GNOME Bugzilla – Bug 583757
Unconditionally fades in background
Last modified: 2010-12-01 08:44:34 UTC
Please describe the problem: Since upgrading to 2.26.0, gnome-settings-daemon now fades in the background rather than just drawing it immediately. I find this behavior very annoying. As far as I can tell, no way exists to turn this behavior off, either, short of either editing the source (plugins/background/gsd-background-manager.c, on_bg_changed, change the second argument of draw_background to FALSE) or turning off gnome-settings-daemon's background handling entirely. I'd really like to see some option I can use to disable this fading. Actually, I'd really like to see this disabled by default, for the same reasons that gnome-session disabled the splash screen by default, but I'll settle for an option I can use to disable it myself. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Originally reported as Debian bug 525187: http://bugs.debian.org/525187
You can turn off animations like these by toggling the gtk-enable-animations gtk setting. One easy way to do that is to put gtk-enable-animations = 0 in your gtkrc file
(In reply to comment #2) > You can turn off animations like these by toggling the > > gtk-enable-animations gtk setting. > > One easy way to do that is to put > > gtk-enable-animations = 0 > > in your gtkrc file Interesting. I don't know that I want to turn off *all* animations, though. But I'll try that setting and see how it works out.
That setting in ~/.gtkrc-2.0 did indeed disable the fade-in animation. However, the screen still flashes to black and then to the background color. I have the same background color in GDM and in my session, so I'd expect a seamless invisible transition from the GDM background to my session's background.
are you using a solid background color? No picture?
(In reply to comment #5) > are you using a solid background color? No picture? Right.
The use of the same solid background color for GDM and GNOME motivated this bug report in the first place: it looks very odd to have gnome-settings-daemon replace the background color with black and then fade it back to the original background color.
So when the background is a picture, the image is retrievable, but when it's a color it's not. Right now if we can't figure out what to fade from, we fade from black. I wonder if we should just skip the fade entirely in that case. Or maybe we should stuff the color as a property on the root window also, then it would be retrievable and we could fade properly.
(In reply to comment #8) > So when the background is a picture, the image is retrievable, but when it's a > color it's not. Huh, strange. > Right now if we can't figure out what to fade from, we fade from black. I > wonder if we should just skip the fade entirely in that case. That sounds sensible. A fade from black will more than likely result in an initial flash *to* black. > Or maybe we should stuff the color as a property on the root window also, then > it would be retrievable and we could fade properly. Perhaps, but please do check and avoid the fade if the colors match. :)
*** Bug 632081 has been marked as a duplicate of this bug. ***
Bastien, bug #632081 highlights that a good way to address this problem is to fix the g-s-d plugin to make use of the new nautilus configuration setting to disable the fading feature. So, please refer to nautilus bug 623174 to see more information about this. Also note that nautilus now uses GSettings and not GConf, so this probably means that g-s-d needs to be updated to use the new GSettings configuration anyway. Note that the g-s-d background plugin uses the nautilus configuration settings to know how to draw the background. So adding this new configuration option to disable the fading effect should probably be done as a part of updating the g-s-d background to use the new nautilus GSettings configuration.
(In reply to comment #11) > Bastien, bug #632081 highlights that a good way to address this problem is to > fix the g-s-d plugin to make use of the new nautilus configuration setting to > disable the fading feature. So, please refer to nautilus bug 623174 to see > more information about this. > > Also note that nautilus now uses GSettings and not GConf, so this probably > means that g-s-d needs to be updated to use the new GSettings configuration > anyway. Note that the g-s-d background plugin uses the nautilus configuration > settings to know how to draw the background. > > So adding this new configuration option to disable the fading effect should > probably be done as a part of updating the g-s-d background to use the new > nautilus GSettings configuration. You can't use schemas or settings from programs lower down the stack with GSettings. All the needed settings should be from gsettings-desktop-schemas, and the functionality in GnomeBG. Given that GnomeBG already follows the "gtk-enable-animations" setting, I think this should be enough to fix the problem (disable it, and you won't get animations in much of the desktop, and no fade). If you need a separate setting just for the fade, please file a bug against gnome-desktop, where all the fade code is. And, obviously, if the setting isn't respected in your setup, feel free to file a bug against gnome-desktop again.
I guess I don't really care that much about having a separate setting, but I don't really want to disable all animations, either (though doing so does work). Actually, I'd be perfectly happy if whatever does the fade would do some kind of crossfade, so that if the initial and final appearance looks the same, the fade would not have any visible effect. Or any other solution that avoids fading to black between two otherwise identical backgrounds. What package should I file that request against (or reassign this bug to)?