Is the default desktop theme backed up outside /usr/share/themes?


I am using Ubuntu 20.04 with Gnome 3.38.0-1ubuntu1 (installed from PPA).

The question:

I moved /usr/share/themes to /usr/share/themes_backup. I also deleted $HOME/.themes, and checked that $HOME/.local/share/themes did not exist.

However, Gnome still boots into the default theme, even though it has been deleted.

How is this possible? Is the default theme backed up elsewhere?

NB. This question follows issues themes on both Budgie and Gnome, posted here (Cannot change themes after hard reset - Budgie Desktop - Ubuntu Budgie)

I also asked this question at Unix stackexchange, but without any response
(ubuntu - Default desktop theme still boots, after being deleted - Unix & Linux Stack Exchange)

Thank you,


If by “default theme” you mean “the default theme for GTK applications and GNOME Shell”, then it’s expected: the default themes in both cases is embedded into GTK and GNOME Shell, respectively, as without a default theme both applications and the shell would be utterly broken.

I guess the actual question is: what is it that you’re trying to achieve.

1 Like


I wanted to know if I could force a change to the default theme, by deleting all but one other theme.

I did a hard restart on my laptop (via the power button), on Budgie desktop. Since then, GTK / icon themes cannot be changed. I can change the values with the commands below (and they do, in fact, change), but it does not bring about any actual (visible) change to the themes:

gsettings set org.gnome.desktop.interface gtk-theme "example-theme-name"
gsettings set org.gnome.desktop.interface icon-theme "example-icon-theme-name"

I asked at Ubuntu Budgie discourse, and it was suggested that perhaps gsettings were corrupted. I deleted all gnome user settings and reinstalled dconf, with no effect. Completely purging budgie desktop and reinstalling changed nothing either.

rm -rf ~/.gnome ~/.gnome2 ~/.gconf ~/.gconfd ~/.metacity .config/dconf/*
apt-get install --reinstall dconf-cli dconf-editor dconf-editor dconf-gsettings-backend dconf-service libdconf1

I thought Gnome desktop was affected as well, but actually changing themes is working fine when logged into Gnome. I hope this question is ok here, as it is about gsettings/dconf.

It now seems that a reinstall would be the next step. I am still mystified why a hard reboot would cause this to break though. I know very little about hardware, but my guess is this is some damage due to the power spike.

Thanks for answering a very basic question about how Gnome works.

If you are using a desktop like Budgie, in all likeliness GTK never sees your settings change, because there might be no xsettings-manager running (in GNOME, that role is filled by gnome-settings-daemon).

1 Like

Thank you!

Adding /usr/libexec/gsd-xsettings to startup applications on Budgie fixed the problem.

Looking at the startup applications, gnome xsettings is there as /usr/lib/gnome-settings-daemon/gsd-xsettings, but this file no longer exists.

Notwithstanding, without the daemon running, changing all other gnome settings than the icon/desktop was still working… do these settings not need it?

I am not sure how the problem came about.


This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.