Krunner focus + focus follow mouse

Support KDE Plasma
1

Hi guys!

Seems like a little bit of 1st world problem (and it is), but after updating Plasma from 6.3.x to 6.5.x I have this annoying issue that I can’t resolve yet.

I mostly use KRunner to launch my programs, and I use “focus follows mouse” on my system, because we are all lazy; that’s the truth. The thing is that since Plasma 6.5, my “focus follows mouse” is interfering with KRunner (I don’t know if it was bugged before in 6.3.x, but I didn’t have this issue).

For example, before the update, I started to write the name of the program, KRunner ignored the mouse, highlighted the first result, and I just pressed ENTER and launched my desired program.
Now, when I try to do the same thing, the mouse keeps highlighting anything in the middle of the results. For example, I want to run caffeine, and then this happens:

krunner_not_focusing_correctly
krunner_not_focusing_correctly623×601 49.1 KB

The only way I found to make this work is to move the mouse out of the way before running Krunner, which is the least annoying way, but still annoying.

I tried to play with Windows rules with “prevent focus” or “focus protection,” but with no luck (probably because it is the same window).

Is there a way to make KRunner ignore the “focus follow mouse” setting so it keeps pre-selecting the first result when I type??

Thanks in advance.

Edit: Marked as solved because there is no solution yet, but if you arrive at this post, feel free to check the comments below that have very useful related information. At least it was useful to me, maybe it could be useful to you as well.

2

The good news: The issue has already been reported to KDE.
The bad news: It was first reported in 2016 and appeared to have been fixed, but has managed to recently reappear.

2 Likes
3

Not something I normally use, but confirmed. Thing is, my mouse pointer will usually still be in the area of the text box when I type, which avoids the issue.

I did notice the cursor stops flashing as soon as I move the pointer away (and it highlights whatever it’s hovering over) but the text box is still “focused” so to speak and I can add/remove text without moving the pointer back and clicking on it again.

What I haven’t tried is hitting Enter; it’s not something I do with a GUI element, where it can be avoided. I never just blindly assume the “default” selection is what most people expect it to be.

1 Like
4

Hmmm whilst it IS the truth, there’s a lot to be said for efficiency and caution.

I am interested to learn more - my experience is that a click is 100% predictable (and works with popups). When I set to follow the mouse, then there needs to be a delay so that it only reduces your action by one click, but it does mean you have to WAIT for it.

Then also, you can’t maintain focus on a window whilst moving the mouse to do something else… so focus stealing is a huge problem now - and then I’m sure everything’s going to go through a huge new development stage after shifting from X11 to Wayland.

Right now I’ve a couple of windows, and as I’m typing I can use Meta Alt with arrows to shift between them (including any hidden behind) as well as Meta W , Meta G , mouse to the corner to ‘present all windows’ etc.

Messing with this now, however, I noticed that I can still use keyboard shortcuts which disables the mouse focus…

The Issue at hand:

Ok, so I’m here because I remember this issue…

I think mostly for something I remember launches from a few characters, without looking, would get something different instead) but I also cannot remember WHEN I had this issue. Right now (with or without mouse focus set) there seems no issue.

As soon as I start to type, the cursor disappears and everything seems to be working as expected:

KDE Plasma Version: 6.5.5KDE 
Frameworks Version: 6.22.0Qt Version: 6.10.1
Kernel Version: 6.18.6-1-MANJARO (64-bit)Graphics 
Platform: Wayland

So thanks for the push, I’m trying this out now because I’m really interested to find out (like the old single vs double click to open) whether it can be more efficient… though I fail to see the benefit of a system that’ll activate all windows in the path of the mouse if I decide to have three in a row, and wish to go from the first to the third.

Focus stealing prevention is set to LOW… not sure how relevant that is.

For now, with the absence of Mouse Gestures, my primary aid tends to be the two thumb buttons set to Present Windows and Grid.

Something I find very useful (occasionally):

I can middle click to LOWER an active window, so I can see my browser or text editor; but I can still type in a window which is not on top. Now this means I can set my terminal, let’s set that active and below Firefox.

I can resize firefox using my keyboard/mouse whilst it covers the terminal, but still type into the terminal.

1 Like
5

Actually, focus-follows-mouse was the way the original window managers on UNIX used to work, and many conservative UNIX admins still prefer it that way.

Indeed, which completely negates whatever usefulness focus-follows-mouse might offer, in my humble opinion.

2 Likes
6

Well you can adjust it… but I only gave it a ten minute trial. It dispelled quite a few misconceptions - but inevitably feels like a less flexible experience for the sake of an intentional tap to confirm that you’re selecting the window under the mouse.

2 Likes
7

First of all, thank you guys for taking time out of your day to see this and share your insights.
I agree it is not the most efficient way; it is just what I am accustomed to use. I think I am midway between a full mouse experience and a title window manager kind of style.

What you and @Aragorn said about the waiting could be an issue. The focus timing in my current settings is long enough to allow me to go from one window to another (even on another monitor) without raising all the windows between them but is short enough that the delay to focus is mostly shorter than the time it takes to position my mouse hand on the keyboard again (and that ‘moving hand’ time is spent anyways, independent of whether I use it with focus follows mouse or not). So for me, there isn’t much of a waiting problem, but it is also true that the “saving” using ‘focus follow mouse’ is minimal, just “the click”! When it really pays off is when you have a few windows open and have to scroll, alternating between them (comparing queries, text files, or code). That is when I miss it the most. (I have a long way to go to become a vim wizard.)

In my experience I had problems with both. With ‘click to focus’ thinking, I am focusing on the window where the pointer is at and sending keystrokes anywhere else, or accidentally moving the mouse while using ‘focus follow mouse’ and sending keystrokes anywhere else. And I know the system is doing what it’s supposed to do; the problem here is between the chair and the monitor :worried:.

But this shortcut I didn’t know it:

I usually used Alt Tab to switch but the big difference is that with this, you can’t see the window until you switch, which is a problem when you have several similar windows opened. Maybe with this in mind I give ‘click to focus’ another try.

I am going to mark @Takakage post as a solution since there is no solution and it is already reported.

Thank you all for sharing your knowledge and experience.

1 Like
8

You cleared up my doubt and made me laugh at the same time, so I am grateful for both.

Thank you for taking time to answer!

2 Likes
9

That depends on which task switcher you’re using. There are several different ones to choose from — you should check them all out — and you can set up an alternative method as well. :wink:

1 Like
10

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.