Bugzilla – Bug 113040
desktop B/G capplet race ...
Last modified: 2006-01-30 17:43:36 UTC
It -looks- like the D/T B/G capplet is doing some funky idle/background image loading to stay responsive as you switch desktop backgrounds. Unfortunately it appears that as you switch to a new b/g it does not correctly cancel the load/scale/set of the in-progress load. ie. with a few clicks it's pretty trivial to end up with a scenario where a different background to that that is rendered is selected eg. attached screenshot
Created attachment 47637 [details] inconsistent setting ...
I am unable to reproduce the issue on 9.3 or a source build of upstream 2.11 tarballs. I was also unable to see this problem on Mark's SL10 test laptop. I would presume that if the g_source_remove () is not working, then perhaps something changed in glib with regards to timeout API? The timeout is slightly longer than the keyboard repeat timeout, so that if you hold down the arrow key, the capplet does not cycle through all of the images and their settings, passing them all off to gconf. Even if you somehow managed to select a new image immediately after the timeout went past its bounds and started to do the commit to gconf, the timeout would get removed with the new selection, which would get a new timeout, and then would update gconf for the new image. I'm resolving this as WORKSFORME since I have no idea what the two extra fields next to NEEDINFO are for.
I'm running the stock GNOME build in Beta3, I'm using the mouse to select the backgrounds, often selecting A, B, C, B in quick succession; although possible just some Large, Small pattern. Reopening - "doesn't work for me" ;-)
I've been trying to replicate this as well, and can't either.
I can't see it either anymore; closed.