When I upgraded to KDE5, I lost all my global shortcuts. It would be nice if KDE could scan the KDE4 folder and recover my shortcuts, or at least detect them, show me the code and let me reconfigure them in KDE5. Reproducible: Always
Perhaps kglobalaccel daemon should run kde4 config migration at start?
(In reply to Bhushan Shah from comment #1) > Perhaps kglobalaccel daemon should run kde4 config migration at start? It's unfortunately not that simple. E.g. it would result in plasma not having any global shortcuts as the application name changed. That's outside the scope of the knowledge of kglobalaccel. The burden to migrate the shortcuts must therefore be in the application. Which is also suboptimal as that can only work when the application migrates and doesn't support transitions from Plasma 4 to 5.
Well, Martin, it's clear that kglobalaccel daemon, kded4, kded5, or whatever else should do *something*. I spent countless hours configuring multiple shortcuts and rules and I just lost everything. "We can't do anything" is just not an acceptable answer, because it really is possible to parse the config files from ~/.kde4 and convert them to KDE5 shortcuts, or, at the very least, show the user what he had and let him re-configure them. There is no technical limitation I can see in that. It's just parsing files.
Your comment is not helpful. In fact I found it quite demotivating by implying that this is a "we don't do anything" situation. It certainly did not help to convince me to invest lots of time into the issue given that there are many more issues which need lots of work. In comment #2 I just stated that the solution proposed in comment #1 is not a suitable solution for the problem at hand. Please give us time to investigate the problem and find a working solution.
Can I get this bug in a "Confirmed" state?
Totally unsupported: ------------------------------ pkill kglobalaccel5 cp ~/.config/kglobalshortcutsrc ~/.config/kglobalshortcutsrc.bak cp ~/.kde/share/config/kglobalshortcutsrc ~/.config/kglobalshortcutsrc kglobalaccel5 & GOD! DAMN! NOTICE! ------------------------------ As Martin pointed out in his very first comment, it's the clients which put their shortcuts there. THERE IS NO GUARANTEE that the application or shortcut names didn't change, so be prepared to have some cruft in there (which the "new" clients will never remove) or even loose actual settings! YOU HAVE BEEN WARNED (and hopefully created the backup) -- I'm sorry if you fail to understand this, but this is no way "fixable" from kglobalaccel - it cannot port information which it does not possess.
I'm ... not really sure what are you talking about, but let me explain you how I see it. `kglobalshortcutsrc` is used to store global shortcuts for 2 types of applications (clients, as you call them): kde-centric and 3rd party. The format of the file is pretty simple: [client] <command>=<shortcut> Now, I can't really understand what exactly is the problem here? Which part of that you can't migrate? Because, as I see it, it could be done as simple as: for <client> in kglobalshortcutsrc.reader(): for <command> in <client>: if client.isKDEType(): //KMix, for example, let's assume it's like //decrease_volume=X+Y <----- in KDE4 //new_decrease_vol_command=X+Y <------- in KDE5 // //because KMix is a KDE app, you should already know if the command changed //If that is the case, write down the new command. else: //copy <command> as-is as 3rd party apps don't care about KDE4 or KDE5, it's just a command with an assigned shortcut I could be wrong, of course, if that is the case, please explain *why* exactly isn't this possible? PS: Of course, this "migration" work shouldn't be done by Plasma, but it's still KDE's job to do it. That is what "giving KDE4 and migration to KDE5 support" means.
The problem at hand is that no single person actually knows which applications have the global shortcuts in there and how those applications changed. Now let's go with your suggestion for a bit - Martin G. is the maintainer of kglobalaccel, what he would need to do is compile a comprehensive database of all shortcuts from all kde apps from kde4 times. Then compile another comprehensive database of all shortcuts from apps based on frameworks ("kde5"). Then actually match all the terms from both databases together. That is simply an impossible task to do so. Therefore, as others have pointed out, it is the responsibility of the application itself to actually migrate all the shortcuts. There is no other simple way to do this...unless you have a sufficient manpower with absolutely nothing to do ;)
I keep failing at understand where is the problem. Recompiling those (supposedly huge and impossible to recompile) databases is as simple as installing a <full> KDE4 desktop, a <full> KDE5 desktop, enabling all shortcuts (managing conflicts, of course) and comparing both kglobalshortcutsrc files with a simple `diff`, then writing down the differences. Is that such a big task that requires so many man power/years of work or am I missing something? And no, I really don't think this should be handled by each app itself, because global shortcuts it part of KDE, and because KDE did the code-break, KDE should handle it (pretty much the same thing that happens when you upgrade your Debian install, for example).
if you think it's so trivial we invite you to show us it's doable. We as the developers having do not think it's a trivial task. Also we think it's the task of each and every application to migrate their configuration as it's - due to the way how kglobalaccel works - outside the scope of kglobalaccel.
Since KDE4 is now unsupported and unmaintained, is there anything left to do with this bug?
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!