I’m trying out the new(ish) ARM Sway Edition (20.10 release) on my Pinebook Pro. I made several tweaks to files in $HOME/.config, e.g. .config/termite/config, .config/waybar/config, .config/waybar.style.css, and then I logged out and back in to get the changes to the waybar configuration picked up. Upon logging back in, all of the files I had modified were overwritten with the originals provided by the system.
This seems only to affect files in .config; for instance, a change to $HOME/.bashrc was not overwritten. Also, it doesn’t happen if I log in on a text console, only if I log in via the graphical greeter. (I did not try logging in on a text console and starting sway from there.)
What component is responsible for this behavior, and how do I make it not do that?
Should not happen unless you did not save the edits or there is a symlink active instead to which the config points where you don’t have write access. IN the last you should have gotten an error.
Also why logout and in instead of reloading the config?
I dunno what the keybinding is in Manjaro sway edition, but in my config it is mod+shift+c (check the sway config for the correct binding).
The process as such looks like the following: based on the configured theme variable a set of sed scripts are executed that replaces predefined color variables in the templates and store them in the .config folder of the user when he logs in.
So one could either update the templates, or disable the autostart configuration for now. I’ve to investigate how to make this a bit more user-customizable (templates are always taken from /etc/sway/themes/templates) at the moment…
As a user, I generally expect that logging in, starting applications, and so forth may create config files that don’t exist, but will never overwrite a config file that already exists. I was so shocked when this happened that I spent like ten minutes making sure I hadn’t booted off of my recovery SD card or logged in as the wrong user or something like that.
IMNSHO a better implementation, if possible, would be to have each file in the user’s .config include a system-provided file from the selected theme. Switching themes and color preferences would be done with variables. I don’t know to what extent this is possible with the swaywm config language, I’m still learning it.
If that’s not possible, behavior like how pacman handles system-wide config files that may have been changed by the sysadmin (i.e. installing the new files under different names and alerting the user to reconcile differences) would be preferable to the current behavior.
Thanks for pointing me at the code responsible for this.
I didn’t expect the swaywm “reload config” keystroke to affect the waybar or termite configuration, only the configuration for swaywm itself. Is that not the case?
These style.css files doesn’t affect the customization of the modules in your waybar (as part of the .config/waybar/config).
So from this p.o.v. the procedure looks ok’ish to me. Could you eventually elaborate what kind of changes got overwritten?
Btw: a reload of sway will also reload all the autostart applications incl. waybar, so changes will be also reflected there (without having to logout / login again).
EDIT: to ease the generation of custom styles I will update the scripts in such a way that you can specify an own template directory (e.g. in you home directory). Then you would need to overwrite one variable in your sway config to get your theme templates activated…
I can only reiterate that I don’t think it is ever okay for login scripts to overwrite any file in the user’s home directory. Create, yes, overwrite, no.
Good to know, but if I’d done that I wouldn’t have noticed the bug.
