Configuration

[gabm]

Description

There are more and more requests for more configuration options. Currently we allow configuration exclusively through the commandline. That is okay but a) becomes confusing and b) has to be specified on each call - so it is not available when launched from the file browser for instance.

I want to introduce a config file which should reside in the XDG_CONFIG_DIR/satty/config.{ending}. Every configuration option shall have a sane default, a configuration entry and a commandline option. The hierarchy shall be as mentioned where the command line has the highest priority and overrides previous settings.

I did not decide on a format yet, I like yaml for its accessibility but I feel that toml is more type safe - although I dislike some of its design choices.

Existing Configuration options

• early exit: Directly exit after copy/save action
• fullscreen: start in fullscreen mode
• copy command: specify the command to be used for the copy action
• output-filename: specify the output folder and filename (if we want to handle this as a config option, then we need to allow patterns here..)
• initial-tool: the tool that is selected by default on start-up

Requested Configuration Options

• color-palette: specify the value of each colour (#28)
• annotation-size-factor: specify the size of the annotations (e.g. make S bigger or smaller than default) (#28)
• exit-action: what to do when exiting the app: clipboard, save or both
• filename pattern

Possible Other Options

• font: Font for text rendering
• ...

[wangyc-pers]

I'm thrilled about this feature! Regarding the configuration file format, I'm a big fan of TOML over YAML. YAML's rigid indentation requirements often give me a headache.

Moreover, I have another suggestion. How about introducing a separate configuration option for the file name format that supports formatting? For instance, something like "satty-%Y-%m-%d %H:%M:%S.png." This would enable us to specify the save folder when using a command, without repeating the file name. I believe this would add a delightful touch of flexibility to our setup! What do you think?

[gabm]

thank you for your warm words and your suggestion. It's what i meant with "patterns" up there.. i plan to do exactly like you suggest!

i would be happy about contributions

[gabm]

CALL FOR TESTERS

I implemented configuration file handling in #38 . The file is supposed to reside in ~/.config/satty/config.toml. The (currently) exhaustive list of options is:

[general]
fullscreen = true
early-exit = true
initial-tool = "brush"
copy-command = "wl-copy"
annotation-size-factor = 2
output-filename = "/tmp/test-%Y-%m-%d_%H:%M:%S.png"

[color-palette]
first= "#00ffff"
second= "#a52a2a"
third= "#dc143c"
fourth= "#ff1493"
fifth= "#ffd700"
custom= "#008000"

Please checkout the code, build it, try it and give feedback. I am specially interested in

• general feeling aobut the solution
• naming of the options
• interaction with the commandline, that can override the config options
• new introduced options: size-factor and color handling

[wangyc-pers]

Hello gabm,

I hope this message finds you well. I wanted to express my sincere apologies for the delayed response; I've been caught up with work commitments and overlooked checking my emails. I appreciate your understanding.

Upon manually compiling and testing the code, I'm delighted to share that Satty offers precisely the functionality I was seeking. Here are some thoughts and suggestions:

1. Configuration File Path Parameter: It would be beneficial to introduce a parameter in Satty for specifying the configuration file path. This would provide users with the flexibility to opt for either the default path or a customized one.

2. Automatic Configuration File Generation: Considering runtime scenarios, it might be worthwhile to check if users have a configuration file. If absent, an automatic generation of a default configuration file with explanatory comments could enhance the user experience by providing guidance on each parameter's purpose and acceptable values.

3. Persistent Customer Color Modifications: Noted the observation regarding customer color modifications made post-Satty launch not being saved to the configuration file. I believe that any changes a user makes to the customer color should be persistently saved to the configuration file, ensuring a consistent experience across sessions.

Best regards

gabm @.***> 于2023年12月28日周四 18:11写道：

CALL FOR TESTERS

I implemented configuration file handling in #38 https://github.com/gabm/Satty/pull/38 . The file is supposed to reside in ~/.config/satty/config.toml. The (currently) exhaustive list of options is:

[general]fullscreen = trueearly-exit = trueinitial-tool = "brush"copy-command = "wl-copy"annotation-size-factor = 2

[color-palette]first= "#00ffff"second= "#a52a2a"third= "#dc143c"fourth= "#ff1493"fifth= "#ffd700"custom= "#008000"

Please checkout the code, build it, try it and give feedback. I am specially interested in

• naming of the options
• interaction with the commandline, that can override the config options
• new introduced options: size-factor and color handling

— Reply to this email directly, view it on GitHub https://github.com/gabm/Satty/issues/30#issuecomment-1871021494, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK335MFYVF4K6DRSERHAOI3YLVAVLAVCNFSM6AAAAABAJGG7OOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZRGAZDCNBZGQ . You are receiving this because you commented.Message ID: @.***>

[gabm]

thanks for your valuable feedback. I agree with any point made! Currently my time is limited, so lets see what is the ETA on this..

[gabm]

The configuration file update has been merged and released as v0.9.0. Please test and report any issues.

I decided against the following ideas for now

• automatic file generation: I use nixos nowadays and we wouldn't really want the programs to write automatically. We do have a sane set of defaults, so a config file is not necessary imho
• persistent settings: as a result of previous thoughts on this and as outlined in #34, config and state should be separated and we would never want to touch the users config. Therefore we might introduce an "autosave settings" config that will cause satty to write a state file... the config will then only describe the initial state of things

Thank you for your help on getting this done and testing!