GNOME Bugzilla – Bug 710756
Changes to current background wallpaper source image not detected consistently
Last modified: 2014-11-07 10:41:13 UTC
I have for a long time been using a script running as a cron job to download an image to use as my desktop background. The script saves the image to a particular file stored locally, overwriting the last image from the previous day. Since the last couple versions of GNOME at least, the change to the background image file no longer automatically leads to the updating of the desktop background (the preview image in the background properties screen however always picks it up). Now, I have to 'nudge' the change into effect by setting some dconf keys in org.gnome.desktop.background (essentially changing the wallpaper settings and then reverting back). To test: Say the image is stored in a file wallpaper.jpg gsettings set org.gnome.desktop.background picture-uri '<image path>' The background should now be set to the content of wallpaper.jpg. Now copy a new image file to overwrite wallpaper.jpg. I would expect the shell to monitor any changes to wallpaper.jpg and instantly update the desktop background when this file changes. However, the background image remains unchanged, despite the file contents having changed. Doing something like gsettings set org.gnome.desktop.background picture-uri '' followed by gsettings set org.gnome.desktop.background picture-uri '<image path>' resets the desktop background and correctly shows the updated image. But this step should not be necessary, I believe, which is why I'm reporting it as a bug.
I have the same problem. The patch from https://git.gnome.org/browse/gnome-shell/commit/?h=gnome-3-8&id=1020d8a0f8523a04d8336b1348388b8b242e414f plus some other patches, that I'll attach to this bug report, are needed for me to have a stable shell, when I stress the background update by (simultaneously) : . periodically changing the background by the picture-uri key . periodically changing the background by updating the file referenced by picture-uri . locking/unlocking the session . periodically changing the screen output/size, with xrandr (--output LVDS1/--output VGA1) commands. I know that the initial patch got reverted after freeze bug reports, but it works for me, and seems needed for the reason given is the commit description.
Created attachment 264016 [details] [review] decrement the loop counter after splice calling splice() on the list we're iterating on changes the position of the next elements.
Created attachment 264017 [details] [review] count references for monitored files
Created attachment 264018 [details] [review] add debug information (optional patch)
Created attachment 264019 [details] [review] background: properly disconnect background manager signals this patch fixes the case of a null bgManager.background in the 'changed' callback.
Created attachment 264020 [details] [review] background: check is backgroundMenu is null before destroy
Review of attachment 264016 [details] [review]: Yes.
Review of attachment 264017 [details] [review]: I have an alternate fix for this that I like better... ::: js/ui/background.js @@ -108,3 @@ - monitor.disconnect(signalId); - Unrelated and bad change.
Review of attachment 264019 [details] [review]: Don't insert private properties into instances owned by somebody else.
Review of attachment 264020 [details] [review]: Why is this necessary?
(In reply to comment #8) > Review of attachment 264017 [details] [review]: > > I have an alternate fix for this that I like better... > > ::: js/ui/background.js > @@ -108,3 @@ > > - monitor.disconnect(signalId); > - > > Unrelated and bad change. I think the signal should not be disconnected here, because the monitoring signal per file is created only once, and if we disconnect it the first time the file is modified on disk, we won't see the next modifications of the same file ?
Comment on attachment 264020 [details] [review] background: check is backgroundMenu is null before destroy I couldn't reproduce the error that made me write this patch, so I propose to ignore it.
Comment on attachment 264019 [details] [review] background: properly disconnect background manager signals I also propose to discard this patch for the same reason : I could not reproduce the related error.
Hello, I can confirm this bug simply with Firefox browser. In Gnome 3.10, when setting desktop background from Firefox - right click on an image - Set as Desktop Background, the browser creates a file named "Firefox_wallpaper.png" in user's home folder and the background is changed. When setting a different image as a desktop background from Firefox, the browser simply overwrites the image file but the background stays the same, it does not change for the new one. When opening the file in the Image Viewer and "Set as Wallpaper", the Image viewer notifies that "The image "Firefox..." has been set as desktop background...", but the background does not change at all. The only way to update the wallpaper is either restarting the Gnome session (altF2r) or logging out and logging back in.
Review of attachment 264016 [details] [review]: should someone push this?
Hi! Since bug #735638, the background code changed a lot (between 3.13.91 and 3.13.92), and the pending patch no longer applies. However, this bug is still there : a modification of the background file on the filesystem triggers a 'changed' event in BackgroundFile.monitorFile, but the change is not propagated on screen. (just tested on Fedora-21-alpha, with gnome 3.13.92 rpms)
Created attachment 287012 [details] [review] background: when a file changes, remove it from the image cache MetaBackgroundCache doesn't itself use file watches, so when a image that we are monitoring changes we need to purge it from the cache, so that when we load it again we get the new image.
Review of attachment 287012 [details] [review]: ::: js/ui/background.js @@ +301,3 @@ Lang.bind(this, function(cache, changedFile) { if (changedFile == filename) { + let cache = Meta.BackgroundImageCache.get_default(); Can you pick a different name (metaCache?) that doesn't shadow the function parameter?
The patch works for me. Thanks!
Changed cache=>imageCache and pushed. Attachment 287012 [details] pushed as 50ac1dd - background: when a file changes, remove it from the image cache
*** Bug 707950 has been marked as a duplicate of this bug. ***
*** Bug 723917 has been marked as a duplicate of this bug. ***
*** Bug 725307 has been marked as a duplicate of this bug. ***
*** Bug 725652 has been marked as a duplicate of this bug. ***
*** Bug 733383 has been marked as a duplicate of this bug. ***
*** Bug 729910 has been marked as a duplicate of this bug. ***
*** Bug 735738 has been marked as a duplicate of this bug. ***