Description of problem:
Gnome cannot keep wallpapers when changing desktops.
Version-Release number of selected component (if applicable):
[mcpierce@mcpierce-desktop ~]$ rpm -q nautilus
Steps to Reproduce:
1. Go to a desktop.
2. Set the wallpaper.
3. Change to a different desktop.
The wallpaper changes to the default wallpaper.
The wallpaper to stay ask set.
I'm using the nouveau driver from the mesa-dri-drivers-experimental package.
[mcpierce@mcpierce-desktop ~]$ rpm -q mesa-dri-drivers-experimental
The error message in ~/.xsession-errors is:
GdkPixbuf-CRITICAL **: gdk_pixbuf_format_get_name: assertion `format != NULL' failed
This is really curious bug. Generally, desktop background is set by gnome-settings-daemon initially after startup and then nautilus places a root window on top of it with icons and its own wallpaper. Crossfade effect should occur on this occasion.
There might be several potential intruders changing your background back to "default" - usually other processes managing backgrounds, like nautilus running under different user, other filemanager managing desktop (Thunar from xfce) etc.
Do you see icons on the desktop when the change happens? Does it happen always on workspace switch? Does it happen after a timeout while idle, say in a few seconds? Does it happen when you turn the desktop effects off and stay with plain metacity?
I don't think it's related to nouveau, I'm running it myself and never seen the problem you describe.
(In reply to comment #1)
> This is really curious bug. Generally, desktop background is set by
> gnome-settings-daemon initially after startup and then nautilus places a root
> window on top of it with icons and its own wallpaper. Crossfade effect should
> occur on this occasion.
> There might be several potential intruders changing your background back to
> "default" - usually other processes managing backgrounds, like nautilus running
> under different user, other filemanager managing desktop (Thunar from xfce)
I don't have Thunar installed on my system. And it's my work laptop, so there are no other users on the system. It's purely my account logged in once with my user account and session running.
> Do you see icons on the desktop when the change happens? Does it happen always
> on workspace switch? Does it happen after a timeout while idle, say in a few
> seconds? Does it happen when you turn the desktop effects off and stay with
> plain metacity?
It only happens when I switch desktops.
> I don't think it's related to nouveau, I'm running it myself and never seen the
> problem you describe.
I agree that this is likely not a nouveau problem - I installed the binary-only nVidia drivers and the functionality continued.
But I think it's related to having two monitors. When I have a single display then it doesn't occur. But when I'm on two monitors the pathology occurs.
I have exactly the same problem. I can change the background image but when I switch between workspaces it goes back to the default.
I use Fedora 13 and the hardware is Lenovo laptop. I don't have two screen but I mostly use my laptop in docking station which I'm not sure if qualifies as two screens.
I have more observations on this bug that is now seen in Fedora 14. If you have a single workspace, then everything works fine. If you have multiple workspaces, then if you change the background in the first workspace, then go to another workspace, the wallpaper fades away. If you change the background in any workspace other than the first one, then the wallpaper fades away if you go to the first workspace, but not if you go to other workspaces and stay away from workspace #1.
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13. 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 '13'.
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 13'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 13 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 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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.