Bug 396930 - Option to lock the order of preferred applications for all mimetypes
Summary: Option to lock the order of preferred applications for all mimetypes
Status: CONFIRMED
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_filetypes (show other bugs)
Version: 5.13.1
Platform: Other Linux
: LO wishlist
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-28 14:52 UTC by Øystein Steffensen-Alværvik
Modified: 2020-01-22 16:16 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Øystein Steffensen-Alværvik 2018-07-28 14:52:12 UTC
– Feature wish:
An option to prevent external applications from changing applications associated with each mimetype. In other words, lock all mimetypes with their associated applications to prevent non-user invoked changes.

– Why?
Because it is frustrating to edit the preferred applications list for *each* mimetype manually – which happens when applications, upon install, auto-edit the list without asking the user.
Comment 1 David Faure 2018-08-06 08:49:53 UTC
Which applications auto-edit ~/.local/share/applications/mimeapps.list ?? That should be forbidden. The intent of the spec was for the user to edit this file, and only the user.

In any case we can't do anything at the KDE level, to prevent an application from editing a file. But since this is a violation of the mimeapps spec, let's get those apps fixed.
Comment 2 Øystein Steffensen-Alværvik 2018-08-06 09:56:34 UTC
I don't know about that file, but KMPlayer from Neon adds itself to the top of the list for audio and video files in File Associations. I see now that the program messes with default options only; if you've changed anything for a mimetype in File Associations it respects that. But on a new user account, installing KMPlayer sets it as the default audio and video player. So if you're happy with the defaults, you msut change each association manually. :-(
Comment 3 Christoph Feck 2018-08-06 14:15:20 UTC
I guess this is expected behaviour, probably caused by respecting a 'priority' in the desktop file.

If you only have 'Ark' installed, then Office Open XML files would open in 'Ark', because they are .zip archives. If you then install 'Okular', it must have a higher priority to show .odt files in 'Okular'. Finally, if you now install 'LibreOffice', all files should open there by default.

You probably want bug 254560 instead.
Comment 4 Øystein Steffensen-Alværvik 2018-08-06 14:57:01 UTC
But if the system default is to open video files with VLC, why would installing KMPlayer prioritise it?
But yes, bug 254560 looks more sensible now.
Comment 5 Øystein Steffensen-Alværvik 2018-08-07 17:38:14 UTC
So after some thought, this is more or less the same as WISH 254560.

*** This bug has been marked as a duplicate of bug 254560 ***
Comment 6 Øystein Steffensen-Alværvik 2018-09-14 15:48:40 UTC
It turns out that my original problem (apps auto-changing 'open with…' defaults) stemmed from Flatpak apps, which will frequently increase their priority over other apps. Mediainfo from Flathub, for example, will ignore the default app for video files (VLC) and add itself as default upon install.

Is this likely a KDE issue or are the individual Flatpak apps misbehaving?
Comment 7 Nate Graham 2020-01-22 16:16:48 UTC
More likely an issue with Flatpak apps not respecting the existing data here. Might also be worth a bug on Flatpak itself. https://github.com/flatpak/flatpak/