https://bugs.kde.org/show_bug.cgi?id=425154
--- Comment #8 from D. Debnath <d_debn...@outlook.com> --- (In reply to Adam Fontenot from comment #7) > 1. Do you experience what I called issue 4 in my earlier comment? To recap: > it makes sense (given this issue) that Okular is associated with almost all > of your file types. But has Okular been unexpectedly opening files even > though you already had another program assigned to open that file type more > directly? If so, can you report your Plasma desktop version? Given David's > fix, this shouldn't be happening unless you have an old version. > > It looks to me from your screenshot that Okular is indeed listed first, > despite the fact that it is (I assume) only inherited from octet-stream. I did experience that issue as you noticed from my screenshot. Okular got automatically prioritized to the highest spot even though more direct associations existed. > 2. Do you think you would have been able to resolve this problem on your own > if the File Associations KCM had done something to make you aware of the > root cause? E.g. an indication that the file association for > application/x-ipynb+json was inherited *AND* when deleting that file > association, a popup message identifying the inherited association > (application/otect-stream) and offering to delete it for you? Oh yes absolutely. If the File Associations KCM had given me hints about the chain of inheritance, it would've made the troubleshooting a lot more straightforward and I would've likely succeeded in resolving the issue on my own. The XDG specification here: https://specifications.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-0.21.html under the "Subclassing" heading notes that: > All streamable types (ie, everything except the inode/* types) are subclasses > of application/octet-stream. So, application/octet-stream has special meaning, and this information would be helpful to point out when troubleshooting any issues with file associations. However, when a normal user, who isn't having file association related problems, and visits the KCM just to change a file association, this information about octet-stream wouldn't be useful and wouldn't even make much sense to the user. So from a UI/UX perspective, you would have to implement it in a way that still retains a simple and easy to use interface, but presents this extra information to a curious user. > I might have a look at coding something to resolve the issue in the way I > suggested in the next few days, if I have the time. This would then only > leave issue 3, as I described it in my earlier comment. Is it possible to add comments to the ~/.config/mimeapps.list? If yes, then let's say whenever a programs modifies that file, a comment could be added to it about which program made the modification. Something like: [Added Associations] application/octet-stream=org.kde.okular.desktop; # added by /usr/bin/firefox inode/directory=org.kde.dolphin.desktop; # added by File Association KCM x-scheme-handler/http=firefox.desktop; # added by File Association KCM x-scheme-handler/https=firefox.desktop; # added by File Association KCM x-scheme-handler/mailto=thunderbird.desktop; # added by File Association KCM [Default Applications] application/epub+zip=calibre-ebook-viewer.desktop; # added by /usr/bin/dolphin [Removed Associations] application/epub+zip=okularApplication_epub.desktop; # added by File Association KCM -- You are receiving this mail because: You are watching all bug changes.
