Bug 321706 - Some file type association can't be changed anymore
Summary: Some file type association can't be changed anymore
Status: RESOLVED FIXED
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_filetypes (show other bugs)
Version: 4.10.97
Platform: Other Linux
: NOR major with 61 votes (vote)
Target Milestone: ---
Assignee: David Faure
URL:
Keywords: regression
: 323029 323326 323746 323750 324098 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-06-28 11:46 UTC by Janek Bevendorff
Modified: 2014-07-10 22:45 UTC (History)
30 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.11.1


Attachments
Should fix mimetypes not being saved properly (2.46 KB, patch)
2013-08-06 04:59 UTC, Mathias Tillman
Details
New version that should be slightly faster (3.54 KB, patch)
2013-08-10 09:55 UTC, Mathias Tillman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Janek Bevendorff 2013-06-28 11:46:37 UTC
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.
Comment 1 Rohan Garg 2013-06-28 14:03:22 UTC
Seems to work for me, can you check if you have rw permissions for ~/.local/share/applications/mimeapps.list ?
Comment 2 Christoph Feck 2013-06-28 16:10:28 UTC
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.
Comment 3 Rohan Garg 2013-06-28 16:15:32 UTC
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.
Comment 4 Janek Bevendorff 2013-06-28 18:16:37 UTC
I tried it for Matroska files. Probably a general issue with foo/x-bar 
MIME types?
Comment 5 Janek Bevendorff 2013-06-28 18:23:00 UTC
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.
Comment 6 zless 2013-07-01 16:55:18 UTC
I also observed this issue with the mkv filetype.
Comment 7 Eugene Shalygin 2013-07-17 17:54:07 UTC
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?
Comment 8 Mathias Tillman 2013-08-02 12:49:57 UTC
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.
Comment 9 Mathias Tillman 2013-08-05 14:39:18 UTC
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.
Comment 10 Mathias Tillman 2013-08-06 04:59:12 UTC
Created attachment 81578 [details]
Should fix mimetypes not being saved properly
Comment 11 Mathias Tillman 2013-08-06 04:59:31 UTC
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
Comment 12 Frank Reininghaus 2013-08-10 08:02:09 UTC
*** Bug 323326 has been marked as a duplicate of this bug. ***
Comment 13 Frank Reininghaus 2013-08-10 08:04:45 UTC
*** Bug 323029 has been marked as a duplicate of this bug. ***
Comment 14 Mathias Tillman 2013-08-10 09:55:24 UTC
Created attachment 81627 [details]
New version that should be slightly faster
Comment 15 Mathias Dietrich 2013-08-15 12:57:18 UTC
What's the actual status of the patch ? I still have this issue in 4.11.
Comment 16 TOM Harrison 2013-08-15 15:15:58 UTC
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
Comment 17 TOM Harrison 2013-08-15 15:19:58 UTC
ok i found, build kded.
and this resolved the problem.
Comment 18 lnxusr 2013-08-15 19:08:36 UTC
Thank you Mathias.  I patched and rebuilt kde4libs and it fixed the problem for me.
Comment 19 Mathias Tillman 2013-08-16 09:47:13 UTC
@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.
Comment 20 TOM Harrison 2013-08-16 10:02:56 UTC
@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
Comment 21 lnxusr 2013-08-16 14:23:06 UTC
@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.
Comment 22 Mathias Tillman 2013-08-16 14:33:22 UTC
@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.
Comment 23 Eugene Shalygin 2013-08-16 14:45:54 UTC
I'm running KDE 4.11 with this patch applied since 4.11 release. So far ther are no problems
Comment 24 lnxusr 2013-08-16 14:58:05 UTC
@Mathias Tillman:  I'm pretty sure my problems were due to my building and installing the complete kde4libs package, not your patch.
Comment 25 TOM Harrison 2013-08-17 00:48:35 UTC
(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.
Comment 26 Jekyll Wu 2013-08-20 04:06:48 UTC
*** Bug 323746 has been marked as a duplicate of this bug. ***
Comment 27 Jekyll Wu 2013-08-20 04:37:03 UTC
*** Bug 323750 has been marked as a duplicate of this bug. ***
Comment 28 David Faure 2013-08-26 13:51:40 UTC
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
Comment 29 Jekyll Wu 2013-08-27 08:37:26 UTC
*** Bug 324098 has been marked as a duplicate of this bug. ***
Comment 30 David Faure 2013-10-18 07:41:10 UTC
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
Comment 31 David Faure 2013-10-19 08:11:13 UTC
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
Comment 32 ciprian.lica 2014-02-14 18:26:48 UTC
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.
Comment 33 Rob Burness 2014-02-19 00:30:57 UTC
(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.
Comment 34 David Faure 2014-03-01 09:21:04 UTC
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.
Comment 35 Eric S 2014-06-13 02:50:13 UTC
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.
Comment 36 Eric S 2014-06-20 20:57:05 UTC
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.
Comment 37 Eric S 2014-06-20 21:01:08 UTC
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.
Comment 38 Christoph Feck 2014-07-10 22:45:13 UTC
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.