GNOME Bugzilla – Bug 564909
draw_background setting in gconf is ignored
Last modified: 2011-03-13 17:37:21 UTC
Please describe the problem: When logging in, before nautilus starts up, g-s-d asks gnome-desktop for the background image. gnome-desktop doesn't check to see if the background is enabled, so returns the image specified enev when disabled. This is a waste when the user doesn't want a background. Steps to reproduce: 1. Disable background in gnome/desktop/draw_background 2. log out 3. log in. Actual results: The background loads and show before nautilus starts up and takes control Expected results: No background should load Does this happen every time? Yes Other information: Attaching a patch to fix the problem
Created attachment 124883 [details] [review] Patch to check if a background image is enabled
Hrm. I'm actually not sure that's the right place to do this. I think it makes more sense to do the check in gnome-settings-daemon since we don't draw the background in this function, we just get the configuration.
Created attachment 125968 [details] [review] check in g-s-d Yeah, in this case it's probably better to check in g-s-d itself (this patch should work) to avoid generating too much overhead, but ideally I would expect all GnomeBG users to not render when that setting is disabled, so gnome-desktop should also check for it internally (in _set_pixmap_as_root, probably?).
Is this bug on the roadmap for getting fixed for 2.26?
As far as g-s-d is concerned, only if someone can confirm that the patch works as expected. No idea about the gnome-desktop side of things.
This also happens when coming out of a locked screen
Created attachment 173906 [details] [review] Takes /desktop/gnome/background/draw_background key setting into account when gnome-settings-daemon is run I haven't tested the other attached patches, but I can confirm that this one does in fact work. I used the NAUTILUS_SHOW_DESKTOP_KEY code as a reference to keep things uniform. Filing this upstream after submission to bugs.gentoo.org [http://bugs.gentoo.org/show_bug.cgi?id=344301]
I just realized that this is for 2.24.x. The bug still exists in 2.30.2-r1. Should I file a separate report for the 2.30.x?
(In reply to comment #8) > I just realized that this is for 2.24.x. The bug still exists in 2.30.2-r1. > Should I file a separate report for the 2.30.x? I think it's not needed, but anyone with more permissions than me should modify "Version" field ;-)
What needs to be done to get this confirmed? It is a bug, and the patch I submitted fixes it. It has been present from at least 2.24 through 2.30.
Well, things have changed a little bit with migration to GSettings. I believe the "draw-background" value is not respected at all at the moment (applies for Nautilus as well). I was also thinking about removing it completely. The only purpose of this switch would be to indicate "don't ever touch the xroot pixmap", i.e. let background handle some other app (not nautilus, not gnome-settings-daemon). If you simply don't want to draw background image but still want to have solid color on the desktop, set "picture-options" = "none". Either we will make use of this switch or we will remove it completely. Comments?
I'd vote for gnome-bg just not doing anything when draw-background is disabled. Meaning no background setting in nautilus or g-s-d when it's off.
I think that setting draw_background to false in gconf should be respected by gnome-settings-daemon. In tracking down and fixing this issue, I noticed that when gnome-settings-daemon does set the background there is a built in delay. That delay makes it difficult to set the background manually in .xinitrc after executing g-s-d. The option is hidden from any UI settings, so whether it stays that way or not is ultimately up to the Gnome Devs. My current setup consists of Xorg 1.7, Openbox 3.4, pipe menus, gnome-settings-daemon, gnome-power-manager, gnome-volume-manager, and other assorted utilities. I like being able to set my GTK properties with gnome-appearance-properties, and restore them with gnome-settings-daemon. It was becoming nuisance to have g-s-d keep overriding my manual background settings after the delay I mentioned above. After patching gsd-background-manager.c things are working great. It would be a major bummer if this setting continues to do nothing in the official releases, or at worst, is removed.
(In reply to comment #13) > I think that setting draw_background to false in gconf should be respected by > gnome-settings-daemon. Nautilus takes over managing background if it's set to run and gnome-settings-daemon does nothing in that case. > It was becoming nuisance to have g-s-d keep overriding my manual background > settings after the delay I mentioned above. After patching > gsd-background-manager.c things are working great. It would be a major bummer > if this setting continues to do nothing in the official releases, or at worst, > is removed. You can disable g-s-d background plugin if you don't run nautilus and your desktop background will not be touched. Check GSettings' org.gnome.settings-daemon.plugins.background
Maybe the patch could be committed at least for 2.32 branch as other suggestions (like comment #12) won't probably take place until Gnome3 (or even later) and, until then, current situation is not good enough :-/ Thanks
commit 8fab983bb557e0b242616884afab9f049ee1931f Author: Bastien Nocera <hadess@hadess.net> Date: Fri Mar 11 18:51:31 2011 +0000 background: Listen for "draw-background" changing Do the right thing when "draw-background" is set to TRUE again, and do draw the background (hopefully). commit 349bd0063fc9a4c65234a45f800b8c6b7a14ac6e Author: Bastien Nocera <hadess@hadess.net> Date: Fri Mar 11 18:46:14 2011 +0000 background: Never draw the background if "draw-background" is false https://bugzilla.gnome.org/show_bug.cgi?id=564909
As the fix doesn't apply to 2.32 branch, is patch from comment #7 good enough for using in 2.32.1 downstream? Thanks
(In reply to comment #17) > As the fix doesn't apply to 2.32 branch, is patch from comment #7 good enough > for using in 2.32.1 downstream? Thanks I have no idea, and I can tell you now that I will not be looking at it. Most o the patch seemed to rely on draw_background never changing throughout the lifetime of gnome-settings-daemon, and be placed at the wrong time (eg. escape any initialisation). My patches to the upcoming 3.0 should be easy enough to backport as GConf-centric patches, but none of the patches attached to this bug were good enough.
OK, thanks for the info :-)
(In reply to comment #18) > (In reply to comment #17) > > As the fix doesn't apply to 2.32 branch, is patch from comment #7 good enough > > for using in 2.32.1 downstream? Thanks > > I have no idea, and I can tell you now that I will not be looking at it. Most o > the patch seemed to rely on draw_background never changing throughout the > lifetime of gnome-settings-daemon, and be placed at the wrong time (eg. escape > any initialisation). > > My patches to the upcoming 3.0 should be easy enough to backport as > GConf-centric patches, but none of the patches attached to this bug were good > enough. I will have to follow up with you on this one. I will test my patch against the 2.32 branch, as well as read up/ask around on how the flag should be handled by g-s-d. I thought it was a one time thing, checked on startup. I seems I am mistaken. Concerning the status, was this actually resolved/fixed? I know you guys are focusing primarily on Gnome 3 these days, but I am a bit confused.
(In reply to comment #20) > (In reply to comment #18) > > (In reply to comment #17) > > > As the fix doesn't apply to 2.32 branch, is patch from comment #7 good enough > > > for using in 2.32.1 downstream? Thanks > > > > I have no idea, and I can tell you now that I will not be looking at it. Most o > > the patch seemed to rely on draw_background never changing throughout the > > lifetime of gnome-settings-daemon, and be placed at the wrong time (eg. escape > > any initialisation). > > > > My patches to the upcoming 3.0 should be easy enough to backport as > > GConf-centric patches, but none of the patches attached to this bug were good > > enough. > > I will have to follow up with you on this one. I will test my patch against the > 2.32 branch, as well as read up/ask around on how the flag should be handled by > g-s-d. I thought it was a one time thing, checked on startup. I seems I am > mistaken. I would expect the draw-background being changed on-the-fly to be taken into account. > Concerning the status, was this actually resolved/fixed? I know you guys are > focusing primarily on Gnome 3 these days, but I am a bit confused. It's fixed in GNOME 3.