blue-systems / plasma-5.5

Plasma 5.2 - 5.5
0 stars 0 forks source link

[file assocations]: order in kcm is not the same as in dolphin4 context menu #114

Open star-buck opened 9 years ago

star-buck commented 9 years ago

dolphin4-file-association

star-buck commented 9 years ago

@eikehein: can you have a look if thats only happening on kci or a general problem?

eikehein commented 9 years ago

Investigating (but my guess is: order isn't stored in shared-mime but in sycoca, which isn't shared).

eikehein commented 9 years ago

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).

eikehein commented 9 years ago

I've written a patch for the KIO framework to address this, now waiting for David to review it.

eikehein commented 9 years ago

Patch for KIO pushed: http://commits.kde.org/kio/ee5303a33787691499858310a80a44e0119ea8c9

hsitter commented 9 years ago

https://launchpad.net/~netrunner-os/+archive/ubuntu/netrunner-16-ci-fixes/+sourcepub/5052846/+listing-archive-extra

star-buck commented 9 years ago

@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

eikehein commented 9 years ago

@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?)

star-buck commented 9 years ago

no user is going to do this for all mimetypes manually, so any way to fix this with one swoop?

eikehein commented 9 years ago

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.

hsitter commented 9 years ago

@star-buck It's part of https://launchpad.net/~netrunner-os/+archive/ubuntu/netrunner-16-ci-updates/+sourcepub/5054209/+listing-archive-extra

star-buck commented 9 years ago

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.

star-buck commented 9 years ago

@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?

star-buck commented 9 years ago

@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...

mck182 commented 9 years ago

This could possibly be https://bugs.kde.org/show_bug.cgi?id=321706 - read comment 34, that might be helpful.

star-buck commented 9 years ago

@mck182 : good catch, this might give a clue: https://bugs.kde.org/show_bug.cgi?id=321706#c34

star-buck commented 9 years ago

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?

eikehein commented 9 years ago

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?

star-buck commented 8 years ago

@eikehein : has this been fixed with dolphin ported to 5?

eikehein commented 8 years ago

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.