Restarting regolith resets the wallpaper

[ankitson]

Describe the bug
Restarting regolith with Super+Shift+R resets my desktop background to the default regolith background (shown on the homepage).

To Reproduce
Steps to reproduce the behavior:

Restart regolith via Super+Shift+R. Rebooting or shutting down the computer does not cause this problem.

Expected behavior
Regolith restarts with background intact.

Screenshots
N/A

Installation Details

• Regolith Install Type: PPA
• Regolith Version: regolith-desktop/focal,now 2.63-1focal1 amd64
• PPA url: ppa:regolith-linux/release
• Host OS (for PPA): Pop OS 20.04

Additional context
N/A

[moritzheiber]

How are you setting your background?

[moritzheiber]

As a side-note, the documentation on this appears to be misleading: https://regolith-linux.org/docs/getting-started/configuration/

cc @kgilmer

[kgilmer]

Hi @ankitson , yes this is by-design. Because Regolith is a blend of i3 (X windows) and GNOME, there are some configuration elements that are redundant, including the wallpaper. Regolith tries to be smart by only changing the wallpaper from X if it detects a change, but refreshing the session explicitly forces Regolith to refresh itself from the existing Xresource values. You can see that the wallpaper is defined in Regolith with the xrdb tool:

$ xrdb -query | grep wallpaper
gnome.wallpaper:	/usr/share/backgrounds/ESP_016895_1525_desktop.jpg

So, Regolith is seeing this and then updating GNOME (dconf/gsettings) to use is this as well. To avoid this issue, you can override the default wallpaper in Xresources using (Xres overrides)[https://regolith-linux.org/docs/howto/override-xres/].

[kgilmer]

To properly fix this, some kind of synchronization mechanism between dconf/gsettings and Xresources would need to be created. Or, remove Xresource support for wallpaper, which would be a regression for Looks. Or, remove the ability for users to change wallpaper via Settings (which may not be possible without forking).

[kgilmer]

This is also tied into the recent gsettings-override change in gnome-regolith-flashback. There may be another solution that's not clear to me yet.

[moritzheiber]

@kgilmer But then the documentation will have to change as well

[cheginit]

I think setting background from Xresource is more inline with the overall philosophy of Regolith and users should be encouraged to set it this way. This approach is more convenient from dotfile management point of view.

[moritzheiber]

Is the Xresources handler also setting the wallpaper for the lock- and login screens? Because that's what GNOME Control Center does, I think.

Also, I disagree that setting this in Xresources is more convenient, especially for users that aren't managing their environment using dotfiles. The Control Center clearly suggests that its a viable way of setting the wallpaper, but we are "hijacking" this process in order to, supposedly, improve user experience.

Ideally, we could have both methods run side-by-side?

[kgilmer]

Is the Xresources handler also setting the wallpaper for the lock- and login screens? Because that's what GNOME Control Center does, I think.

I think that before focal, this was the case, however the lock and login screen changes I believe were intended for gnome-shell, as they didn't seem to work. In focal it doesn't appear that we can select anything except the desktop wallpaper, which does work.

Yes, I think both methods have value depending on who you are, and that this sync issue between the two is "worth it" to allow people to easily set their wallpaper via a GUI or keep it managed in dotfiles depending on their preferences.

I was thinking that w/ the gsettings monitor function, it would be possible (but probably complex relative to the potential functional gain) to listen for gsettings changes and then somehow update Xresources accordingly.

There is a future potential of Regolith to migrate entirely to gsettings/dconf over Xresources (although the opposite is also possible it seems to me it would be much more work to make GNOME use Xres instead of dconf), unifying all configuration into gsettings. This would require forking i3-gaps and rofi, at least. So, for example instead of i3 setting window decoration colors from the i3 config file (transitively the Xresource db), it would directly integrate gsettings APIs to read and use gtk settings naively. However, this seems like a lot of work and it isn't clear that the resultant system would be better than Regolith in it's current state, other than perhaps internally being more symmetrical and consistent.

[moritzheiber]

We already have another bug relating to handling of gsettings/dconf vs. xsettings vs. Xresources, this one appears to be another artifact of it .. 🤔

[moritzheiber]

@ankitson I think your issue is resolved for now, right? If so, I'm going to close this report and open an enhancement topic instead which refers to the situation around respecting Xresources values and GNOME settings

[ankitson]

@moritzheiber @kgilmer

Yes, this resolves my issue, thank you for responding. I am not familiar with the details of Gnome and X but I can see how syncing config can get complicated for little benefit. As a user I think if there is no syncing, the docs should just mention this quirk.

[moritzheiber]

Okay, thank you. I've opened a new issue (#431) and closing this one.