Duplicate Krita and Okular MIME associations (multiple Krita and Okular options in Dolphin)

Development
, ,
1

I am unsure where to report this, it’s not really a Dolphin issue and Okular[1]/Krita[2] devs argue it’s not theirs either.

The spec says

NoDisplay means “this application exists, but don’t display it in the menus”. This can be useful to e.g. associate this application with MIME types, so that it gets launched from a file manager (or other apps), without having a menu entry for it (there are tons of good reasons for this, including e.g. the netscape -remote, or kfmclient openURL kind of stuff).

And in my opinion Dolphin and others do what they are supposed to, they display those entries in options to open a file based on its MIME type as the NoDisplay doesn’t exclude this use case. GTK has its own issue on this[3] and Emmanuele Bassi has the same point there[4]. But since Krita and Okular have separate plugins for different file types, they can’t merge the MimeType declaration in one desktop file

File loading in Krita is done via plugins and each of them declares which types it can handle, you can freely add and remove these plugins. We can’t fix that file managers don’t interpret the declarations properly unless we make the entire thing into a monolith.

[5]

Okular allows distributions to provide multiple packages so they can just have the ‘likely used’ backends (e.g. pdf) in the ‘main package’ and the more fringe formats (‘djvu’, ‘fax’) in auxillary addon packages.

[6]

And so no-one can do anything with this. Then perhaps everyone should come together and extend the spec to include a Parent or Alias option to desktop files as suggested in https://gitlab.gnome.org/GNOME/gtk/-/work_items/7776#note_2599971 to make everyone happy?

Related bug reports:

Posting this here to bring some attention as the GTK issue hasn’t seen activity for 8 months, and I wasn’t linked to any active issues on KDE side and couldn’t find any either.

1 Like