Bug 417730

Summary: Gwenview doesn't realise it's just opened an image from a "Tag" folder
Product: [Applications] gwenview Reporter: tagwerk19
Component: generalAssignee: Gwenview Bugs <gwenview-bugs-null>
Status: CONFIRMED ---    
Severity: minor CC: faure, goodaqua
Priority: NOR    
Version: 24.08.1   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Bug Depends on:    
Bug Blocks: 473661    

Description tagwerk19 2020-02-16 07:38:54 UTC 
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
Comment 1 Christoph Feck 2020-03-06 12:46:50 UTC 
Does Dolphin actually pass the tags:/ URL or does it pass the actual file to Gwenview? The issue might be in Dolphin.
Comment 2 tagwerk19 2020-03-07 07:56:58 UTC 
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.
Comment 3 Christoph Feck 2020-03-07 15:34:06 UTC 
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.
Comment 4 tagwerk19 2020-03-07 16:18:31 UTC 
(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:/
Comment 5 David Faure 2020-08-02 10:08:43 UTC 
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?