Comment 25 for bug 344228

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.