Open star-buck opened 9 years ago
@eikehein: can you have a look if thats only happening on kci or a general problem?
Investigating (but my guess is: order isn't stored in shared-mime but in sycoca, which isn't shared).
Basically, this seems to have roughly two aspects to it:
(a) 4 and 5 do share these settings, but only once a ~/.local/share/applications/mimeapps.list has been written out (and the KDE 4 version of Dolphin might also not notice changes there without a restart). If it hasn't, the default associations are generated from .desktop files, and there's a bunch of ways they could end up being inconsistent due to setup/PATH differences.
(b) More concretely, the older KDE 4 stack stores the mimeapps.list information in KDE's system configuration cache (sycoca), whereas KF5 uses the new MIME stack we contributed to Qt 5 that runs largely sycoca-less. Now, when the KCM writes out a new mimeapps.list it does run kbuildsycoca5, but it doesn't run kbuildsycoca4, and kded4 probably doesn't keep a file watch on it to auto-update (like it does when a new app is installed to pick up its .desktop file). That means KDE 4 apps don't pick up on the change until a sycoca update happens.
There's two ways that could be addressed: (1) Patching KDE 4 to watch mimeapps.list for changes, at least when KDE_FULL_SESSION!=true || KDE_SESSION_VERSION!=4 (2) Patching the 5 stuff to also run kbuildsycoca4 if it's installed
I've started a conversation about which way to proceed with this with the maintainer of the file association system (dfaure).
I've written a patch for the KIO framework to address this, now waiting for David to review it.
Patch for KIO pushed: http://commits.kde.org/kio/ee5303a33787691499858310a80a44e0119ea8c9
@eikehein : How does this work? Does every fileassocation needs to be set again and "applied" in kcm to have any effect in dolphin? Or should dolphin simply show the same order as under fileassocations?
@apachelogger : is this patch also in ci-updates ppa?
Thing is I tried to see if this works now for mp3 set to audacious, but while in kcm this is, in dolphin its still vlc default, even though packages in netrunner semm to be all up-to-date from ci-updates ppa: https://launchpad.net/~netrunner-os/+archive/ubuntu/netrunner-16-ci-updates
@star-buck: The simple story is: When you change the order in System Settings and hit OK/Apply, a file mimeapps.list is written out with the info. KF 5 apps use this file at runtime, but KDE 4 apps cache the information. Prior to the patch, this cache wasn't immediately updated. With the patch, OK/Apply will also update the KDE 4 cache. Dolphin 4 should then use the updated info immediately.
I tested this on my Fedora system as follows: Without the patch, changing the order had no immediate effect on Dolphin 4. With the patch, it does.
The cache is also updated in some other circumstances (system restarted, or no KDE 4 app running for long enough that kded exits and refreshes when it gets started again, etc.).
(Why don't we use Dolphin 5 btw?)
no user is going to do this for all mimetypes manually, so any way to fix this with one swoop?
The complete mimeapps.list is written out on any change, so it doesn't have to be done for each type individually. And since the cache is also refreshed on a new login anyway, the user doesn't have to make any changes to trigger an update. This was just about making it react faster, basically.
This doesnt seem to work. If I update the fileassociation in kcm for example for .mp3 mimetype and apply, it gets adjusted in dolphin fine, but all other mimetypes like for example .wav, stay different and dont get updated in dolphin.
@eikehein : dolphin5 might bring a whole other set of issues, so we use the same parts that are shipped in kubuntu for now. Any other idea how to force updating cache manually?
@eikehein : okay found out more interesting stuff: the reason why .mp3 is not possible to update is that currently 3 programs are associated: vlc, audacious, handbrake in that order Now changing and applying the order in kcm for audio-mpeg .mp3 filetype didnt update at all, so after closing system settings and opening again, it shows the same order. Interestingly, deleting one entry like Handbrake, and then Apply does update and store the settings for mp3 and then correctly shows them in dolphin too. So not sure why one can change the order for wav-files, but not mp3, and further why adding/removing entries from the associated list of apps does apply and save for .mp3-filetype though...
This could possibly be https://bugs.kde.org/show_bug.cgi?id=321706 - read comment 34, that might be helpful.
@mck182 : good catch, this might give a clue: https://bugs.kde.org/show_bug.cgi?id=321706#c34
So for some filetype associations (like in my case *.mp3), deleting an associated application gets updated and saved but reordering of the left items at the same time of deletion doesnt, just like mere re-ordering is also not saved correctly. Just speculating: Maybe the kcm does get parts of information of "what apps" and "which order" from seperated mimeapps.lists occurences, so the local and the global copy of mimeapps.list start to differ or become inconsistent?
There is no global mimeapps.list file; in the absence of a mimeapps.list file the default behavior is constructed from .desktop files following a quite complex algorithm (it also doesn't help that we have two implementations of this system, the old one in kdelibs4 and the new code in Qt 5).
Perhaps the bug is in the KCM noticing diffs from the default and not writing out enough, rather than the read-in (where it could also be, or at query time - this is one of the most complicated parts of the desktop and there's a wide bug surface). Could you upload and describe various combinations of what changes you made and your resulting ~/.config/mimeapps.list?
@eikehein : has this been fixed with dolphin ported to 5?
I'm not sure. The last comment is my request for more test information based on talking to David Faure about how the order is constructed. I think we have to re-test to find out.