GNOME Bugzilla – Bug 143112
Make a copy of files used for desktop wallpaper
Last modified: 2011-02-12 03:33:36 UTC
Gnome 2.6 I chose a file to be my desktop wallpaper, and then I moved it. When I rebooted, the desktop wallpaper didn't show. You should make a copy of the file, instead of relying on the file remaining in the same location. That copy should remain until you change the desktop, at which point it would be replaced.
Mmm, that seems like a half-baked solution to me. The desktop manages a whole -set- of files that you designate as backgrounds -- it keeps track of several paths, along with settings for each one. Thus, for your feature to work in a consistent and sane fashion, we'd have to make copies of all of the registered backgrounds. I don't know about you, but I don't appreciate software that auto-clutters my drive, and makes needless copies of files "for my convenience" :p. A better approach, in my mind, is to have someplace like "~/.wallpaper" and hardlink background images to that dir. Naturally, this could be preformed in an automagical, transparant fashion by the desktop whenever you add new images to the wallpaper selection list. Then, you have solved the problem of (a) following a moving target, and (b) not wasting (near as much) space. The drawback, of course, is that not all operating environments support hard-linking; I don't know if there are any such systems that GNOME cares about, but it is a portability factor nonetheless. IMHO, it is not the responsibility of the desktop to try and follow files around if you give it a path and then move the file, so this whole thing falls under "nifty feature", and so should just be excluded in environments where linking is not an option.
The problem with .wallpaper is that it will preclude things like active desktops, etc. But to clarify, I'm not talking about creating a copy of every wallpaper you have added, just the one currently active, that way until you change it, it'll be available even if you move it.
Moving to control-center / background.
Once the inotify stuff is reliably available, then we can add hooks to that. This way, everything will just happily get updated automatically when things move. Until then, I'm not going to add a bunch of nasty hacks to make one user happy. :)
Me too. I too thought I could delete the original file after I added it in the desktop background list.
Hm. There are several use cases where it would be nice to have gnome-background-properties (g-b-p) manage background _files_, which a inotify hack could not handle: - When you set a background directly from your brower; i.e. you open an image in your browser, right click it and choose "Set As Background". It would be best if g-b-p would handle this image as your browser does not know when you delete this image from the list in g-b-p. - When you alt-drag an image from a thumb drive to your desktop and choose to set it as your background. You wouldn't want to lose this background the next time you logged in. (This actually happened to me recently, and is how I came to find this bug report.) - When instead of moving a file, you delete it instead. This might not be an odd use case. A user might not want to manage his backgrounds in g-b-p AND in his file manager.
*** Bug 351896 has been marked as a duplicate of this bug. ***
These seem like corner cases to me. I would rather avoid making the preferences dialog be a file manager. I can see adding the feature having the reverse bug being filed as well. "I deleted the image from disk, but it's still in my wallpaper capplet." We shouldn't require users to remove things twice in all cases. If reasonable UI can be created to make this work, and the infrastructure can work so that the user can always only remove things ONCE to get rid of images, then we can work something into the capplet. Having to find the same image in multiple locations on disk and delete them all is not a reasonable solution.
If the wallpaper application doesn't want to manage files then why does it have a file list? We get the worst of both worlds now: - You need to keep the file list in the wallpaper application organised; - But you also need to make sure you don't move or delete your wallpapers in Nautilus.
It doesn't have a file list. It has a list of backgrounds. Backgrounds are comprised of images (which are files on disk) and of colors (which are not files, but merely a set of a few gconf keys which define colors and whether or not there is a gradient, and in which direction). In order to support images set to be the desktop wallpaper, from remote sources (http, ftp, smb, whatever), we obviously will need to cache those somewhere. However, just copying everything over is not the answer. We need a proper solution, rather than one that will make a few people happy, and a bunch of other people angry.
It really isn't clear from the interface that this is the model. For example, I was very surprised to find that the colour is stored per-image (pleasantly so, but still surprised). I see the case about "I deleted the image from disk, but it's still in my wallpaper prefs", so it seems to me that this is mostly a matter of rethinking to UI to better convey the working. One to refer to the usability list?
*** Bug 429222 has been marked as a duplicate of this bug. ***
*** Bug 530236 has been marked as a duplicate of this bug. ***
After almost 4 years this bug report is still open, shouldn't anything be decided already?
*** Bug 586124 has been marked as a duplicate of this bug. ***
I registered this problem for brainstorming http://brainstorm.ubuntu.com/idea/20305/
Copying the wallpaper image to ~/.wallpapers has become fairly popular suggestion at Ubuntu Brainstorm. In case, you think that is not a good idea, please file other suggestions to compete with it.
The bug (paper cut) reported in Launchpad: "Deleting an image that's used as a desktop wallpaper removed it as a wallpaper without notice" https://bugs.edge.launchpad.net/gnome-control-center/+bug/344228 Wallpapers should only change when users change them explicitly, or when they modify the source image. Some user stories exercising the appropriate behavior: Lola downloads a photograph of her boyfriend, todd.jpg, and sets the image as her wallpaper, either via appearance settings, or within EoG, Firefox, etc. If Lola opens the image afterwards in GIMP and does color correction, red-eye elimination, and crops the photo, these changes should be reflected in the desktop wallpaper. However, if Lola moves the photo from ~/Downloads to ~/Pictures, her wallpaper should not change. Later, if she renames ~/Pictures to ~/Photos, her wallpaper should not change. If she moves the photo to another partition, her wallpaper should not change. Celine saves a Facebook photo to her Desktop by dragging it from her browser window onto her Desktop. She then opens her appearance preferences and sets the image as her wallpaper. The next day, Celine sees an file names hd8dh8ed_djs9dh.jpg on her Desktop. She selects it and presses her delete key and the file is deleted. Her wallpaper does not fade to black at this point -- it remains unchanged. The crucial thing we are preventing here is the wallpaper changing without explicit user consent. Most users don't think like programs do, so may not understand why deleting a file (or worse, a seemingly unrelated folder) changes their wallpaper. We are only focused on the active wallpaper image -- not the entire set of photos that the user can choose from when opening her Appearance preferences.
*** Bug 615505 has been marked as a duplicate of this bug. ***
*** Bug 625349 has been marked as a duplicate of this bug. ***
We already do that for items that are remote, and will do it for items outside the Pictures directory or the stock items.