Created attachment 748359 [details, diff] Patch Ref: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/921 Ref: https://bugs.kde.org/show_bug.cgi?id=437364 For some time now, I've been having an issue where KRunner's shortcut keys stop working after a while. I found this bug and PR, and compared it to what is installed by kde-plasma/plasma-workspace-5.22.5-r2, and made this simple diff patch. Probably needs some more testing, I've been using it all day without my KRunner shortcut keys not working, so I'd consider this patch successful. Thought I'll submit it here, as it can be useful for users using 5.22.5. I believe it's fixed in later versions.
Thank you!
Please don't compare files from different branches, use the actual fix commit by upstream. It was linked anyway. https://invent.kde.org/plasma/plasma-workspace/-/commit/6502f798fe64bd31f043fe2f273587e166ffcb52.patch
The patch provided by upstream wasn't applying, hence I made my own from the PR made from the patch. The patch I made did apply and fixed the issue.
Created attachment 748644 [details] Emerge Output - Attempt to use upstream patch Here's the output of an attempt to merge `kde-plasma/plasma-workspace` with the upstream provided patch.
Created attachment 748737 [details, diff] krunnerglobalshortcuts.cpp-to-5.23.diff I've looked at it again, and found the content of your linked MR already cherry-picked to 5.22 branch. See also Version-fixed-in "5.22.1" in your linked KDE bug. So that's not the fix. I've found only two commits to master or Plasma-5.23 that make any material difference to the code over 5.22.5, and the end result of that patch looks like what I have attached here. (please test) ...which is completely different to your patch, so I was left wondering how you got to it; and it is essentially that you reverted follow-up commit e275ae2c8e5d5fe3c3acf48bf201bed3a15f911f. I'm not going to do that without further reports or clarification upstream. It may be that you simply have to fix your config manually.
Okay, I'll try it out today, and let you know how it goes. As far as to where I got the patch, I didn't revert anything, at least, not intentionally. As I think I mentioned before, all I did was pull the MR when the patch that was provided didn't apply; and then I ran a diff on that to see the difference between them. The results is patch you get here. Which in my 2 solid days of testing, I noticed, fixed the issue.
You effectively reverted follow-up commit [and any other changes] by viewing the file at commit 6502f798fe64bd31f043fe2f273587e166ffcb52, which in git history is some time before 5.22.1, and diffing that against 5.22.5. Which obviously may undo any other unrelated changes happening in the file after that commit. Btw I doubt that my patch will do anything, it will just confirm that even [with that file from] git master has the same behaviour for you. And with that you should go upstream and improve your bug description, i.e.: "KRunner's shortcut keys stop working after a while" - what does that mean? After one hour, after one day, after using it once, twice, a dozen times?
Understood. However, I wasn't the OP of the bug. TBH, I've had this issue for a week, maybe more, and it just got so annoying that I googled it and found a Reddit post of some people with the same problem. That Reddit post, mentioned the bug, so...chain reaction. Honestly, it didn't seem like it was 100% the same issue, but it was close enough, for me to try their fix. Yes, your patch doesn't seem to do anything. As for the keys, I've noticed them stop working after a while. I don't know precisely how long, but sometimes it just after 10-15m of a clean boot. I've also noticed Sleep makes it go bananas. However, with that patch I submitted, it seems to fix all the issues. I had my computer on for 2 days, and slept it multiple time, and all KRunner kept working.
(In reply to Randall from comment #8) > Understood. However, I wasn't the OP of the bug. ... Right, but I'm replying to this, your bug here. ;) (In reply to Randall from comment #8) > Honestly, it didn't seem like it was 100% the same issue, but it was close > enough, for me to try their fix. I'm re-iterating just to make sure we are on the same page: - 42b1039e is the fix from the MR you had referenced, it is part of 5.22.1 - 924bdf5e is also part of 5.22.1 just committed after the above Just have a look at it here, it is the exact inverse of your patch: https://invent.kde.org/plasma/plasma-workspace/-/commit/924bdf5e So, anything you are experiencing with 5.22.5 can not be fixed by the above, and the revert can not be backported by Gentoo, because it will make another bug resurface. Therefore, please create a new bug upstream at bugs.kde.org, if you can't find an existing bug that is more fitting to your error description, with full details about currently installed versions (kinfocenter provides useful output to clipboard), link to the commit that you have established is breaking the shortcut for you, and feel free to link back to this downstream report as well, and make us aware of it for tracking purpose. Bonus points for also testing Plasma 5.23.2 just in case the problem was fixed elsewhere.
. > I'm re-iterating just to make sure we are on the same page: > - 42b1039e is the fix from the MR you had referenced, it is part of 5.22.1 > - 924bdf5e is also part of 5.22.1 just committed after the above > Just have a look at it here, it is the exact inverse of your patch: > https://invent.kde.org/plasma/plasma-workspace/-/commit/924bdf5e > > So, anything you are experiencing with 5.22.5 can not be fixed by the above, > and the revert can not be backported by Gentoo, because it will make another > bug resurface. Nice catch. I didn't think of checking the other commits. I will next time something like this happens. And yes, you're explanation makes sense. However, why would they revert the commits referenced in comments 17 and 18 are reverted shorty after they were committed? > Therefore, please create a new bug upstream at bugs.kde.org, if you can't > find an existing bug that is more fitting to your error description, with > full details about currently installed versions (kinfocenter provides useful > output to clipboard), link to the commit that you have established is > breaking the shortcut for you, and feel free to link back to this downstream > report as well, and make us aware of it for tracking purpose. Bonus points > for also testing Plasma 5.23.2 just in case the problem was fixed elsewhere. Ok. I can do that, however I've actually found a number of commits that reference the original commit I listed. https://bugs.kde.org/show_bug.cgi?id=413368 https://bugs.kde.org/show_bug.cgi?id=433271 https://bugs.kde.org/show_bug.cgi?id=412250 (I guess, but not really) I don't know it would be wise to make another one, as they've closed them all and referenced 437364. Maybe I should just add a comment with a reference this bug in 437364, and it's currently in reopened status? Or should I just go ahead and open a new bug? I would much appreciate your thoughts, Andreas. Also, I did test 5.23.2, it does have the same original problems with KRunner shortcuts as did 5.22.5.
Sorry, what I was trying to say... However, why would they revert the commits referenced in comments 17 and 18 if those are the commits that are referenced when they closed the bug ticket? Sorry, sometimes I get distracted. 😁
Hey Andreas, I may have spoken too soon about your patch. I've been using it since you posted it yesterday, and it seems that my KRunner shortcuts have been working all that time. So maybe it really does sometimes to address the issue?
(In reply to Randall from comment #10) > > So, anything you are experiencing with 5.22.5 can not be fixed by the above, > > and the revert can not be [backported] by Gentoo, because it will make another > > bug resurface. > > However, why would they revert the commits referenced in comments 17 and 18 > are reverted shorty after they were committed? Sorry, precise language: [backported] meant *your* patch and I should have said "used" or "patched" instead. Nothing was reverted upstream. (In reply to Randall from comment #10) > https://bugs.kde.org/show_bug.cgi?id=413368 > https://bugs.kde.org/show_bug.cgi?id=433271 > https://bugs.kde.org/show_bug.cgi?id=412250 (I guess, but not really) All these bugs are reported with versions earlier than 5.22, so it makes sense they were closed because upstream assumes they are fixed by >=5.22.1. So really, you are likely experiencing a different bug, that may or may not have already been around pre-924bdf5e, which may just influence the frequency of it happening or not; maybe it is simply one of the enabled runners that is crashing krunner and you just think it is the shortcut not working. You can test that by manually invoking the krunner command instead of using the shortcut. (In reply to Randall from comment #12) > I've been using it since you posted it yesterday, and it seems that my > KRunner shortcuts have been working all that time. So maybe it really does > sometimes to address the issue? And this comment makes me think you need to really watch it over a bigger time frame to be sure. Maybe your own patch did not help at all; maybe tomorrow you will have reproduced the problem again with my patch.
(In reply to Andreas Sturmlechner from comment #13) > Sorry, precise language: [backported] meant *your* patch and I should have > said "used" or "patched" instead. Nothing was reverted upstream. I believe I did the same thing. I meant to say is, why would the code be removed or modified if it reintroduces the issue they just intended to close? I can only assume it's most likely intentional, which I guess means it makes sense that this most likely would be a new bug then. > So really, you are likely experiencing a different bug, that may or may not > have already been around pre-924bdf5e, which may just influence the > frequency of it happening or not; maybe it is simply one of the enabled > runners that is crashing krunner and you just think it is the shortcut not > working. You can test that by manually invoking the krunner command instead > of using the shortcut. Well, this didn't happen at all till after I updated to 5.22. I pay attention to this type of stuff. So I know at the very least, it must have to be something changed with 5.22. I did check the individual runners, and also running from command line. I couldn't determine any one runner being the issue. As for the command line option, it didn't do anything. > And this comment makes me think you need to really watch it over a bigger > time frame to be sure. Maybe your own patch did not help at all; maybe > tomorrow you will have reproduced the problem again with my patch. That's a good idea. I'll keep an eye on it. So far, still so good. Maybe I'll go back to 5.22.1 and compare. I'll report back anything here.
I'm gonna close this. This hasn't been a problem for a while. It must have gotten fixed upstream.
