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
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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
Comment by Jonas Abrahamsson (JKAbrams) - Saturday, 14 February 2015, 16:31 GMT
Oops, the new name for gwenview is 'gwenview.desktop' not 'org.kde.gwenview.desktop'!
Comment by Andrea Scarpino (BaSh) - Saturday, 14 February 2015, 16:32 GMT
We cannot modify users data, so there is nothing we can do about this.
Comment by Doug Newgard (Scimmia) - Saturday, 14 February 2015, 16:35 GMT
The global mime type list is updated in the post_install script. The $HOME/.local/share/applications/* would be local overrides that you configured. I don't see how a package can do anything about that.
Comment by Jonas Abrahamsson (JKAbrams) - Saturday, 14 February 2015, 16:36 GMT
That is very unfortunate, the update will break the desktop.
What about a news item on the start page of archlinux or is it too late for that?
Comment by Jonas Abrahamsson (JKAbrams) - Saturday, 14 February 2015, 16:45 GMT
Doug Newgard:
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?
Comment by Jonas Abrahamsson (JKAbrams) - Saturday, 14 February 2015, 16:50 GMT
KDE config files are many and has a somewhat complicated structure, most(?) users don't mess with them too much directly unless there is a specific issue that needs to change them to fix something.
It is not obvious that an update of kwrite will make all custom 'open files with kwrite' to stop working.

Loading...