I usually use krunner via keyboard, like this: - Alt-F2 - "fi" - Enter to start Firefox. # Actual results Yet if I happen to have the mouse pointer within the area to which krunner expands to while listing search results krunner shows the entry over the mouse pointer as selected. When I then hit return, I do not get Firefox started but an PDF opened or an image or whatnot. # Expected result Start the best fit that matches what I type and ignore the mouse pointer location. I think an easy workaround would to only select an item from krunner by mouse if the user actually presses the left mouse button. I see no point in the on hover selection. Sure I could use the mouse and then still hit the enter key, but what for? Either I use the keyboard or I use the mouse.
*** Bug 373154 has been marked as a duplicate of this bug. ***
> I think an easy workaround would to only select an item from krunner by mouse if the user actually presses the left mouse button. I see no point in the on hover selection. Sure I could use the mouse and then still hit the enter key, but what for? Either I use the keyboard or I use the mouse. Alternatively (because the on-hover graphical effect is nice and potentially helpful), pressing the Enter key could entirely ignore th selected item if it was selected with the mouse. (Of course the selection should be honored if it was done with the keyboard.)
Any update on this one? This easily qualifies as the most annoying bug I currently have with Plasma. I triggered it at least 10 times in the last two days. And whenever I trigger it krunner starts something completely unrelated to what I wanted to start. For now I consider to just disable any and all krunner plugins to reduce the likely for this issue to happen again. Have a merry christmas, (and yes I understand if there would not be a reply before it anymore). Martin
*** Bug 374044 has been marked as a duplicate of this bug. ***
(In reply to Ralf Jung from comment #2) > > I think an easy workaround would to only select an item from krunner by mouse if the user actually presses the left mouse button. I see no point in the on hover selection. Sure I could use the mouse and then still hit the enter key, but what for? Either I use the keyboard or I use the mouse. > > Alternatively (because the on-hover graphical effect is nice and potentially > helpful), pressing the Enter key could entirely ignore th selected item if > it was selected with the mouse. (Of course the selection should be honored > if it was done with the keyboard.) I do not like an out of sync visual representation with actual behavior. For this reason I propose to select an item only on mouse move or click.
Either I never noticed it before or this must have been introduced by a recent update. It annoys the crap out of me as well. The KRunner list usually has a length of about half my screen height and one quarter its width. Since I rarely have my mouse cursor anywhere but around the center of my screen, it's very likely that I select something I didn't intend to select. What I notice is: when I invoke KRunner and type something, the first list item is selected, but then the selection is replaced by whatever my cursor is hovering over. I think the best solution would be to only change the selection if I actually move my mouse cursor. When I use the keyboard, I don't touch the mouse, so the cursor is stationary. A stationary cursor should not change the selection. An easy criterion for checking this would be if the cursor has moved since the last KRunner list update. If it hasn't, don't let it select anything.
This. Please. It happens to me as well at least 5 times each day, it's very frustrating :(
From what I can tell Qt now processes mouse events even if the item moves underneath the mouse without the mouse moving. While this is a good thing in principle, it causes this side-effect as items show up under the mouse and then it fires a hover event. I'm still looking for a good way to fix this, other than randomly adding timers...
Kai, thank you for thinking on a fix. Whatever the fix may be: Please consider to backport it to Plasma 5.8 LTS, cause this way it can still be integrated in distributions – giving much relief to users how would otherwise be stuck with this really annoying bug for years. I am volunteering to hint Debian Qt/KDE team at a fix thats usable in Plasma 5.8 LTS.
I would try to fix this, if somebody could point me in the right direction. My idea is to get the current cursor position, when the krunner pops up and ignore the hover event, when the mouse position doesn't differ from the previously saved position. I guess the UI is painted with QtQuick2 in plasma-workspace/lookandfeel/contents/runcommand/RunCommand.qml and is clued together in plasma-workspace/blob/master/krunner/view.cpp, but I cannot find where the mouse events are processed..
The processing happens in Qt itself.. your best guess would be having a look at milou (which the ResultDelegate comes from and try your luck in there)
Is it possible to detect the start and end of the animation? In this case it should be possible to deregister the listener of the mouse move event while the animation is going on and re-register is afterwards.
Created attachment 105009 [details] Disable mouse from stealing focus If this patch is applied to ResultDelegate.qml from milou, the mouse animation for the current list item is disabled, but the rest works as expected (Selecting via keyboard or clicking with mouse).
Works for me. Thanks a lot!
Propose a proper patch that enables hovering + highlight with mouse after the mouse moves. https://git.reviewboard.kde.org/r/130088/
(In reply to Leszek Lesner from comment #15) > Propose a proper patch that enables hovering + highlight with mouse after > the mouse moves. > https://git.reviewboard.kde.org/r/130088/ Found out reviewboard isn't used anymore and posted to phabricator here: https://phabricator.kde.org/D5490
Git commit a41a850a3943dbc1bd43b867def775e41902f987 by Peifeng Yu. Committed on 30/04/2017 at 18:20. Pushed by peifengyu into branch 'master'. Only follow mouse when moved (Fixes Bug #372635) Summary: Use a new variable moved to detect if mouse moved and only change index if the mouse moved. This helps preventing index changes when only using keyboard to search something in milou and to not accidently start/open something you did not want (see bug report https://bugs.kde.org/show_bug.cgi?id=372635 ) In general the onEntered signal seems to be broken in Qt somehow as I could not make it work reliably with Qt 5.7.1. Sometimes it worked but mostly the code using onEntered failed to work with onPositionChanged (I guess this also does not always set it to true). Hence I tried containsMouse which seems to work reliably at least on Qt 5.7.1. Tests are appreciated especially on other Qt versions. Reviewers: broulik, davidedmundson Reviewed By: davidedmundson Subscribers: ltoscano, qi437103, lfurmetz, anthonyfieroni, davidedmundson, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D5490 M +1 -0 lib/CMakeLists.txt A +40 -0 lib/mousehelper.cpp [License: GPL (v2/3)] A +44 -0 lib/mousehelper.h [License: GPL (v2/3)] M +12 -4 lib/qml/ResultDelegate.qml M +9 -0 lib/qml/ResultsView.qml M +5 -0 lib/qml/qmlplugins.cpp https://commits.kde.org/milou/a41a850a3943dbc1bd43b867def775e41902f987
Dear Aetf. *Thank you*. Finally, this quite annoying issue received a fix. Any plans to backport this to Plasma LTS 5.8 release? It would improve the user experience on all the distributions that ship with it considerably, like next Debian Stretch. *If not* I may still point Debian Qt/KDE team at this and if its easy enough to carry it as a patch they may include it. Thanks, Martin
*** Bug 379859 has been marked as a duplicate of this bug. ***
(In reply to Aetf from comment #17) > Git commit a41a850a3943dbc1bd43b867def775e41902f987 by Peifeng Yu. > Committed on 30/04/2017 at 18:20. > Pushed by peifengyu into branch 'master'. > > Only follow mouse when moved (Fixes Bug #372635) > > Summary: > Use a new variable moved to detect if mouse moved and only change index if > the mouse moved. This helps preventing index changes when only using > keyboard to search something in milou and to not accidently start/open > something you did not want (see bug report > https://bugs.kde.org/show_bug.cgi?id=372635 ) > > In general the onEntered signal seems to be broken in Qt somehow as I could > not make it work reliably with Qt 5.7.1. Sometimes it worked but mostly the > code using onEntered failed to work with onPositionChanged (I guess this > also does not always set it to true). > Hence I tried containsMouse which seems to work reliably at least on Qt > 5.7.1. > Tests are appreciated especially on other Qt versions. > > Reviewers: broulik, davidedmundson > > Reviewed By: davidedmundson > > Subscribers: ltoscano, qi437103, lfurmetz, anthonyfieroni, davidedmundson, > plasma-devel > > Tags: #plasma > > Differential Revision: https://phabricator.kde.org/D5490 > > M +1 -0 lib/CMakeLists.txt > A +40 -0 lib/mousehelper.cpp [License: GPL (v2/3)] > A +44 -0 lib/mousehelper.h [License: GPL (v2/3)] > M +12 -4 lib/qml/ResultDelegate.qml > M +9 -0 lib/qml/ResultsView.qml > M +5 -0 lib/qml/qmlplugins.cpp > > https://commits.kde.org/milou/a41a850a3943dbc1bd43b867def775e41902f987 Thanks a lot for fixing it Aetf! :D
*** Bug 379910 has been marked as a duplicate of this bug. ***
Thanx! Fixed for me as well, a big annoyance is gone now, really appreciate it!!