Version: unknown (using 4.1.00 (KDE 4.1.0), Debian packages) Compiler: cc OS: Linux (i686) release 2.6.26-1-686 When typing really fast, it seems as if the enter key is evaluated before the program matching is done. When typing kpat<CR>, I start kontact or kpackage, depending on how fast I type.
Same here (4.1 on ArchLinux), depending on speed for example typing "oper" opens Opera or OpenOffice (if slower). It's annoying.
this behaviour is also available on kubuntu intrepid alpha 6.
Even typing the full command of an app does not work if you type too fast. For example if I type "kdesvn"+enter quickly, krunner will launch KAppTemplate. If I slow down, it launches kdesvn. This is a critical bug for a keyboard launcher where the whole point is to be quick and predictable.
Critical might be a tad too much, but I would agree that it is major. That is up to the devs, though. Is anyone actually working on/looking at this?
This seems to be related to http://bugs.kde.org/show_bug.cgi?id=154228 and might need to be merged.
*** Bug 175110 has been marked as a duplicate of this bug. ***
*** Bug 173598 has been marked as a duplicate of this bug. ***
dont know if that's it but quite often when i type something (ex "gg:bla"), then the window that pops up (if ever) is the result from another "gg:*" i tried few days ago. really weird. reproduced from 4.1 to 4.2 through most of 4.2 betas
I believe that this bug, and possibly #170032 are caused by the following situation: In the code there's a locking mechanism to prevent running matches which refer to previous queries; namely, before running the default item, the variable m_queryRunning is checked to see if there's a pending query we need to wait for; if (m_queryRunning) { m_delayedRun = true; } else { // do something } m_queryRunning is set to true each time a query is /launched/ (i.e. each time we add a letter to the search term) and set back to false each time the query returns some non-trivial result. So here's what I believe it happens. I take as an example typing "system settings" because that's how I can reproduce the bug: A bunch of items are obtained by querying for "system". It takes a relatively long time to find all the items; in particular the nepomuk search is quite late. Suppose I manage to type "system settings" before the first matches are even retrieved; as soon as they are received m_queryRunning will be set to false and the lock is gone, even if the query for "system settings" is still running. Whenever I hit enter, then I'm going to run the first result for "system", in my case it's the sweeper. The lock with a bool (m_queryRunning) is very fragile, a counter would be better; unfortunately a single query may end up in one, many or no calls to matchCountChanged, so it's not the right way to keep track of pending queries. Does it make any sense? --J
for me, it still happens in 4.2.1
Please confirm this is still present with 4.2.2
Works perfectly now in krunner.
This bug seems fixed in 4.2.2 here as well. Thanks!
seems fixed in 4.2.3, thanks.
Closing then! It should have been fixed in 4.2.2 and no negative reports since then. Thanks all for feedback