Red Hat Bugzilla – Bug 447192
Changes to desktop background and fonts are not automatically loaded upon reboot of system.
Last modified: 2009-07-14 12:19:12 EDT
Description of problem:
Chosen Desktop Background and font choice not loaded after reboot or startup,
until user selects System - Preferences - Look and Feel - Appearance. Desktop
background also looks corrupted until this is done.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Change system background and font via System - Preferences - Look and Feel -
2. Make changes to desktop background and font choices.
3. Close out of "appearances" window.
Desktop background and font have reverted to default selections, mostly, but
desktop background appearance is corrupt (black bar across bottom of screen).
This will automatically "fix" itself however, if user returns to System -
Preferences - Look and Feel - Appearance. Without making any changes other than
switching between tabs, the desktop background and font will change to previous
Desktop background choices and font choices should save and load upon login.
This seems to only occur when you use a desktop that is a solid color only,
rather than a picture. I changed the desktop to a picture through Desktop
Appearances, and the problem seems to have gone away. Hopefully that info will
help you track down what's causing the problem, as it was quite annoying until I
found the workaround.
The issues described above may be unrelated. I can't reproduce the font problem
but I've experienced unwanted background reversion under the "No Wallpaper"
setting. The latter problem can be reproduced without rebooting -- assuming you
currently have a wallpaper set as your background, do the following:
1. Go to: System -> Preferences -> Look and Feel -> Appearance -> Background
2. Select the "No Wallpaper" thumbnail in the chooser then click Close. As
expected the background image should disappear, leaving you with a simple graded
or single-colored background
3. Trigger the bug. Launch the Appearance Preferences app again as you did in
Step 1 but don't switch to the Background tab. You should observe the background
reverting on its own to the default Waves wallpaper, regardless of whichever
wallpaper you started with (and if you have an uncommon monitor resolution you
may notice the wallpaper isn't properly fitted to the screen as it would be if
you had selected the wallpaper manually). Don't do anything else here, just
4. By triggering the bug again the settings will correct themselves. Launch the
Appearance Preferences app once more and switch to the Background tab. The "No
Wallpaper" preference should automatically re-apply itself to the background
without you having to select anything in the chooser.
After disabling nautilus-2.22.1-hide-white-screen.patch in nautilus.spec then
rebuilding and reinstalling the RPM, the bug is no longer reproducible. Dropping
this patch presumably breaks what the patch originally tried to fix however.
Upon inspection the patch seems to fail to handle the "No Wallpaper" case
properly, since it should be testing the GConf key
/desktop/gnome/background/picture_options for a value of "none". I hope to post
a corrected version of the patch soon.
A fix isn't so straightforward. In Fedora's current Gnome 2.22 release
background handling is spread across nautilus, control-center, and
gnome-desktop, and the state logic involved in the "no wallpaper" case is
convoluted and brittle. This is probably why libbackground is being phased out
upstream . The changeover obsoletes the
nautilus-2.22.1-hide-white-screen.patch mentioned in my previous comment.
Efforts toward resolving this bug are probably better spent backporting
upstream's changes to Nautilus  and the other packages.
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.