Version: 4.5 (using KDE 4.5.2) OS: Linux This is a regression introduced with kde 4.5 I am not the only one noticing this, it is marked on a blog somwehere. Can't find it anymore. Anyhow should be extremely simple to reproduce. Reproducible: Sometimes Steps to Reproduce: press alt-f2 enter a command press <enter> Actual Results: sometimes I have to press <enter> twice because krunner apparently neglects or misses my first enter. Expected Results: I expect krunner to always react to key presses. It always did so before kde 4.5.
I did have this problem, it only seemed to happen when the text I entered matched the auto-complete text I had entered previously. However, in an openSuse update about 2 weeks ago the problem stopped, so this might be fixed.
The same problem here since 4.5. Very annoying! I can reproduce it every time: Type anything fast, for example "firefox" and press enter. Nothing happens, but if you wait for displaying the results for the string and you press enter afterwars it works. Or you have to press enter twice, it works too. Thanks in advance!
I'm using OpenSuSE 11.3 with the latest KDE (4.5.2) and the problem still exists here.
Similar problem. It didn't occur until several days ago (probably after a Kubuntu update). To me the problem appeared to be a seemingly unnecessary short delay (about one second) before list of candidate applications is shown and "enter" can be recognized and accepted by krunner. At first I thought the cause was that I enabled too many plugins for krunner and thus it took longer for krunner to search against its cache. Therefore I disabled all plugins except "Applications". But that didn't work. It was not until then that I began to suspect that this might actually be a newly introduced bug. I wonder if this bug can be fixed by caching keyboard input (especially the terminating "enter") for a second or two so that users who type fast to launch their favorite applications don't have to wait for the list of candidate applications to appear. By the way, I'm using KDE v4.5.1 on Kubuntu 10.10 (amd64).
Hi John van Spaandonk, Is the following blog article what you are referring to? http://aseigo.blogspot.com/2010/02/krunner-responsiveness.html
@Zane Tu: No this is not the blog post. I cannot find it anymore, but it was a review of kde 4.5 and mentioned the problem with krunnen (alt-F2 / run command) sometimes missing the enter key after a command was pressed. The post from Aaron is about something else: krunner waiting too long to appear after pressing alt-f2. Observation: Looks like if I wait after typing until krunner shows the selection the problem does not occur. In other words, krunner is busy with its internal processing and therefore misses my keystroke [enter]. But for me the usefulness decreases if I have to explicitely wait after typing something. It would be nice if Aaron could repair it. I guess it would help if the developers use really old hardware / limited memory etc. to test. This could be an error that typically does not show when you have fast hardware.
I have fast hardware with 4G RAM, and the problem is still here. The results appear instantly (before I finish typing "firefox") but I have to wait some time (~500ms) to get the Enter caught.
Strange that you still get the bug when it's long since disappeared on my openSuse 11.3 install (currently on KDE 4.5.4). Could we get a quick survey on distro version and KDE version? I suspect that it may be a config problem rather than a code bug, could you try creating a brand new user and log in with that user to see if they have the problem? Also has anyone tested my theory about the auto-complete text?
My hardware: Pentium IV-2.6 GHZ 1GB RAM Asus P4P800 PRO motherboard ATI Radeon 9600SE Using up-to-date Arch linux, with newest mesa, ATI mesa driver etc. Never had this problem in KDE 4.5, so for me it is a clear regression. Perhaps having todo with the mentioned changes by aseigo
I meant to say: never had this problem _before_ kde 4.5
As I could try it has nothing to do with auto-completion. It works like a charm with a newly created user. So I compared the newly created and my old krunnerrc, but didn't found anything useful. I deleted my krunnerrc and it works now. Let's see if it's really gone.
Hi all, I seem to have pinpointed the root cause. The problem is probably due to a much too long command history, which is recorded in lines starting with "PastQueries=" and "LaunchCounts=" in ~/.kde/share/config/krunnerrc. After killing all "krunner" processes, deleting the two lines mentioned above, logging out, and logging in again, krunner began honoring the terminating "enter" key promptly. By the way, I didn't have this problem before kde 4.5, even with a long command history.
Zane, excellent detective work! I knew it was something to do with the history completion, hopefully that's enough info now for someone to track the problem down.
On Tue, 7 Dec 2010 10:52:40 +0100 (CET), John Layt <john@layt.net> wrote: > https://bugs.kde.org/show_bug.cgi?id=254365 > > > John Layt <john@layt.net> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |NEW > Ever Confirmed|0 |1 > > > > > --- Comment #13 from John Layt <john layt net> 2010-12-07 10:52:38 --- > Zane, excellent detective work! I knew it was something to do with the > history > completion, hopefully that's enough info now for someone to track the > problem > down. > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug. Zane, also from my side congratulations. I can confirm this solves the problem. Presumably temporarily, until the list becomes too large again. Let's hope somebody will solve this regression before kde 4.6...
I found out that the "PastQueries" line was the real culprit: the other, "LaunchCounts", is used by Plasma's RunnerContext but it does not slow down KRunner's search (maybe it makes launching slower... I don't know). The LaunchCount can easily be cleared by a D-Bus command. In fact, the cleaning methods are all ready for use, but they are never called anywhere ! The D-Bus command is: qdbus org.kde.krunner /MainApplication clearHistory That might be something to run on session start, it just depends on how much you use the history... Better would be to restrict the size of the list, so that only a recent history is kept. I'll see if I can do it.
It turns out there might already be a limit of 50 history items (the oldest entry gets removed when a new one is added), but I cannot find where that limit is set in KRunner's source code. The bug would probably be fixed by setting it to 5 or 10, which should be fine.
commit 3894923 in KDE/4.10 and master branches of kde-workspace.