SUMMARY: If you click on an image from "tag" folder, it opens the image in gwenview. If you then step through the collection of images with "Go to next image" or "Go to previous image", you step forward and back through the files in the filesystem folder STEPS TO REPRODUCE: 1. Create a couple of subfolders under ~/Pictures, say, 2020-02-10, 2020-02-11 2. Create image files in these folders, for example: ~/Pictures/2020-02-10/image1.png ~/Pictures/2020-02-10/image2.png ~/Pictures/2020-02-11/picture1.png ~/Pictures/2020-02-11/picture2.png 3. Tag image1.png and picture1.png with a tag "mytag", leave the other images untagged. 4. Open the tags:/mytag/ folder in Dolphin, click on image1.png and open it in Gwenview, then click on the "Go to next image" button OBSERVED RESULTS: The next image displayed is the (untagged) image2.png EXPECTED RESULTS: The next image should be next in the "Tag" folder, picture1.png SOFTWARE/OS VERSIONS: Gwenview 19.12.2 from Neon 5.18 KDE Plasma 5.18.0 KDE Frameworks 5.67.0 Qt 5.13.2 ADDITIONAL INFORMATION: Gwenview _does_ understand tag folders. If you switch to the browse view and type "tags:/mytag/" into the folder field, you will see the selected files and the "Go to" buttons will take you forward and back though tagged images. The issue is that when opening Gwenview from Dolphin, it opens in the context of the filesystem folder. Not a regression, was checking this before 5.18
Does Dolphin actually pass the tags:/ URL or does it pass the actual file to Gwenview? The issue might be in Dolphin.
Yes, seems to be the case. With an strace: strace -o trace -t -f /usr/bin/dolphin tags:/mytag and looking for the exec: grep gwenview trace | grep exec I get: 3128 08:40:15 execve("/usr/bin/gwenview", ["/usr/bin/gwenview", "/home/test/Pictures/2020-02-10/i"...], 0x56373a8ce270 /* 63 vars */ <unfinished ...> If I launch gwenview from the command line: gwenview Pictures/2020-02-10/image1.png displays "image1.png" and the next image is the next image in the "Pictures/2020-02-10" folder and gwenview tags:/mytag/image1.png displays "image1.png" and the next image is the next image in the "mytag" tag folder. So yes, gwenview on its own works as expected.
Desktop file says %U, so it is expected that Gwenview can open any URLs. Not sure if virtual URL protocols like tags:/, desktop:/, or trash:/ need to be specified separately in the desktop file. The 'Protocols' key is deprecated. Needs input from a KIO developer; adding David.
(In reply to tagwerk19 from comment #2) > Yes, seems to be the case. Whups, that might have been that was ambiguous... as I read the 'execve' call in the strace, dolphin uses the filesystem directory, not the tags:/
Christoph: X-KDE-Protocol still exists, and allows to list supported protocols. The special value "KIO" means all protocols supported by KIO, and is assumed by default for apps with "KDE" in "Categories" (desktopexecparser.cpp:204). But the problem here is that Dolphin resolves the tag URL to a file URL before all this. DolphinViewContainer::slotItemActivated: KRun *run = new KRun(item.targetUrl(), this); And kio_tags sets UDS_TARGET_URL to the local file path, i.e. it's actually asking for this to happen. git log says this goes back to the big rewrite, so no specific justification. Someone who actually uses tags (I don't) could try commenting out the only line that mentions UDS_TARGET_URL in baloo/src/kioslaves/tags/kio_tags.cpp and testing that in multiple ways to find out if anything would break. I can't really test any of this here; I was able to tag a few files, and the tag does appear on the right panel in dolphin when selecting the file, but clicking on it says "tags:Foo does not exist", and tags:/ is empty. And I have to create the tag every time, it doesn't get stored. I guess I disabled something somewhere long ago?