Image from removable device set as background not kept

Bug #62291 reported by Hervé Fache
2
Affects Status Importance Assigned to Milestone
KDE Base
Unknown
Wishlist
kdebase (Ubuntu)
Invalid
Wishlist
Unassigned

Bug Description

Binary package hint: kdesktop

- user adds removable device (USB key)
- user selects image from device as desktop background
- user removes removable device
- user restarts computer
-> image is gone

Suggestion: keep the desktop image in a local cache: $HOME/.kde/share/config/kdesktop/kdesktop.image seems a good place; the complete original path of the image should still be kept in $HOME/.kde/share/config/kdesktoprc.

Revision history for this message
In , Sébastien Laoût (slaout) wrote :

Version: (using KDE KDE 3.2.1)
Installed from: Mandrake RPMs

Sometimes I drop a wallpaper to KDesktop, and then move the file.

I suppose dropping from internet webpage from konqueror would also make problems if internet isn't available ?

In those cases, the next time KDE starts the wallpaper is lost.

Would it be better to save the image to a wellknown folder (~/.kde/foo/bar) ?
Then user can make what he want, its image would be stucked to one location !

Isn't it ?

Revision history for this message
In , Matías Costa (m-costacano) wrote :

I confirm the bad behaviour. When you drag a image from konqueror and drop it to kdesktop, appears a "set as wallpaper" option in the menu. This is a very convenient way to set the wallpaper. But the image is saved to /tmp/kde-$USER/kdesktop$RANDOM/$RANDOM.tmp. Where $USER is the user, and $RANDOM are diferent random strings. After a reboot the /tmp directory is clean and the image lost.

Revision history for this message
Rocco Stanzione (trappist) wrote :

I've never expected this behavior (successfully using an image that's been removed) but it would be a very nice feature. I wouldn't feel so nervous about moving my image directories around.

Changed in kdebase:
importance: Untriaged → Wishlist
Revision history for this message
In , 6-info-a (6-info-a) wrote :

*** Bug 134629 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Hervé Fache (rvfh) wrote :

Suggestion: keep the desktop image in a local cache:
$HOME/.kde/share/config/kdesktop/kdesktop.image seems a good place; the
complete original path of the image should still be kept in
$HOME/.kde/share/config/kdesktoprc.

Changed in kdebase:
status: Unknown → Confirmed
Revision history for this message
Anthony Mercatante (tonio) wrote :

I'm rejecting this for 3 reasons :
- caches are *evil* and are to be avoided as much as possible, since it is a pain for the user to figure out what happens when it gets corrupted (look at the DNS cache on Windows XP for a good example).
- that normal behavior, and implementing this would mean lots of work or a very, very low usage.
- why not the same over smb shares, ftp, nfs or any remove location accessible via vfs or ioslmave ? If we start even thinking of implement this, we would never see the end...

Changed in kdebase:
status: Unconfirmed → Rejected
Revision history for this message
Hervé Fache (rvfh) wrote : Re: [Bug 62291] Re: Image from removable device set as background not kept

You entirely missed the point.

But as Simon Law reported it upstream, and I then added my comments
there, it will hopefully get fixed in the next KDE release.

Changed in kdebase:
importance: Unknown → Wishlist
Changed in kde-baseapps:
status: Confirmed → Unknown
Revision history for this message
In , Nate-b (nate-b) wrote :

Hello!

This feature request was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this feature request is already implemented in Plasma 5, or is no longer applicable.

Accordingly, we hope you understand why we must close this feature request. If the requested feature is still desired but not implemented in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting

If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging

Thanks for your understanding!

Nate Graham

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.