The file type association dialog is broken in 4.11 beta1. When I want to change the order of the default applications for a file the setting is simply not remembered. I can remove applications from the list and I can add new ones, but I can't reorder the already existing associations. Reproducible: Always Steps to Reproduce: 1. Either go to System Settings->File associations or right click on a file in Dolphin and click Properties->File Type Options 2. Reorder the default applications for a file type and click OK. 3. Reopen the dialog Actual Results: The order of the file associations is the same as before, nothing has changed. Expected Results: The new order should be remembered. This bug only occurs for the default file type associations that are already present. When I add a new application to the list I can change its position, but all default (i.e. system-wide) MIME associations can't be reordered in any way. This may be related to Bug 319359.
Seems to work for me, can you check if you have rw permissions for ~/.local/share/applications/mimeapps.list ?
It seems to depend on the file type. Here, I can reorder applications for image/jpeg, but not for video/x-ms-wmv. I have rw permission to mimeapps.list.
Indeed, I can't change the order of applications for video/x-ms-wmv as well. However, this seems to be more of a UI issue since my mimeapps.list does have the correct ordering.
I tried it for Matroska files. Probably a general issue with foo/x-bar MIME types?
Addition: just tried for MP3 files, it works. It still does not work for MKVs, though. But although the correct entry is written to the mimeapps.list file, this is definitely not just a UI issue because the file still opens in the wrong application. E.g. when I have an MKV file and it has the applications mkvinfo, VLC, Handbrake (in order) and I put VLC first, it still opens in mkvinfo after saving the changes.
I also observed this issue with the mkv filetype.
I have the similar problem: can edit, for instance, image/x-eps, but can not application/rtf. Moreover, not only keditfiletype application/rtf can not save assotiation (mimeapps.list is updated), but even after $ xdg-mime default libreoffice-writer.desktop application/rtf (mimeapps.list is updated) $ xdg-mime query default application/rtf prints kate.desktop Does it mean that the problem is not in KDE?
I too have this problem using KDE 4.11 (4.10.95). @Eugene Shalygin xdg-mime uses KDE programs to query and set mime types. So if you edit xdg-mime and make detectDE set DE to gnome for example it will most likely work. I believe KDE uses ktraderclient to find out the mimetypes list (which internally pulls its data from ksycoca4), you can try this yourself using ktraderclient --mimetype application/rtf --servicetype Application.
I have done some more testing and it appears like this problem is due to how KDE handles mimetypes and their parents, it seems like it doesn't adhere to the ordering if a mimetype has a parent. For example application/rtf has the parent text/plain, and video/x-matroska application/x-matroska, if I change the order of application/rtf it's not listed properly, but if I change text/plain it does, same goes for video/x-matroska. One other thing I noticed is that the parent mimetype needs to have the same desktop files set as it's child, or the order will be screwed up, the child will list its desktop files first (excluding the ones that exist in the parent) followed by the parent's desktop files. Here is an example list of my mkv setup: mimeapps.list: application/x-matroska=vlc.desktop;ghb.desktop;mkv-extractor-gui.desktop; video/x-matroska=ghb.desktop;kde4-dragonplayer.desktop;vlc.desktop;mkv-extractor-gui.desktop; System Settings list for video/x-matroska: kde4-dragonplayer.desktop, vlc.desktop, ghb.desktop, mkv-extractor-gui.desktop As you can see it first goes through video/x-matroska and adds desktop files that are not part of the parent first, then adds the parent desktop files, in order. I hope that makes sense and that you can use this information, I have looked through the KDE code myself but it feels like it'll be like finding a needle in a haystack as I'm not very used to how the KDE code is written etc.
Created attachment 81578 [details] Should fix mimetypes not being saved properly
I looked through the code and found out where the problem is, and it is caused by this commit: https://projects.kde.org/projects/kde/kdelibs/repository/revisions/871cccc8a88a600c8f850a020d44bfc5f5858caa I have attached a patch that should fix this problem but I had to disable the fix above of it to work. The patch contains a reworked way of detecting "duplicate" mimetypes though, which should work, it did for me anyway
*** Bug 323326 has been marked as a duplicate of this bug. ***
*** Bug 323029 has been marked as a duplicate of this bug. ***
Created attachment 81627 [details] New version that should be slightly faster
What's the actual status of the patch ? I still have this issue in 4.11.
i have patch this patch, but because i did not know what package need to compile or which program. when i compile all. the kde work not correct
ok i found, build kded. and this resolved the problem.
Thank you Mathias. I patched and rebuilt kde4libs and it fixed the problem for me.
@Mathias Dietrich I posted it to the review board a week or so ago, but it has yet to be submitted, and they haven't replied to review request. @l12436@yahoo.com.tw The patch applies to kbuildsycoca4, which is part of kdelibs. So building that should be fine. @lnxusr@westlot.net That is good to hear, it's a very annoying problem so I hope it gets submitted soon.
@Mathias Tillman yeah, but i found vuild all of the code will crash the kde. only build kded could work normal. my source is using apt-get source libkdecore5, and that version is now i installed, so i did not know how that happened. anyway, now the patch will let the problem solved, i hope it could update to apt ASAP
@Mathias Tillman: I spoke a bit too soon there. Although patching, building and installing the complete kde4libs fixed this particular problem, it ended up completely hosing my system. @l12436@yahoo.com.tw: Oh, yes it does. Things seem to work OK at first, but the whole system starts to fall apart rather quickly, and don't even think about rebooting. I'd not recommend to anyone to rebuild the complete kde4libs. I'm going to try to rebuild my second partition this weekend and try again with just kbuildsycoca4. Thankfully, I keep two identical partitions on my system for just such stupidity by me. I synch them up when I know the changes are stable.
@lnxusr@westlot.net Did you try building kde4libs without this patch before and if so, did that work? I'm pretty sure my patch shouldn't destroy a system, though I haven't tried to build and install the whole of kde4libs.
I'm running KDE 4.11 with this patch applied since 4.11 release. So far ther are no problems
@Mathias Tillman: I'm pretty sure my problems were due to my building and installing the complete kde4libs package, not your patch.
(In reply to comment #24) > @Mathias Tillman: I'm pretty sure my problems were due to my building and > installing the complete kde4libs package, not your patch. you just need to build kded, this patch just effect the kded.
*** Bug 323746 has been marked as a duplicate of this bug. ***
*** Bug 323750 has been marked as a duplicate of this bug. ***
Git commit 7f42bf2530090526d0150428fe58b87123317e2e by David Faure. Committed on 26/08/2013 at 13:46. Pushed by dfaure into branch 'KDE/4.11'. Fix reordering of apps for a derived mimetype. This fixes a bug introduced by 871cccc8a88a60 that made it impossible to re-order file type associations both in System settings and in the open with list. Hence it contains a new way of detecting duplicate (inherited) mimetype entries, that the original was supposed to fix. Unittest is in kde-runtime, commit 967979f (if I can commit it fast enough ;) Patch by Mathias Tillman. REVIEW: 111951 FIXED-IN: 4.11.1 M +36 -9 kdecore/services/kservice.cpp M +1 -1 kded/kbuildservicefactory.cpp M +0 -25 kded/kmimeassociations.cpp M +0 -1 kded/kmimeassociations.h http://commits.kde.org/kdelibs/7f42bf2530090526d0150428fe58b87123317e2e
*** Bug 324098 has been marked as a duplicate of this bug. ***
Git commit f723e2e7d36b597c5262bf63dde380d89ec6bfcb by David Faure. Committed on 18/10/2013 at 07:44. Pushed by dfaure into branch 'KDE/4.11'. Fix association-with-derived-mimetype again. 871cccc8a88a made it impossible to re-order file type associations. 7f42bf253009 fixed that, but changed the value of KService::mimeTypes(), which broke okular. This new fix works the same way, but only inside kbuildsycoca when it processes the mimetypes. The value of KService::mimeTypes() is now restored to be exactly what's in the desktop file. FIXED-IN: 4.11.3 M +9 -36 kdecore/services/kservice.cpp M +4 -3 kdecore/tests/kservicetest.cpp M +10 -1 kded/kbuildservicefactory.cpp http://commits.kde.org/kdelibs/f723e2e7d36b597c5262bf63dde380d89ec6bfcb
Git commit 8bfcace7efc0feea8899f70dfc15c3050c90ea99 by David Faure. Committed on 19/10/2013 at 08:15. Pushed by dfaure into branch 'KDE/4.11'. Improve fix for association with derived mimetypes (f723e2e7d36) If a desktop file was mentionning two aliases, they would both get removed, due to is() returning true for aliases as well. M +6 -1 kded/kbuildservicefactory.cpp M +10 -4 kded/tests/kmimeassociationstest.cpp http://commits.kde.org/kdelibs/8bfcace7efc0feea8899f70dfc15c3050c90ea99
I still got this bug under KDE 4.11.5. Re-ordering to vlc works for *.mp4, *.avi, *.flv, but not for *.mkv. My "Application Preference Order" is: kaffeine, vlc, handbrake, mediainfo-gui. When I change it to vlc being first and close the Edit FIletype window, kaffeine remains the default player and, when the filetype window is opened again, the list order appears to have remained unchanged. The weird thing is that if I change the list order to kaffeine, vlc, mediainfo-gui, handbrake, the change will remain effective. The same is valid for mediainfo-gui, kaffeine, vlc, handbrake. But after this last permutation, when I tried to change it to vlc, mediainfo-gui, kaffeine, handbrake, I've got instead kaffeine, vlc, mediainfo-gui, handbrake. In the end, I've removed kaffeine from the list, and vlc remained the first application.
(In reply to comment #32) > I still got this bug under KDE 4.11.5. Re-ordering to vlc works for *.mp4, > *.avi, *.flv, but not for *.mkv. My "Application Preference Order" is: > kaffeine, vlc, handbrake, mediainfo-gui. When I change it to vlc being first > and close the Edit FIletype window, kaffeine remains the default player and, > when the filetype window is opened again, the list order appears to have > remained unchanged. > > The weird thing is that if I change the list order to kaffeine, vlc, > mediainfo-gui, handbrake, the change will remain effective. The same is > valid for mediainfo-gui, kaffeine, vlc, handbrake. > > But after this last permutation, when I tried to change it to vlc, > mediainfo-gui, kaffeine, handbrake, I've got instead kaffeine, vlc, > mediainfo-gui, handbrake. > > In the end, I've removed kaffeine from the list, and vlc remained the first > application. If I remove Amarok from the list vlc can be moved to the default location. If I add Amarok back in it wants to stay at the top and changes in position (move up/down) are ignored. Running KDE 4.12.2. I will simply keep Amarok off the list for .ogg files until this gets fixed. Seems like it should be a simple fix.
Please investigate what happens in your ~/.local/share/applications/mimeapps.list file when making changes in the GUI, to find out if the problem is what gets written there, or the way it's interpreted. It's hard for me to reproduce such bugs because it depends on what the .desktop files for the apps say (that's the initial ordering) and what the user's mimeapps.list file says, so overall quite system-dependent. But we can narrow down the bug if you can look into mimeapps.list and find out if it's right or wrong.
I'm seeing this problem on 4.13.1. It does seem to record my changes in ~/.local/share/applications/mimeapps.list For example application/xml=kde4-kate.desktop;juffed.desktop;chromium.desktop;kde4-rekonq.desktop;kde4-kfmclient_html.desktop;firefox.desktop;opera-browser.desktop;kde4-author.desktop;kde4-okularApplication_txt.desktop;kde4-calligrawords_ascii.desktop; However rekonq keeps showing as the first mapping in system settings UI, and that is the app that will open if I click and xml file.
I can now confirm it is still a problem in 4.13.2 Whatever is going on is pecularly specific. For application/xml I have Rekonq Kate Juffed etc. in my list. I encountered the problem because I wanted Kate to be the default app. I kept moving the order to Kate was at the top and Rekonq lower in the list. But it would never seem to "take." Rekonq was always opened when I clicked on an xml file, and going back into the file association ui, it would stil show Rekonq at the top Looking at ~/.local/share/applications/mimeapps.list I would see that the change was indeed saved. The entry looks like: application/xml=kde4-kate.desktop;juffed.desktop;kde4-rekonq.desktop;chromium.desktop;kde4-kfmclient_html.desktop;firefox.desktop;opera-browser.desktop;kde4-author.desktop;kde4-okularApplication_txt.desktop;kde4-calligrawords_ascii.desktop; Deleting Rekonq from the list (using the UI) did however work. It stopped appearing in the UI and Kate was opened when I clcik an xml file. So I thought, well maybe it is reordering changes specifically that don't work. So for kicks I swapped Kate and Juffed in the order. However this DID work. Juffed was opened when I click and xml file, and the order was shown when I went bck into the UI. So then I added Rekong again. And now AGAIN rekong always shows first in the UI and always opened when clicking an xml file. Reordering it the UI does not matter. Can we please reopen this? Something is not right, even if very specific.
BTW I should add that this does not seems to be a case of Default Applications overriding the file associations. Rekonq is NOT my default web browser or default for anything. I rarely even use it.
Eric, can you please file a new bug with exact steps to reproduce on a freshly created user account? This one is most likely a different bug.