if background image set to path on removable storage, image should be copied to local storage
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
One Hundred Papercuts |
Fix Committed
|
Low
|
Unassigned |
Bug Description
Not 100% sure if this counts as a papercut, as I'm not sure it is trivially fixable. However, this is a good a place to start as any to file the bug for tracking purposes, and it can always be moved against the proper package.
Steps:
1. connect USB storage which has some photos
2. Select a photo and open it to view
3. Set it as wallpaper
4. Shutdown
5. Remove the USB storage
6. Boot up
Expected behaviour
Wallpaper should be set.
Actual behaviour
Blank background.
Explanation:
a) in step 3, we do not actually copy the image from the USB key to the main storage. In fact, we simply set a gconf key (desktop-
b) so when the key is removed in step (5) and rebooted in step (6), the path to the background image is no longer valid, and that is why we do not see it upon restart.
c) in fact, even if the key is present (ie, skip step 5 and perform steps 4 and 6), we still get a blank background.
The reason for this is because the normal desktop starts *before* the USB key is mounted, so the path to the background image is invalid. Nautilus cannot find the path, and we get the empty background.
Now if Unity-2D is in the picture, and we enter the Dash homescreen, we *might* see the background image, but only if the USB key was present during boot. This is because the Dash home screen logic occurs *after* the USB key is mounted, so now the path to the image *is* valid. Unity reads the path, it works, and we see the image. Somehow, Unity caches the image somewhere, because it remains even after the key is removed.
This is very confusing behavior. As a developer, I think "duh, you're setting a path to an image on removable storage, so when that goes away, of *course* your image won't work". However, it is slightly troubling that it doesn't work even if the USB key is present during boot, due to the timing of when drives are mounted vs. when nautilus looks at the paths.
This could all be fixed simply by ensuring that whenever we set a background image, we always copy it to local storage, and setting the gconf key accordingly.
Thanks for the detailed bug report. But we already have Bug #344228 which has been fixed by upstream as you've mentioned (If wallpaper is not in local pictures directory, it will just be copied.). :-)
This will land with other g-c-c 3 changes, or if someone works on backporting the change to g-c-c 2