Bug 474819

Summary: Category and context menu items appear in random order
Product: [Applications] kphotoalbum Reporter: Andreas Schleth <schleth_es>
Component: Thumbnail ViewerAssignee: KPhotoAlbum Bugs <kpabugs>
Status: RESOLVED FIXED    
Severity: wishlist CC: johannes
Priority: NOR    
Version: GIT master   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: attachment-1790554-0.html

Description Andreas Schleth 2023-09-23 20:39:59 UTC
SUMMARY
Items in context menus and categories in thumbnail view appear in random order.

STEPS TO REPRODUCE
1. Start KPA
2. Thumbnail view (configured to show categories below the thumbs)
3. Note the sequence of the categories
4. right click on any thumbnail and click on "open with ..." or "edit with ..."
5. a list of applications appear (if you have some installed) 
6. Note the sequence - it is probably different for "open" and "edit"
7. Close KPA and start over with #1

OBSERVED RESULT
* The sequence of the categories most probably have changed
* The sequences of the external apps have changed too and are different for the two menus even if they contain the same apps.

EXPECTED RESULT
* It would be somewhat helpful, if the sequences stayed the same all the time. Any ordering/sorting scheme would do, but alphabetical (by category or app) comes to mind.

WHY?
* If you use the menus quite often, you click by muscle memory without really reading the entries every time.  
* Sorting would improve the user experience.  [Just imagine, the "File ... " entry always changing place in the main menu - Unthinkable!]

SOFTWARE/OS VERSIONS
KPA: v5.11.0-92-g28815029
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8 

ADDITIONAL INFORMATION
Comment 1 Johannes Zarl-Zierl 2023-09-23 22:46:47 UTC
Git commit 4ea7445fb79da43637d3b585053ac11f16256c00 by Johannes Zarl-Zierl.
Committed on 24/09/2023 at 00:42.
Pushed by johanneszarl into branch 'master'.

Sort categories/tags in thumbnail view

Sort categories and tags if "Show Categories in Thumbnail Window"
ist enabled, so that their order is always the same.

M  +5    -10   ThumbnailView/ThumbnailModel.cpp

https://invent.kde.org/graphics/kphotoalbum/-/commit/4ea7445fb79da43637d3b585053ac11f16256c00
Comment 2 Johannes Zarl-Zierl 2023-09-23 22:47:59 UTC
Thanks for the bug report!
I've fixed the one problem already and can confirm the issue in the open/edit application menu.
Comment 3 Andreas Schleth 2023-09-23 23:25:04 UTC
Thanks!
I was just trying to check for myself and then:
"fatal: konnte nicht auf 'https://anongit.kde.org/kphotoalbum/' zugreifen: The requested URL returned error: 502"
...
I'll be a.f.k. for ~10 days and then check again.
Comment 4 Johannes Zarl-Zierl 2023-09-25 20:22:29 UTC
I've reworked the entire popup - the way things currently are, I could simply use an alphabetically sorted list, but l think we should at least approximate the user preference that you get in the file manager etc.
The way I would approach the issue is by only having the subset of applications that do support all selected files, not the superset of applications that support any of the selected files and then exclude unsupported files when opening a given application...

Take a look - what do you think?
https://invent.kde.org/graphics/kphotoalbum/-/commit/109ceff206d958467307cd837e6cf61f38b454c1
Comment 5 Bug Janitor Service 2023-09-25 20:23:00 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/kphotoalbum/-/merge_requests/29
Comment 6 Andreas Schleth 2023-09-26 16:07:02 UTC
Created attachment 161889 [details]
attachment-1790554-0.html

As i said, i am a.f.k until 5.10. ... but then, i'll test it. Cheers, Andreas

Am 25. September 2023 22:22:29 MESZ schrieb Johannes Zarl-Zierl <bugzilla_noreply@kde.org>:
>https://bugs.kde.org/show_bug.cgi?id=474819
>
>--- Comment #4 from Johannes Zarl-Zierl <johannes@zarl-zierl.at> ---
>I've reworked the entire popup - the way things currently are, I could simply
>use an alphabetically sorted list, but l think we should at least approximate
>the user preference that you get in the file manager etc.
>The way I would approach the issue is by only having the subset of applications
>that do support all selected files, not the superset of applications that
>support any of the selected files and then exclude unsupported files when
>opening a given application...
>
>Take a look - what do you think?
>https://invent.kde.org/graphics/kphotoalbum/-/commit/109ceff206d958467307cd837e6cf61f38b454c1
>
>-- 
>You are receiving this mail because:
>You reported the bug.
Comment 7 Johannes Zarl-Zierl 2023-09-26 19:04:18 UTC
No worries - I didn't realize that you would even read the notifications before October 5th...
Comment 8 Johannes Zarl-Zierl 2023-10-02 19:41:48 UTC
Git commit 64a72ece78165ed7c3971285992ccf5682f9f1b8 by Johannes Zarl-Zierl.
Committed on 02/10/2023 at 21:41.
Pushed by johanneszarl into branch 'master'.

Rework gathering of applications for ExternalPopup

Instead of offering the sum of all services for a file list, offer the
list of services that can handle all files in the file list.

This has the benefits:
 - The user actually gets to open all files in the list with the
   applications, without some files being filtered out
 - It is now possible to mostly honor the application preferences set by
   the user instead of presenting a set of randomized order.

M  +47   -20   MainWindow/ExternalPopup.cpp
M  +12   -9    MainWindow/ExternalPopup.h

https://invent.kde.org/graphics/kphotoalbum/-/commit/64a72ece78165ed7c3971285992ccf5682f9f1b8
Comment 9 Andreas Schleth 2023-10-07 21:07:51 UTC
Hi Johannes, now - finally - I did some testing:

a) the categories in thumbnail view seem to be in a static sequence now. Good, check!

b) the options with what external program to open something are static (good!), but still different for different file types (for the same media type). I just checked for video (this is where I always use the "open with external program" path):
*.mkv: QtAV QML Player - QtAV Player - QMPlay2 - VLC - Enqueue with QMPlay2
*.mp4, *.webm, *.mpg: VLC - QMPlay2 - GPAC - QtAV - Enqueue... - QtAV QML (+ Audacity only for .mpg)
* mov: QMPlay2 - VLC - QtAV QML Player - Enqueue... - QtAVPlayer 

Now I see, that the lists have sometimes different entries for different types. But these lists are not even complete/correct. Examples: 
*.mp4 opens in Audacity too (as the .mpg) - if the sound codec is recognized in Audacity.
*.mov opens and plays in GPAC which is not in the list. 
[How do you find the apps that should work and how do you determine if a file type is suitable for an app?]

To differentiate which program can play a *.mkv or *.mp4 file successfully cannot be determined by the file extension alone, as these files are just containers for a host of different codecs (most/all? video files are). Depending which AV-libraries are installed, some may play others may play not.

[The real use cases for me are: images: open in Gimp, videos: play with VLC - all the others are (for me!) just a distraction. If I ever need to open a video in Audacity, the generic "open with ..." would do nicely. Others would have other preferences.]

So, what to do about this? I can think of:
a) make the list dependent on media type only (and have some programs throw an error if they cannot understand a certain codec - most do this nicely)
    or
b) let the user configure this list in the settings (for each media type)
    and/or
c) let the user configure a preferred viewer for this media type = the action that comes with a double click in thumbnail view (I would choose the internal viewer for images and VLC for video)

I guess a) should be the easiest path forward as b) and c) would need lots of additional UI.

However, since most of my videos are *.mp4 I like the current solution already a lot better than the old state :-)

Cheers, Andreas
Comment 10 Johannes Zarl-Zierl 2023-10-08 10:54:00 UTC
Hi Andreas, thanks for taking the time. See my responses below...

(In reply to Andreas Schleth from comment #9)
> b) the options with what external program to open something are static
> (good!), but still different for different file types (for the same media
> type). I just checked for video (this is where I always use the "open with
> external program" path):
> *.mkv: QtAV QML Player - QtAV Player - QMPlay2 - VLC - Enqueue with QMPlay2
> *.mp4, *.webm, *.mpg: VLC - QMPlay2 - GPAC - QtAV - Enqueue... - QtAV QML (+
> Audacity only for .mpg)
> * mov: QMPlay2 - VLC - QtAV QML Player - Enqueue... - QtAVPlayer 

I assume that for each file type the options are the same ones that you get in dolphin? If so, than this would be the intended behaviour...

> Now I see, that the lists have sometimes different entries for different
> types. But these lists are not even complete/correct. Examples: 
> *.mp4 opens in Audacity too (as the .mpg) - if the sound codec is recognized
> in Audacity.
> *.mov opens and plays in GPAC which is not in the list. 
> [How do you find the apps that should work and how do you determine if a
> file type is suitable for an app?]

The list is compiled from KApplicationTrader::queryByMimeType() [1]. If there's more than one mime type, only applications that support all given mime types are displayed.

[1] https://api.kde.org/frameworks/kservice/html/namespaceKApplicationTrader.html#acd651d14667b2437ce7bf056b81ead8a


> To differentiate which program can play a *.mkv or *.mp4 file successfully
> cannot be determined by the file extension alone, as these files are just
> containers for a host of different codecs (most/all? video files are).
> Depending which AV-libraries are installed, some may play others may play
> not.

I would say that this is a problem that is out of scope for kphotoalbum. We already are querying by mime type of files, not file name suffix. Dynamically determining the list of installed codecs and adapting the application list accordingly would have to be done in the KService framework.

> [The real use cases for me are: images: open in Gimp, videos: play with VLC
> - all the others are (for me!) just a distraction. If I ever need to open a
> video in Audacity, the generic "open with ..." would do nicely. Others would
> have other preferences.]
> 
> So, what to do about this? I can think of:
> a) make the list dependent on media type only (and have some programs throw
> an error if they cannot understand a certain codec - most do this nicely)

This is what is currently done.

> b) let the user configure this list in the settings (for each media type)

I would really dislike taking this approach. Having a different list of preferred applications in dolphin/Gwenview/etc. and KPhotoAlbum does not seem like a good user experience.

> c) let the user configure a preferred viewer for this media type = the
> action that comes with a double click in thumbnail view (I would choose the
> internal viewer for images and VLC for video)

This is basically feature request #468134. I'm not opposed to adding this, but it'S not on my short list right now...

> However, since most of my videos are *.mp4 I like the current solution
> already a lot better than the old state :-)

So I take it that you're ok with me having closed this bug? If not, you know where the "reopen" button is ;-)

Cheers,
  Johannes
Comment 11 Andreas Schleth 2023-10-08 17:01:51 UTC
Hi Johannes,
this ...
"I assume that for each file type the options are the same ones that you get in dolphin? If so, than this would be the intended behaviour..." 
... is the path to true enlightenment!

As follows:
The sequence is indeed the same as in dolphin. [Only dolphin shows the first in the list directly as a preferred app and the others as "others".]

However, this sequence is not set in stone but can be managed via the KDE system settings. 
(I am translating from the German UI on the fly, so there might be some mis-namings):

Goto "Applications" - "File associations" - "video" and get a long list of mime types.
For each mime type you can set the sequence to your own liking: sort, add apps, remove apps ...
Problem solved!

Thus, this part is definitely outside the scope of KPA. 
As it is not really transparent where these lists come from, a hint in the docs would be helpful :-)

Closure accepted :-)
Cheers, Andreas
Comment 12 Johannes Zarl-Zierl 2023-10-08 18:52:45 UTC
Hi Andreas,

I'm glad this works for you :-)

Cheers,
  Johannes