FS#43817 - Transition problems to KDE 5 applications
Attached to Project:
Arch Linux
Opened by Jonas Abrahamsson (JKAbrams) - Saturday, 14 February 2015, 16:18 GMT
Last edited by Antonio Rojas (arojas) - Friday, 13 March 2015, 15:58 GMT
Opened by Jonas Abrahamsson (JKAbrams) - Saturday, 14 February 2015, 16:18 GMT
Last edited by Antonio Rojas (arojas) - Friday, 13 March 2015, 15:58 GMT
|
Details
Description:
In the update to KDE 5 applications the .desktop files to start the applications are changed but the filetype associations not. Result: Files that are set to open with Kwrtie, Kate, Gwenview are can not be opened by clicking them. Here are the names from the applications I happened to have installed on this machine: old names: /usr/share/applications/kde4/kate.desktop /usr/share/applications/kde4/konsole.desktop /usr/share/applications/kde4/kwrite.desktop /usr/share/applications/kde4/okteta.desktop new names: /usr/share/applications/org.kde.kate.desktop /usr/share/applications/org.kde.konsole.desktop /usr/share/applications/org.kde.kwrite.desktop /usr/share/applications/org.kde.okteta.desktop Fix would be in $HOME/.local/share/applications/mimetypes.list: Replace 'kde4-kwrite.desktop' with 'org.kde.kwrite.desktop' Replace 'kde4-kate.desktop' with 'org.kde.kate.desktop' Replace 'kde4-gwenview.desktop' with 'org.kde.gwenview.desktop' Then login and logout. Packages that depend on knewstuff: kanagram kate kde-gtk-config-frameworks khangman ksysguard kwin muon parley plasma-workspace I'm not familiar with how the KDE config files are set up, there might be more areas causing issues. One I've noticed is that shortcuts to open applications has the same problem. Searching for the old names in $HOME I find: ./kde4/share/config/khotkeysrc ./kde4/share/config/plasma-desktop-appletsrc |
This task depends upon
Closed by Antonio Rojas (arojas)
Friday, 13 March 2015, 15:58 GMT
Reason for closing: Upstream
Additional comments about closing: Packages can't touch user's home
Friday, 13 March 2015, 15:58 GMT
Reason for closing: Upstream
Additional comments about closing: Packages can't touch user's home
What about a news item on the start page of archlinux or is it too late for that?
Ah, so local overrides, at least that means that user not all users are affected which is good. Still I think most users would (all? can't think of one that would not) have appreciated the same script modifying the users overrides as well (I mean overrides are kind of encouraged with 'open with' -> 'remember'), then broken with a 'pacman -Syu'.
What is the problem keeping the script from this? Policy or technical difficulty finding all users directories and the like?
It is not obvious that an update of kwrite will make all custom 'open files with kwrite' to stop working.