Store recent images list outside of the configuration file

[fabienengels]

Is your feature request related to a problem? Please describe. Currently, it's hard to simply commit the config file in a git repository as the config file changes all the time due to the "recent_images" field.

Describe the solution you'd like Store the list of recent images to a separate file like : ~/.local/state/oculante/recent-images.json

Additional context Lot of users track their dotfiles in a git repository. I think it's nice to separate the proper configuration and states like mpv does to track videos progress (when save=position-on-quit is used) by storing this kind of information in ~/.local/state/mpv.

[woelper]

Interesting idea!

Would there be other things not to store in the main configuration file, such as window size?

[eugenesvk]

Yes, last_open_directory as well

Also ideally the format would be a comment-allowing and parsing whitespace preserving so that users could reorganize (like group various ◀▲▶▼ keybinds in a single line etc) and comment configs. Would need non-serde-based concrete syntax tree-like parser for that

(I see that you've changed to a condensed json dump, that also doesn't help with some naive diffs)

P.S. By the way, the way I get around it is use chezmoi store the config there, and just generate a json dump to match your output (this also allows me to skip temp changing fields like last_open_directory), but even then I can't reoder configs (guess would need to add some sorting before), and also that's way too cumbersome unless you're already using this tool

[woelper]

I am looking at this now - I could add the ability to preserve order in serde_json first, and see about putting "volatile" configurations as above into a second file. I don't think I would want to use anything non-serde though as this would be quite some effort. What would be possible is to use a non-json format - but that would also not preserve comments or whitespaces once oculante saves over the file again.

[eugenesvk]

What would be possible is to use a non-json format - but that would also not preserve comments or whitespaces once oculante saves over the file again

unless that format has a rust space-preserving parser library :)

The best overall config format I've found is KDL (especially when v2 is supported, which would not require those mandatory garbage syntax like " in simple configs that don't benefit from it), and it just so happens it has a space-preserving praser library (at least from its description) https://github.com/kdl-org/kdl-rs

[woelper]

That does sound nice. But the persistent settings are a nested struct with children that are custom types, such as the shortcuts. Serde (and its supported formats) handles this transparently. If another library requires manual parsing or re-creating these structures this would mean a lot of additional code for a relatively low return.

[fabienengels]

Interesting idea!

Would there be other things not to store in the main configuration file, such as window size?

I only spotted recent_images as it was the one I saw when I did my git diff. My guess would be that config file should only store parameters explicitly defined by the users :)

I've just started to learn Rust so I won't take the risk to make a pull request :D

[kurnevsky]

Also ideally the format would be a comment-allowing and parsing whitespace preserving so that users could reorganize (like group various ◀▲▶▼ keybinds in a single line etc) and comment configs. Would need non-serde-based concrete syntax tree-like parser for that

This is not really needed if the config file is never written by oculante - just never touch settings and write it manually and you can store it in git. This is how home-manager works. In this case it's important to oculante not to overwrite settings file if settings weren't changed (like on exit), because home-manager puts a symlink to settings instead of plain file.

[eugenesvk]

just never touch settings and write it manually

That'd be a worse experience, e.g., it's easier to change shortcuts via GUI by pressing the actual shortcut.

it's important to oculante not to overwrite settings file if settings weren't changed (like on exit), because home-manager puts a symlink to settings instead of plain file.

you can still overwrite if you follow symlinks, the app just has to be aware of that (another common fail is so called "atomic saves" where the new file is saved then copied over to the old one, thus removing the old link)

Though this is the reason why it's better to just use regular files which some home managers allow

[kurnevsky]

That'd be a worse experience, e.g., it's easier to change shortcuts via GUI by pressing the actual shortcut.

But this is up to you to decide whether you want it to be overwritten with some default formatting and lost comments, or you want to edit it manually.

you can still overwrite if you follow symlinks, the app just has to be aware of that (another common fail is so called "atomic saves" where the new file is saved then copied over to the old one, thus removing the old link)

If we are speaking about nix then those symlinks point to read-only nix store - it's impossible to overwite it without remounting the whole store. And the point is that you write config manually in nix language for everything, and it's then being mapped to necessary configs. For instance, here I have a config for alacritty, and I don't really want any app to mess with it - I always want it to be written manually.

It's not that I'm against that feature, I'm just saying that there are benefits in a config separation from mutable part even if oculante can't preserve comments/formatting, and for many this will be enough.

[woelper]

I've had time to look at this and have a branch ready. There are two settings files in a oculante folder now. For now, the format keeps the order, but it is not space-preserving. I'll investigate a bit more but would prefer to merge what I have for the sake of progress. I've put the config folder in git and it seems quite convenient manually editing the file. Of course oculante would write over the file again at some time, resetting the formatting, but avoiding this would come at a much higher effort.