SUMMARY: Deleting a file in a 'Tag' Folder, the file is deleted rather than the tag removed. This is a change in behaviour, could be considered a regression. Previously when in a 'Tag folder', highlighting one or a collection of files and pressing 'Del' removed the tag from the files (after asking for confirmation). Now the files go to the wastebasket (without asking for confirmation) or with shift-del the files are permanently deleted (after asking for confirmation) STEPS TO REPRODUCE: Create a test file and apply a tag. Move to the 'tag folder' in Dolphin, highlight the file and press 'del' OBSERVED RESULTS Pressing 'del' deletes the file EXPECTED RESULTS Pressing 'del' removes the Tag SOFTWARE/OS VERSIONS Neon Testing: Dolphin : 20.12.0 Plasma : 5.20.4 Frameworks : 5.78.0 Qt : 5.15.2 Filesystem : Ext4 Kernel : 5.4.0-58-generic and Fedora 33: Dolphin : 20.08.03 Plasma : 5.20.4 Frameworks : 5.75.0 Qt : 5.15.2 Filesystem : BTRFS Kernel : 5.9.16-200.fc33.x86_64 The earlier/expected behaviour is still there in Fedora 32 Dolphin : 20.04.01 Plasma : 5.18.5 Frameworks : 5.73.0 Qt : 5.14.2 ADDITIONAL INFORMATION I think there's a regression here: If you are in one folder (a 'Tag' folder) and you delete a file, it disappears from a completely different folder. You may not notice and you may lose the file. That is bad... If you delete a 'Tag Folder' itself, the tags are removed from the files (so, the "earlier" behaviour), the files referenced are not deleted The alternative view is that you consider a 'Tag Folder' like a set of search results. In this case if you delete a file from the pane of search results, it is indeed the file that is deleted
Now going back and checking the 'before' and 'after' behaviour, I can see a subtle visual hint. Previously links from a "Tag Folder" were overlayed with a pair of tags motif (comparable the links of a chain motif when displaying a 'soft link'). That overlayed motif is now not there for files although it is there for folders. I fear the subtle hint was too subtle :-/ Having now recognised the hint I can see a comparison to soft links, deleting a soft link does not delete the destination file. Previously, deleting a file from a "Tag Folder" (showing the overlayed motif) also did not delete the referenced file. I stumbled on this after discovering Bug 431053. I tried moving a collection of files from one "tag folder" to another, noticed that they did not disappear from the original tag folder, thought "Strange??", and then pressed "Del". There is a potential trap here...
This is intended. Every other IO slave uses these semantics. Deleting means deleting/trashing, not modifying the file. You can only delete/trash files with a tag with these semantics. You can still remove tags from the context menu and using the information panel.
Fair enough.
Let me try out the functionality in the information panel. Maybe a 'Del' isn't the right key to be mapped to removing the tag. I'd argue that the functionality be visible in the context menu though, so that someone can see that there are two options - of deleting the highlighted files and removing the tag from them. Not sure of the etiquette of reopening bugs. If I've got it wrong, apologies...
Created attachment 134669 [details] Mockup of 'Remove Tag' option in context menu > Let me try out the functionality in the information panel. Works for me in test systems with a small number of tags but it is pretty unwieldy when you have many hundred tags: You have to scroll through a large number of potential tags to find the one you want to remove. As this is an "edit" rather than a "remove", you are given the full list of tags so you can select as well as remove tags. It is also possible, although maybe an unusual case, that you have tags of the same name at different places in a hierarchical tag structure and have to be careful, as you scroll, to pick the correct one. Comparing 'Assign Tag' and the 'Edit' in the information panel: Can see that these work differently. 'Assign Tags' does a better job of showing 'just' the tags that have been selected but it also unwieldy unless you have organised your tags so that there are only a small number of "top level" tags. 'Assign Tags' only appears if you select a single file, so it doesn't help if you've assigned the 'wrong' tag to many files and want to remove it.... When I explore the Dolphin 'context menu' options, I see that there are 'services' that can be added or removed Maybe the solution is to have a 'Remove Tag' service that can be installed in parallel with 'Move to Trash' - something like the attached
Created attachment 134670 [details] Mockup of 'Remove Tag' option in context menu Corrected image...
Consider this a "Ping..." > I stumbled on this after discovering Bug 431053. I tried moving a > collection of files from one "tag folder" to another, noticed that > they did not disappear from the original tag folder, thought > "Strange??", and then pressed "Del". The behaviour's still there and it is, from my perspective, a trap... STEPS TO GET YOURSELF INTO TROUBLE Create two images, assign Tag1 to one and Tag2 to the second Open Dolphin in split screen mode, open tags:/Tag1 in one half, tags:/Tag2 in the second half Drag the image from tags:/Tag1 to tags:/Tag2, chose 'Move', notice that it does not disappear from the tags:/Tag1 ... This is Bug 431053 Highlight the image that has not disappeared and press 'Del', nothing obvious happens, there's no pop-up prompt the image does not disappear. ... Maybe related to Bug 416171 Refresh the tags:/Tag1 panel and see that the image has gone. Refresh the tags:/Tag2 panel and see that the image has also gone from that. The file has been deleted - the good news is only as far as the Wastebasket, provided you remember to check there...
Above was with... Neon testing Plasma : 5.21.1 Frameworks : 5.80.0 Qt : 5.15.2
Dolphin is a file manager. With any other protocol, when you hit "Del" with a selected file, the file is trashed (deleted with Shift-Del). Is this a trap too? Btw, there already is a "Assign Tags" context menu option, which can be used to remove tags.
(In reply to Stefan Brüns from comment #9) > With any other protocol, when you hit "Del" with a selected file, the file > is trashed (deleted with Shift-Del). Is this a trap too? I don't know... I think it would depend on whether I was deleting the 'canonical' form or a link to it. Sorry, that's a bit vague. However I'd compare deleting a file from a "tag folder" to deleting a softlink, tags are, more-or-less, like links. In a test case with: ln -s ~/testfolder/testfile the softlink is clearly signalled as such and deleting it removes the softlink and not the target file. > Btw, there already is a "Assign Tags" context menu option, which can be used > to remove tags. I tried to summarise my experiences in: https://bugs.kde.org/show_bug.cgi?id=431093#c5 I think there's a potential way round the issue mocked up here: https://bugsfiles.kde.org/attachment.cgi?id=134670
(In reply to Stefan Brüns from comment #9) > Dolphin is a file manager. I think of it more as... Dolphin is a file manager with superpowers :-)