when i rectangle a group of pictures icons on my desktop and open them in gwenview i’m presented with a view showing all of the selected items so i can weed thru them.
when i click on one to delete it from the group, my expectation is that it will delete the file from my desktop, not just hide the image from the gwenview window.
but when i’m done weeding and go back to the desktop the files remain unaffected by my efforts.
is this how it’s supposed to work? or more importantly can it be made to work as expected?
without this ability it kinda makes using qwenview to weed thru stacks of images rather pointless.
When you do that, currently gwenview create a temporary directory containing symlinks to the original files, so you can edit them, but if you delete them, you only delete the symlink. This allows users to delete from their selection to copy it someplace else, without touching the originals.
I don’t think changing this behavior would be good, since some users want this behavior, and it fulfills a usecase that woudn’t work if we were to remove the original files.
can you suggest another tool then besides the default one that comes with KDE?
the image viewer seems like the perfect tool for my use case, but alas someone with another use case has beaten me to it by hobbling gwenview’s ability to change the original files.
my use case is, i need to work with the files directly to inspect, rotate, crop, and delete in order to weed thru a selection of images on the fly … this use case is far more important to me than the one you describe.
suggestion: perhaps gwenview could make this symlink session behavior more obvious to the user instead of offering to “delete” files when in reality it is only “remove from selected”
in order to make the symlink session more productive there would need to be BOTH a “remove from selected” option in addition to a “delete” option so that when when i go to “save” my gwenview symlink session, all the changes made to the original selection that started the session would be made to the original set of files … including deletions.
It does it somewhat already, when you open selected files you can the path of the directory is like /tmp/gwenview-kZnMYd/, but adding something to the files to make them appear as symlinks would be best indeed. (italic on filename | icon | overlay…).
I am not sure adding a “delete” original file in symlink cases is really useful and brings more questions, should it be default when I press “delete” ?
Your use case is already fullfilled in gwenview after all, open your desktop folder in it.
Anyway feel free to open a feature request in bugs.kde.org.
i did notice that… if you try to do file operations like open folder it takes you to the tmp folder instead of the desktop, but it was only confusing to me in the context of the desktop.
the whole philosophy of the desktop-as-a-metaphor is that you are working with a selection of the actual objects on your desktop, not an abstraction in a tmp file somewhere else.
i would rather find an image viewer that respects that philosophy than try to force gwenview to conform to a philosophy it was clearly not designed for.
it’s too bad tho, it’s otherwise a nice project and being the flagship for the KDE desktop leaves me a little disappointed that i have to look elsewhere.
That’s completely adjacent to this situation.
When you launch gwenview that‘s not the desktop anymore. The select files in /tmp folder behavior is gwenview’s and happens with any folder.
You can remove files from your desktop directly.
If you would open desktop:/ in gwenview that would also work fine.
then i have failed to communicate my issue… allow me to try again.
when i select a subset of image files from a folder (like ~/Desktop) and open them in an image viewer (right click, open with ____), my expectation is that i will be working with those files in the image viewer.
if one of the actions offered by the image viewer is to delete the image, then my expectation is that it should delete the image file from the folder.
gwenview with it’s /tmp folder behavior in this situation, adds an additional layer of abstraction that is unnecessary and unwanted for this simple use case.
i’m currently wading thru half a dozen alternatives to gwenview and so far none of them fail to delete the original image file when the “delete” action is selected from the UI in this situation.
after running thru 10 other image viewer packages, it’s become clear that qwenview is the outlier when it comes to how it deals with files.
while gwenview will save your alterations (rotate, flip, crop) back onto the original files at the end of the session, it will not delete the original files even if that was one of your operations during the session.
all of the other packages tested will make the changes directly to the selected files, including delete, in real time as you use the interface (the expected behavior).
gthumb is the winner for ticking all the boxes on my use case, despite the gnome like UX… i could select a group of files on the desktop, navigate thru each one in turn with the arrow keys, zoom with the mouse wheel, it includes a thumbnail overview of the selected files (and only the selected files), has all the basic image manipulation tools (and then some), will print to a printer, and most importantly will delete a file if you hit delete!
nomacs was the runner up even tho it would show you all the images in the folder (ignores the original selection if you navigate past the end of the selection) but otherwise ticked all the boxes and had a cleaner Qt UX… would like to see the folder issue resolved.
viewnior deserves an honorable mention for a promising package if it can just tick a few more boxes, like navigable thumbnails, print to a printer and some more work on the UX for the basic tools like flip and crop.