Store current wallpaper in state directory rather than config file.

[max-niederman]

Right now, Waypaper keeps track of the current wallpaper in its config file in $XDG_CONFIG_HOME/waypaper/config.ini.

This is problematic for lots of NixOS users who want to manage their application configurations using home-manager, because this means the config file has to be writable.

By the XDG Base Directory Specification, this kind of state should be stored in the state directory, i.e. $XDG_STATE_HOME/waypaper:

The $XDG_STATE_HOME contains state data that should persist between (application) restarts, but that is not important or portable enough to the user that it should be stored in $XDG_DATA_HOME. It may contain:

• actions history (logs, history, recently used files, …)
• current state of the application that can be reused on a restart (view, layout, open files, undo history, …)

I propose that the current wallpaper is simply stored as a symlink at $XDG_STATE_HOME/waypaper/wallpaper to the path of the currently-activated wallpaper. I'd also be willing to implement this change or a similar one.

[anufrievroman]

Hello, thank you for the suggestion. There's always some trouble with NixOS users 😆 Okay, this sounds reasonable, but before we try to complicate things, I have a few questions:

1) How about all other parameters in the config? I mean, many of them can be changed during the run. Moreover, many programs change their config files, they are not really static, and need to be writable anyway. So, by the provided definition, only wallpaper is the kind of thing that needs to be stored separately?

2) The walpaper entry is actually a list, which contains comma separated wallpaper paths for each monitor. Then there is also the monitors entry which is the corresponding list of monitors, set to ["All"] by default, but there can be many things. So just a symlink will not really work. We'd need another config there.

3) On my system, the platformdirs.user_state_dir() points to ~/local/state but from the almost empty directory I can see that almost no other program follows this standard. They seems to use ~/local/share instead.

[max-niederman]

There's always some trouble with NixOS users 😆

Too true lmao :skull:

1. How about all other parameters in the config? I mean, many of them can be changed during the run. Moreover, many programs change their config files, they are not really static, and need to be writable anyway. So, by the provided definition, only wallpaper is the kind of thing that needs to be stored separately?

By my interpretation I think everything else is configuration; my thinking was that the wallpaper parameter was state rather than config because it really only exists to persist the wallpaper choice across application restarts, not purely because it's mutable.

At least for me, and I think for most home-manager users, the other parameters are all things that I'd want to manage declaratively from my NixOS config. Waypaper (and most programs) already handle immutable config files in quite well IMO, by just silently failing to write configuration changes made from the UI.

2. The walpaper entry is actually a list, which contains comma separated wallpaper paths for each monitor. Then there is also the monitors entry which is the corresponding list of monitors, set to ["All"] by default, but there can be many things. So just a symlink will not really work. We'd need another config there.

Ah, I hadn't realized this. Maybe another ini file like

All = /path/to/wallpaper
HDMI-A-1 = /path/to/other/wallpaper

Or even a fileystem-based API with symlinks like

~/.local/state/wallpapers/All -> /path/to/wallpaper
~/.local/state/wallpapers/HDMI-A-1 -> /path/to/other/wallpaper

3. On my system, the platformdirs.user_state_dir() points to ~/local/state but from the almost empty directory I can see that almost no other program follows this standard. They seems to use ~/local/share instead.

Practically speaking I don't see any problems with using the share directory over the state directory to conform with other (wrong) software, but it does make me a little sad. I'll leave it up to your preference.

[anufrievroman]

Sorry, for long silence. I'm still hesitating about this since it's kind of works fine for everyone as is. I think maybe we could add --nix flag to signalize that we want that part of config to be stored and read from that special directory? I just want to avoid breaking changes.