ARM Sway Edition, changes to .config/*/* are overwritten when I log out and back in

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/, 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).

@appelgriebsch Any ideas why these settings are not saved?

1 Like

That was introduced as part of the theming concept. A theme is specified here: overlays/sway/etc/sway/definitions · master · manjaro-arm / applications / arm-profiles · GitLab, the configuration templates can be found here: overlays/sway/etc/sway/themes/templates · master · manjaro-arm / applications / arm-profiles · GitLab and the code to trigger the template replacement is part of the autostart configuration of Sway here: overlays/sway/etc/sway/config.d · master · manjaro-arm / applications / arm-profiles · GitLab.

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?

Moving this thread to arm section.

I just had a deeper look at the sed scripts in the autostart configuration and beside the config file for the terminal emulator ‘termite’ it only updates the style.css file in e.g. .config/waybar/ (overlays/sway/etc/sway/config.d/94-enable-waybar-theme · master · manjaro-arm / applications / arm-profiles · GitLab). The same for wofi and wlogout.

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…

Those were exactly the two files I edited. :man_facepalming:

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.

Good news: I found a way to improve the theming so that it no longer needs to update the styles.css files in the users .config directory…

At first GTK CSS handling allows to use import directives aka @import url("path-to-theme-color-specs") and also allows to define color variables via

@define-color bg_color #f9a039;

* {
  background-color: @bg_color;

(see: GTK+ CSS Overview: GTK+ 3 Reference Manual).

With that in place it will be way easier to configure theme specific colors.

Done. Gitlab commit: [sway] rework theme concept using gtk css imports and color variables (4ed6c11d) · Commits · manjaro-arm / applications / arm-profiles · GitLab.

Will be part of the next Sway image (20.12).

1 Like

Hey, I created a new Sway image based on the recent changes to the profile settings and the stable package updates published today.

You can find it here for Pinebook Pro and Raspberry Pi4: Manjaro ARM Sway Profile builds Project Top Page - OSDN

Feel free to give it a try