Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
star-buck opened this issue May 7, 2015 · 20 comments
Assignees

Comments

@star-buck
Copy link
Contributor

dolphin4-file-association

@star-buck star-buck added the high label May 7, 2015
@star-buck star-buck changed the title [file assocations]: associated order in system settings is not the same as in dolphin4 [file assocations]: order in kcm is not the same as in dolphin4 context menu May 8, 2015
@star-buck star-buck added mid and removed high labels May 8, 2015
@star-buck star-buck assigned eikehein and unassigned notmart May 8, 2015
@star-buck
Copy link
Contributor Author

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

@eikehein
Copy link

eikehein commented May 8, 2015

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

@eikehein
Copy link

eikehein commented May 9, 2015

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
Copy link

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

@eikehein
Copy link

@star-buck
Copy link
Contributor Author

@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
Copy link

@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
Copy link
Contributor Author

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

@eikehein
Copy link

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.

@star-buck
Copy link
Contributor Author

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
Copy link
Contributor Author

@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
Copy link
Contributor Author

@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
Copy link

mck182 commented May 13, 2015

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

@star-buck
Copy link
Contributor Author

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

@star-buck
Copy link
Contributor Author

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
Copy link

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
Copy link
Contributor Author

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

@eikehein
Copy link

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.

@star-buck star-buck removed the mid label Jan 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants