Deleting an image that's used as a desktop wallpaper removed it as a wallpaper without notice

> I'd suggest that when someone sets something as the wallpaper,
> it stores a copy of that image somewhere else to prevent things like this from happening.

No, I'm against. I don't want duplicates of my wallpapers falling somewhere on my HDD. What a disk space loss!

Better display a popup "(Re)moving this image will cause you to loose your current wallpaper" but not dupe my files...

I think this is a good decision. There should be somewhere in home where all previous wallpapers are stored, so that you can revert to previously used (now deleted) images.

There should be, however a limit on this. Maybe there should be a size limit on what can be stored (which can be set by the user on the Background tab from the desktop menu). If this limit is reached, the oldest/least used wallpapers are deleted?

Most machines these days aren't short of a few billion bytes, and those that are would be able to set a really small size limit (a rough estimate set at installation time).

Well I don´t know if we need to save previous wallpapers too, but at least a copy of the current wallpaper should be kept. That would use only the size of one wallpaper.

Even better, use a hardlink that changes when you change the active wallpaper. No extra file system use while you still have the original file on your system and once you change the active wallpaper the extra copy goes away.

However, I'm not sure this qualifies as a paper cut bug as that would probably require quite a bit of code written. I'll let someone else decide though.

A copy should be fine, and if one remove's it from the Appearance window, then the copy is deleted.
Disk space is cheap and background images are usually small.

Making a copy of the image is a lot cheaper than adding a hack to Nautilus which it runs when an image gets deleted ;)

I'm confirming this one, if nobody minds. Even I (and I consider myself reasonably knowledgeable) feel pretty overwhelmed when it comes to adding wallpapers, because I know that if I move or rename the image I will lose my beautiful catalogue of wallpapers! Thus, I usually make a copy into a special folder anyway. It is tremendously annoying (and kind of saddening) when wallpapers just disappear, since I spend lots of time collecting them and setting the appropriate styles. Further, it is currently impossible to set a remote image as a wallpaper since there is no convention in place for where the image should be placed.
People who aren't aware of the details involved are bound to encounter issues at some point, as described here.

A very simple fix could resolve the issue.

Okay...I have an idea and maybe I should post it to Brainstorm, however since this popped into my head while reading through this I thought I would post it here. Why not put a folder in the home folder specifically labelled "My Wallpapers" Then users would know to put a copy of their wallpapers in this folder and it would always be available as an option when one goes to change it. There could be a code that put a copy of any image right clicked and utilized as a wallpaper. With it being a default wallpaper folder, then users like me who collect wallpapers will always have a default folder to drop them into.

You have my complete support. I think it will put all the lights inside the
tunnel!...

2009/6/23 Diggs808 <email address hidden>

> Okay...I have an idea and maybe I should post it to Brainstorm, however
> since this popped into my head while reading through this I thought I
> would post it here. Why not put a folder in the home folder
> specifically labelled "My Wallpapers" Then users would know to put a
> copy of their wallpapers in this folder and it would always be available
> as an option when one goes to change it. There could be a code that put
> a copy of any image right clicked and utilized as a wallpaper. With it
> being a default wallpaper folder, then users like me who collect
> wallpapers will always have a default folder to drop them into.
>
> --
> Deleting an image that's used as a desktop wallpaper removed it as a
> wallpaper without notice
> https://bugs.launchpad.net/bugs/344228
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

In my opinion, this is not a real bug.

If you delete an image, it can no longer be opened. That's true for every file.

As the original poster stated, his wallpaper changed immediately. So he can restore the file from trash and learned his lesson, no harm done.

But on the other hand I can kind of understand the usability implications of this.

If this is supposed to get solved, then I suggest the following solution:

The thumbnail viewer when changing the background will show the files in /usr/share/backgrounds and ~/.local/share/backgrounds

If a new wallpaper gets chosen it is copied to the user folder, the button "Remove" in the wallpaper dialog gets replace with a "Delete" button

This is pretty much the same behaviour as the theme chooser btw.

The implementation however doesn't seem trivial to implement, so I am not sure if this is really a papercut

The easiest most practical solution is to just have a
~/.config/current-background.jpg file to which the wallpaper is copied
the moment you set it as wallpaper. No lessons to be learned or files
to be restored. The solution you propose could be implemented but is
indeed far more complicated and doesn't seem to have any additional
benefits.

On Wed, Jun 24, 2009 at 5:58 PM, Tim Fuchs<email address hidden> wrote:
> In my opinion, this is not a real bug.
>
> If you delete an image, it can no longer be opened. That's true for
> every file.
>
> As the original poster stated, his wallpaper changed immediately. So he
> can restore the file from trash and learned his lesson, no harm done.
>
> But on the other hand I can kind of understand the usability
> implications of this.
>
> If this is supposed to get solved, then I suggest the following
> solution:
>
> The thumbnail viewer when changing the background will show the files in
> /usr/share/backgrounds and ~/.local/share/backgrounds
>
> If a new wallpaper gets chosen it is copied to the user folder, the
> button "Remove" in the wallpaper dialog gets replace with a "Delete"
> button
>
> This is pretty much the same behaviour as the theme chooser btw.
>
> The implementation however doesn't seem trivial to implement, so I am
> not sure if this is really a papercut
>
> --
> Deleting an image that's used as a desktop wallpaper removed it as a wallpaper without notice
> https://bugs.launchpad.net/bugs/344228
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in One Hundred Paper Cuts: Confirmed
> Status in Ubuntu: New
>
> Bug description:
> I saved an image to my desktop (it was the django pony wallpaper (http://www.djangopony.com/)). I then set this as the desktop wallpaper by right clicking on the desktop and selecting "Change Desktop Wallpaper". A while later (today), I wanted to clean up my desktop and right clicked on the image, and selected "Delete". A popup warned me that this would remove the image. I clicked OK and the image disappeared. However my desktop wallpaper changed immediatly to a dull brown colour.
>
> Obviously there is only one copy of the image stored when you set something as the wallpaper, however I thought it was otherwise. I'd suggest that when someone sets something as the wallpaper, it stores a copy of that image somewhere else to prevent things like this from happening.
>
> $ lsb_release -rd
> Description:    Ubuntu 8.10
> Release:        8.10
>

I agree with the hard link idea. Correct behaviour and faster than a copy.

$HOME/.config/current-background is fine (I wouldn't name it .jpg - suppose I use a PNG or TIFF for my wallpaper? It doesn't matter whether or not it has an extension anyway, Nautilus or xloadimage can tell what it is.)

Hard links don't work across mount points. So if the user picks a wallpaper that does not reside in his/her home folder it may not work depending upon how their system was set up.

For example I had a system where most of my image/music data was on a separate mounted volume from my home directory. Hardlinks wouldn't work in this case. Symlinks would but then you're back to the loss of wallpaper on delete issue.

So we copy instead of hard link in that case. In the common case it still does the job and doesn't waste any HD space.

Copying only one image to some predefined location is a bad solution IMO, and here's why:

when a user opens the wallpaper configuration, there are two buttons at the bottom, Add and Remove. When he now adds an image, what should happen in your opinion? Should the old wallpaper be overwritten or should there be a dialog asking so? Maybe the user wants to keep the old wallpaper.

This is even worse than the current situation, because right now, the user must explicitly delete the wallpaper himself.

The hard link seems also impractical, so I still stand by my proposed solution a few posts up.

Don't those buttons just make soft links to an existing image in some directory when "add"ed and delete them when "remove"d? I would think nothing changes.

When the user selects a wallpaper the original image is copied over the ~.gnome/background/current file and displayed from there. The only issue I see is if the user would expect "remove" to clear the current wallpaper from the desktop.

You could compare the original file that the link being deleted is pointing to ~.gnome/background/current and unlink ~.gnome/background/current if it is the same file. Personally I don't think that would be worth the effort.

OK, I should have looked before posting. There are no soft links, there is simply an entry in an xml file added to populate the wallpapers on that menu. ~/.gnome2/backgrounds.xml is the file. There should be no change required to the System->Preferences->Appearance menu to address Tim's concern.

My paths are a bit wonky above. They should be closer to ~/.gnome2/background/current. That would leave room for later functionality add of ~/.gnome2/background/previous[0-9] if someone thought that was important.

I experienced this as well, but when moving the image file. For me, as a user, I figured GNOME would follow the path of the image and replace it for my wallpaper, all without me knowing.

I rather this than have a dialogue pop up warning me that I'm moving my wallpaper. If I delete my wallpaper image, then why would I expect it to stay as the background? That just doesn't make sense.

Thus, I say track the wallpaper path, rather than warn the user with a dialogue.

Sounds like we need an inotify watch for the active wallpaper which
will update the location when it moves. Detecting a deletion should be
possible with this approach as well, though the behavior here would
need to be defined, specifically, where does the image get copied to.
David, any thoughts on that?

Mike, you can see from the use case in duplicate bug #420309 that the
image may need to be backed up to a safe location when it is set, not
when it is deleted.

If it is backed up to a safe location when it is set, and then your
example user modifies her boyfriend's picture, when she deletes it
won't she get the old picture as her background?

David Siegel,
There is also another problem with backing up the file, there are scripts which allow to randomly keep switching wallpapers , so this would lead to lot of unnecessary read-writes.

What Michael said makes sense , inotify watch for the active wallpaper is better...
For the use case when the image is in an external drive.
On trying to remove the drive, System should warn that the wallpaper image is on external drive and needs to be copied to hardisk.

This would be better.

On Fri, Aug 28, 2009 at 10:00 AM, mac_v wrote:
> On trying to remove  the drive, System should warn that the wallpaper image is on external drive and needs to be copied to hardisk.

I think the conclusion is that we don't want a warning, it should just
work and stay out of the user's way. So in this case it should be
transparently copied to a chosen location before / after trashing.

Michael Rooney wrote :
> So in this case it should be
> transparently copied to a chosen location before / after trashing.

That would work even better. just copy the file to the ~/Pictures before unmounting the drive.

I still think a hardlink is the best way to go for the common case (picture on main drive/partition) as there is no read/write overhead or extra space wasted.

I think the idea that users expect a file to be their wallpaper is a bit unrealistic. Many users would like to set their wallpaper in ways that are completely different from interacting with actual files -- right clicking an image in Firefox, for instance (where it's called "desktop background"). Interacting with files is a completely different task than changing the wallpaper, and even very technically savvy users like myself wouldn't expect it change then. The same can be said of modifying pictures or moving files around.

In the case of Firefox, it will silently download and copy the file (to ~/Firefox_wallpaper.png), so other places where you set the desktop background should do the same thing (this includes the image viewer, so I'm opening an Eye of Gnome task).

All places where you set the wallpaper should act consistently -- The control center add button, Firefox, Eye of Gnome, and others. The only way I can see to preserve the wallpaper is to copy the file outright to a special wallpapers folder; a hard link will change the wallpaper when the file changes (not a safe assumption), and a soft link will cause the same problem that opened this report.

Doing this will use up a small amount of disk space, however it will organize everything for the user and not mysteriously delete files - I think the few megabytes is worth it in most use cases. If you are concerned about disk space like Jakub is, you can then use the remove button and have it deleted without losing the original file; only if we keep a special wallpapers folder is it safe to have the remove button actually delete files rather than just scrub them from the list.

This also enables a new feature: the wallpaper chooser can act consistently as a tool for looking at previous wallpapers. This is especially important when you're about to switch wallpaper: if we only copy (or link) the current wallpaper, then we'd lose it as soon as the user changes the wallpaper, losing the ability for them to undo.

Ok i forgot we havent pushed 3.6 yet so set it for 3.5

This is fixed in g-c-c 3. We could get it in natty if someone works on backporting the change
Comments from gnome-control-center developer:
"We already do that for items that are remote, and will do it for items outside the Pictures directory or the stock items."

(If wallpaper is not in pictures directory, it will just be copied.)

Not a bug in firefox.