SUMMARY STEPS TO REPRODUCE 1. Open a text editor 2. Invoke Krunner 3. IMMEDIATELY start typing, don't wait for the dialog to pop up. OBSERVED RESULT Half of your text will be entered into the text editor, and the other half will be entered into Krunner. Krunner isn't terribly fast to open (about 0.3 sec delay on my machine), and until the dialog pops, it's not intercepting your keystrokes. This is unacceptable behavior for a launcher IMO. It never happens on Gnome or Windows AFAIK. EXPECTED RESULT The launcher should start intercepting all keystrokes entered after invoking the launcher, even if it can't draw the actual input dialog fast enough. Of course it's important to display the popup quickly - and KRunner could definitely use a performance improvement - but it is doubly important for a slow launcher to start capturing right away because otherwise the user will end up typing text into whatever window is open. This happens to me regularly when using krunner.
Yeah, can confirm.
If I invoke krunner by typing on the desktop it won't accept the first letter typed the first time it is invoked- but other letters will come through even when they were typed before the input dialogue box appears. For example, if I type "shut down" really fast before the box pops up it will appear as "hut down". When krunner is invoked again during the same session it will work correctly. This is in KDE Neon 5.17.5
Since this issue was annoying me for some time now, I have just submitted a pull request to fix it (and one more): https://phabricator.kde.org/D26718 @Kai Uwe Broulik I haven't noticed this bug report earlier, and now I see you are assigned to it. Do you have a different solution already? Would you mind checking mine? Thanks.
*** Bug 416776 has been marked as a duplicate of this bug. ***
https://phabricator.kde.org/D26718 was modified to resolve this issue for DesktopView only. @leftcrane For running KRunner from shortcut: you may workaround this by autostarting the KRunner service: `krunner --daemon`
*** Bug 413420 has been marked as a duplicate of this bug. ***
There are some other steps we can do. To get input we just need a window with focus. We don't need it loaded with the QML. We can swap this to be - create window - show() (but invisible and empty) - load QML (and libplasma and all the heavy parts) - show and position input won't get dispatched till the event loop runs, at which point we'll have our text field.
Git commit 1c48e351c646212c539392a361a93606274b9211 by David Edmundson. Committed on 03/04/2020 at 11:32. Pushed by davidedmundson into branch 'master'. [krunner] Avoid reparsing the config load on start Reviewers: #plasma, apol Reviewed By: apol Subscribers: apol, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D28365 M +10 -5 krunner/view.cpp M +1 -1 krunner/view.h https://commits.kde.org/plasma-workspace/1c48e351c646212c539392a361a93606274b9211
Git commit 6dc04ef0adec2e96f81766d5d2b5b2483f1ad145 by David Edmundson. Committed on 03/04/2020 at 11:33. Pushed by davidedmundson into branch 'master'. [krunner] Avoid a uneeded pointless config parse Summary: We are krunner, our default config will be krunnerrc, we can load the instance we've already loaded in the QPT instead of doing it again. Reviewers: #plasma, apol, broulik Reviewed By: #plasma, apol, broulik Subscribers: apol, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D28368 M +1 -1 krunner/view.cpp https://commits.kde.org/plasma-workspace/6dc04ef0adec2e96f81766d5d2b5b2483f1ad145
Git commit e2d372d3dfd14ea3210a9e1f5755883bd2578c18 by David Edmundson. Committed on 03/04/2020 at 11:32. Pushed by davidedmundson into branch 'master'. [krunner] Don't set the position three times in a row Summary: loadConfig calls setFreeFloating. setFreeFloating calls setLocation Reviewers: #plasma, apol Reviewed By: apol Subscribers: pereira.alex, ngraham, broulik, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D28366 M +0 -7 krunner/view.cpp https://commits.kde.org/plasma-workspace/e2d372d3dfd14ea3210a9e1f5755883bd2578c18
Hi, I still have this issue in Plasma 5.18.4.1. I’m not sure I’m running a version with the improvements of David Edmundson, though. I think that this issue is important because it can give the impression that Plasma is slow or buggy. Regularly, *even when KRunner is already started*, the first letter I type after using the keyboard shortcut is entered in the wrong place (aka in my browser or my code editor), on a powerful laptop. It’s very annoying because I may not have noticed I typed a letter in the wrong place, thinking the letter was just «lost», because when invoking Krunner I’m already thinking of the next task and I don’t remember where my cursor/focus was. So starting KRunner ahead of time is not a working workaround for me, because my issue is the time an already opened Krunner take to capture input.
Disabling the unit converter fixes the problem for me, so maybe this is an issue with some runners. I’m not sure if the issue is from kdeplasma-addons (where there’s krunner_converter) or from frameworks-kunitconversion, though.
Hmm, the unit converter runner shouldn't be that heavy. If you really want to improve this, disable the "Software Center" runner.
I don’t use the “Software Center” runner. Interestingly, I don’t see a difference between enabling it or not today, though at the time of the test my system was under more load than right now. Anyway, it’s not fixed for me after all, there is still delay even when disabling all the runners.
Is this still an issue? For me it works properly on On KDE Neon unstable.
Still an issue for me.
Created attachment 129332 [details] attachment-4364-0.html I'm still having this issue as well. On Fri, Jun 12, 2020 at 8:48 PM Nate Graham <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=416145 > > --- Comment #16 from Nate Graham <nate@kde.org> --- > Still an issue for me. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
Could you please check if it got fixed/improved by https://invent.kde.org/ngraham/plasma-workspace? @ngraham already reported that this seems to improve the issue.
...rather, https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/92/diffs?commit_id=6fcc54a5e4784587fc5cdc9cabc0fd67f2731c3d.
Whoops
Created attachment 129779 [details] attachment-23671-0.html I'm sorry, I am guessing this is a patch you want me to apply? I am not a developer, and do not know how to do this. If it's something you can walk me through without taking too much of your time, I'm game- but I'd understand if not. On Mon, Jun 29, 2020 at 3:34 PM Alexander Lohnau <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=416145 > > --- Comment #20 from Alexander Lohnau <alexander.lohnau@gmx.de> --- > Whoops > > -- > You are receiving this mail because: > You are on the CC list for the bug.
If you don't want to cmopile krunner from source (for that, see https://community.kde.org/Get_Involved/development#Plasma) you could maybe install KDE Neon Unstable edition in a VM after a few days and test in there.
Created attachment 129859 [details] attachment-24621-0.html I've installed KDE Neon Developer's Edition in a VM. After updating and restarting, krunner crashes immediately upon trying to invoke it by typing on the desktop. I can submit the crash report and backtrace this weekend sometime, but I just wanted to let you guys know I'm still here! Doug On Tue, Jun 30, 2020 at 12:47 AM Nate Graham <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=416145 > > --- Comment #22 from Nate Graham <nate@kde.org> --- > If you don't want to cmopile krunner from source (for that, see > https://community.kde.org/Get_Involved/development#Plasma) you could maybe > install KDE Neon Unstable edition in a VM after a few days and test in > there. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
I've disabled the PIM Contact Search module that was causing krunner to crash per Bug 423003, but the behavior of krunner seems the same as before. I'm on Neon Developer's Edition 5.19.80, updated as of 7/9/20. Just to be clear, when I have focus on the desktop and krunner has not been started, is the desired behavior of krunner: A) typing "Hello" should invoke krunner and send "Hello" to the text box or B) typing "Hello" should invoke krunner, and send "ello" to the text box I'm getting A, but if it's supposed to be B then I guess it is working, though it would seem a papercut if not a bug.
It's supposed to be A, so I'm happy to hear that it's working. :)
Sorry, I meant to say I'm getting "B"- stupid typo on my part! But I went back to check on this again, and found that it's a bit more complicated. If I type "Hello" quickly, or at least normal speed, I get "ello". If I type "H" and wait for the text box to appear, it will appear with an "H" in it, after which I can add the "ello". I checked this several times, stopping "krunner" between each attempt, and it is consistent.
This issue persists on my neon unstable too. The first character typed when desktop is focused and krunner isn't running in background doesn't appear in the search field. Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.19.80 KDE Frameworks Version: 5.72.0 Qt Version: 5.14.2
Darn.
It seems like we are mixing two cases here: 1) KRunner is invoked by Alt+Space and we immediately start typing 2) We are on the Desktop and type really fast (don't wait for KRunner to show up or invoke it manually).
There is a patch ready for using KRunner from the Desktop View: https://phabricator.kde.org/D26718 As for Alt+Space/Alt+F2, there is no solution so far other than autostarting KRunner in advance. But maybe for this shortcut we could: 1. run KRunner 2. focus Plasma Destktop View and rely on the solution above?
>https://phabricator.kde.org/D26718 I guess I should submit this to GitLab now, right?
Yes please :-)
>>https://phabricator.kde.org/D26718 >I guess I should submit this to GitLab now, right? https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/148
(In reply to Alexander Lohnau from comment #29) > It seems like we are mixing two cases here: > > 1) KRunner is invoked by Alt+Space and we immediately start typing > 2) We are on the Desktop and type really fast (don't wait for KRunner to > show up or invoke it manually). Case 1 is also reroducible on neon unstable.
(In reply to Patrick Silva from comment #34) > Case 1 is also reroducible on neon unstable. Weird, I don't have any of these issues on one of my setups. And the other (very recent KDE Neon Unstable install with latest updates) I only have Case2, Case1 was fixed for me with the latest change.
*** Bug 377054 has been marked as a duplicate of this bug. ***
*** Bug 374660 has been marked as a duplicate of this bug. ***
*** Bug 401696 has been marked as a duplicate of this bug. ***
On related not when discussing the issue on reddit people reported that using the KRunner plasmoid called "Search" works really good as a workaround. Maybe someone finds this useful :)
Git commit 003e30a64e976e66c02d3aa8b06301710a231889 by Nate Graham, on behalf of Piotr Henryk Dabrowski. Committed on 09/09/2020 at 18:54. Pushed by ngraham into branch 'master'. aggregate text for KRunner in DesktopView Aggregate text for KRunner in DesktopView to prevent eating fast-typed characters. partial solution: resolved for DesktopView, not resolved for running KRunner from shortcut Test Plan: When DesktopView is focused, typed characters show KRunner query. All fast-typed characters should now appear correctly in KRunner window, instead of only first typed character. M +35 -12 shell/desktopview.cpp M +2 -0 shell/desktopview.h https://invent.kde.org/plasma/plasma-workspace/commit/003e30a64e976e66c02d3aa8b06301710a231889
Git commit 0e575a20ef36532b5b40a40ea30f915976942477 by David Redondo. Committed on 11/09/2020 at 12:23. Pushed by davidre into branch 'master'. Activate KRunner instead of running the binary Currently when we invoke KRunner and it is already running we will start binary, KDBusService will check if it is already registered and then call org.freedesktop.Application.Activate. Cutting the middle out should improve the time that it takes to show KRunner and make it less likely that key strokes are lost. If KRunner is not running we, can rely on dbus activiation to start KRunner. Unfortunately we cannnot call Activate with dbus-send because it doesn't support it's argument type. Instead we can just use the existing display method. M +1 -2 krunner/CMakeLists.txt R +2 -2 krunner/krunner.desktop [from: krunner/krunner.desktop.cmake - 094% similarity] https://invent.kde.org/plasma/plasma-workspace/commit/0e575a20ef36532b5b40a40ea30f915976942477
With the above commit, it’s very very hard to miss more than one letter. I easily miss the first letter though, so it’s not a definitive fix.
Can the Alt+F2 shortcut do two things: 1. immediately focus the desktop (so that we can relay on [1] from here) 2. then show/execute KRunner (with the above in place it doesn't need to be that fast)? [1] "aggregate text for KRunner in DesktopView" https://invent.kde.org/plasma/plasma-workspace/commit/003e30a64e976e66c02d3aa8b06301710a231889 @ariasuni You mean the Alt+F2 invocation, not the desktop typing?
Yes, I was talking about the situation where I invoke KRunner with Alt-F2.
> Can the Alt+F2 shortcut do two things: > 1. immediately focus the desktop (so that we can relay on [1] from here) > 2. then show/execute KRunner (with the above in place it doesn't need to be that fast)? Probably we could do that like this: Alt+F2 calls this new PlasmaShell's method: dbus-send --type=method_call --dest=org.kde.plasmashell /PlasmaShell org.kde.plasmashell.PlasmaShell.displayKRunner which does two things: 1. immediately focuses the desktop 2. then calls (using Qt/C++ DBUS API): dbus-send --type=method_call --dest=org.kde.krunner /App org.kde.krunner.App.display
Or, even better, add focusDesktop() to Plasma and simply modify krunner/krunner.desktop: Exec=dbus-send --type=method_call --dest=org.kde.plasmashell /PlasmaShell org.kde.plasmashell.PlasmaShell.focusDesktop; dbus-send --type=method_call --dest=org.kde.krunner /App org.kde.krunner.App.display so that KRunner can still be opened even when Plasma is not running.
Proof-of-concept for the above (using wmctrl): krunner/krunner.desktop: ... Exec=wmctrl -ai `wmctrl -lxG | grep 'plasmashell' | grep -E -- '-1 +0 +0 ' | cut -d' ' -f1`; dbus-send --type=method_call --dest=org.kde.krunner /App org.kde.krunner.App.display In fact using such a light and independent program like wmctrl to focus the desktop might be beneficial for speed. I'm not sure if requesting PlasmaShell to focus itself will always be fast. After all what we want is to simply tell X11/Wayland to move the focus to the desktop's window and send all the future input there.
(In reply to David Redondo from comment #41) > Git commit 0e575a20ef36532b5b40a40ea30f915976942477 by David Redondo. > Committed on 11/09/2020 at 12:23. > Pushed by davidre into branch 'master'. > > Activate KRunner instead of running the binary This is just to register a regression caused by this commit, where krunner is starting applications with cwd "/" instead of "~", confirmed on several systems to be fixed after reverting 0e575a20. See also downstream bug: https://bugs.gentoo.org/767478
Can you please file a new bug report with that? Thanks!
Seems to work well on KDE Neon. It runs in a VM, work perfectly when under no load, I tried to launch an upgrade at the same time and it still manages to be fast half of the time (I’m not sure how it translates in real use but that’s definitely a huge improvement). It seems the dbus-send trick has been reverted: https://invent.kde.org/plasma/plasma-workspace/-/commit/d544e7657fc756505670c0bfdfb6062a23f8798d And that DBus activation is instead handled directly by kglobalaccel framework: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/609
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/66
I still have this issue in KDE 5.22.3, but I have discovered a very interesting "workaround" that completely solves the issue. In the KRunner settings, if I change the Krunner Position on Screen to "top", it takes at least 3-5 seconds to open up no matter the enabled plugins. However, changing it to "Center" opens Krunner immediately even with a bunch of plugins. I have a Ryzen 9 3900x running in this case Fedora 34 (slowness has been around since I started in Fedora 31). However, on my machine I have discovered that my plasma bar is also very slow, like clicking the Volume icon is extremely slow and laggy, and my plasma bar is at the top of the screen, not sure if the slowness of the plasma bar causes krunner to also be slow when it opens at the top (where the plasma bar is). Or maybe it's completely unrelated, but in any case, if you're having KRunner open slowly, try to change it's placement to the Center of the screen, it solved the issue for me.
I can confirm the workaround. Plasma does not feel sluggish here, but the difference for krunner is still remarkable. I have not been able to type something before krunner pops up, when using the center position. Before, the bug appeared regularly to me.
That is a very interesting observation. The difference between those settings is that the "Top" mode has to calculate its position every invocation using KWindowSystem APIs that take into account the Plasma Panel position and thickness. Perhaps these are heavyweight APIs that need to be made lighter. Or perhaps the position can be cashed and updated only if any of the conditions that affect them (screen resolution/scaling, panel position/thickness) get changed.
maybe this will help https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1230
This occurs especially when I press the windows key and start typing, directly after I logged on. It it the case that the krunner app must load from disk the first time it is run? If this is so then perhaps it is possible to always load the krunner part on startup to prevent this.
Yes, what I always do in all my KDE installs is to autostart "/usr/bin/krunner --daemon". This causes KRunner to be loaded during KDE start-up and not to wait for it until the first time it's needed. I think it'd be nice to include it into default KDE installs, too.
I believe the idea of not having it load immediately was to keep resource use down for default installs. But maybe there could be a simple checkbox "enable KRunner at startup" or something similar.
For me, at this point it seems to be 100% fixed except for the very first invocation after login, where I still get a lost keystroke if I type very very quickly. https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1230 doesn't fix that, which tells me that it's not the DBus panel size querying that's a remaining bottleneck. We could chase further performance improvements, or we could just auto-start KRunner at login.
Lowering priority due to the above.
Same with kickoff. Sometimes it eats the first letter typed. Operating System: Arch Linux KDE Plasma Version: 5.26.0 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 Graphics Platform: Wayland
This has been substantially improved even more, and now it only eats keystrokes when first launched if you're a lightning-fast typist. Reducing priority again.
Still an issue with krunner and kickoff. Operating System: Arch Linux KDE Plasma Version: 5.27.80 KDE Frameworks Version: 5.245.0 Qt Version: 6.6.0 Graphics Platform: Wayland
Same on Plasma 6. Operating System: Arch Linux KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.3 Graphics Platform: Wayland