Version: unspecified (using KDE 4.5.5) OS: Linux I have "focus follows mouse" set and when in a certain desktop, it works great. When I switch (alt+left/right arrow) to another desktop, the focus is NOT in the correct widget. The focus works after I move the mouse. Reproducible: Always Steps to Reproduce: Activate the "focus follows mouse" setting "system settings -> look and feel -> window behavior -> Move the mouse to achieve focus in a widget. alt+left/right arrow to navigate to a new virtual desktop (I have 6 desktops) observe that the widget where the mouse is located does NOT focus until you move the mouse. Actual Results: Focus follows mouse fails when navigating to new virtual desktops Expected Results: I would expect the focus to be associated with the current widget in the new desktop.
This behavior also exists on my Fedora Core 14 system.
Focus follows mouse only sets the focus on enter/leave events - never on random "mapping below" - you'd have to use one of the two stricter (eg. "focus under mouse") policies to for this. That said, one could discuss about an exception on desktop switching and explicitly recalculate the focus afterwards. (though this breaks the so far behaviour)
*** Bug 183559 has been marked as a duplicate of this bug. ***
Thomas, I have set the focus to "focus under mouse". This disables the fancy switching between widgets. I REALLY like this. Is this NOT A BUG? Regards, George... "It's not what you know that hurts you, It's what you know that ain't so." Wil Rogers --- On Wed, 1/26/11, Thomas Lübking <thomas.luebking@gmail.com> wrote: From: Thomas Lübking <thomas.luebking@gmail.com> Subject: [Bug 264368] "Focus follows mouse" focus should be explicitly recalculated after desktop switching To: grgoffe@yahoo.com Date: Wednesday, January 26, 2011, 1:19 PM https://bugs.kde.org/show_bug.cgi?id=264368 Thomas Lübking <thomas.luebking@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Focus follows mouse and |"Focus follows mouse" focus |switch to new virtual |should be explicitly |desktop fails to focus on |recalculated after desktop |"current" widget |switching Severity|normal |wishlist --- Comment #2 from Thomas Lübking <thomas luebking gmail com> 2011-01-26 22:19:21 --- Focus follows mouse only sets the focus on enter/leave events - never on random "mapping below" - you'd have to use one of the two stricter (eg. "focus under mouse") policies to for this. That said, one could discuss about an exception on desktop switching and explicitly recalculate the focus afterwards. (though this breaks the so far behaviour)
(In reply to comment #4) > I have set the focus to "focus under mouse". This disables the fancy switching > between widgets. Can you please explain what you mean by this, preferably naming the effect or at least describe it more precisely than "fancy"?
Thomas, My apologies for leaving this out. When I set the "stronger" focus parameter, look and feel -> windows behavior -> navigate through windows reports the following: "Focus policy settings limit the functionality of navigating through windows." With "focus follows mouse", the fancy "navigate through windows" is the feature produces an AWESOME display. At the top is a strip of widgets in the desktop. The center is the "current" widget, on both sides of the "current" widget are the other widgets, displayed in sequence. They're displayed kind of in isometric order. I don't have the right word for this. You can see all of the widgets kind of stacked but offset from each other... REALLY HARD TO DESCRIBE. My settings to achieve this are in the " p, li { white-space: pre-wrap; } Configure the behavior for navigating through windows" dialog. My settings are in a jpeg attached here. Regards, George... "It's not what you know that hurts you, It's what you know that ain't so." Wil Rogers --- On Wed, 1/26/11, Thomas Lübking <thomas.luebking@gmail.com> wrote: From: Thomas Lübking <thomas.luebking@gmail.com> Subject: [Bug 264368] "Focus follows mouse" focus should be explicitly recalculated after desktop switching To: grgoffe@yahoo.com Date: Wednesday, January 26, 2011, 4:17 PM https://bugs.kde.org/show_bug.cgi?id=264368 --- Comment #5 from Thomas Lübking <thomas luebking gmail com> 2011-01-27 01:17:31 --- (In reply to comment #4) > I have set the focus to "focus under mouse". This disables the fancy switching > between widgets. Can you please explain what you mean by this, preferably naming the effect or at least describe it more precisely than "fancy"?
(In reply to comment #6) > My apologies for leaving this out. Nevermind, i've a mouth... "keyboard" to ask :-) > When I set the "stronger" focus parameter, look and feel -> windows behavior -> > navigate through windows reports the following: "Focus policy settings limit > the functionality of navigating through windows." Ahh, ok - no: alt+tab (window switching) does not work or is rather pointless with those focusmodels, because wherever you switch to, the focus would immediately be passed back to the window under the mouse. "Focus follows mouse" is more like the traditional "click to focus" just that it causes an implicit click when entering the window - with the described result that windows which just "appear" below the pointer (like after a desktop switch) do not automatically receive the focus, therefore this is not a bug, but actually consistent behaviour - yet an exception on desktop switching is a valid wish and worth to think about. > Configure the behavior for navigating through windows" dialog. My settings are > in a jpeg attached here. FYI: you're mailing to a bugtracker (bugs.kde.org) and cannot attach items this way but will have to use the webinterface (for the same reason it's not necessary to quote, since the entire "thread" is displayed in the tracker.
In answer to comment #2, switching desktop is in practice just one way of making the mouse enter a window. It may not generate a Qt enter event, but that's just a technical detail - it does REALLY enter the window (via another desktop). From the perspective of a user, it's now in the window and it doesn't matter how it got there. When you have "focus follows mouse" selected, it becomes second nature to just expect the focus to be where the mouse is, and even after a long time stumbling over this bug, I still get caught out by it sometimes and start typing in the wrong window after a desktop switch.
(In reply to comment #8) > From the perspective of a user, it's now in the window and it doesn't matter > how it got there. Right, and this is perfectly honored by the "window under mouse/strictly under mouse" ploicies, but NOT by "follows mouse" which expects the user to /actively/ get the pointer into the window. Those options may use bad terms - I'm no native English speaker (and to my excuse: didn't invent those strings either) but if we'd ignore "how the pointer got there" the strategy would be 100% equal to "focus under mouse" - so the request that "'follows mouse' should behave like 'under mouse'" falls through to "remove 'follows mouse' feature", and you'll need some good arguments for this :p > When you have "focus follows mouse" selected, it becomes > second nature to just expect the focus to be where the mouse is -> just pick "focus under mouse" (it will not remove the focus when the pointer enters a window that cannot take focus, like docks and some desktops)
*** Bug 276156 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > (In reply to comment #8) > > From the perspective of a user, it's now in the window and it doesn't matter > > how it got there. > Right, and this is perfectly honored by the "window under mouse/strictly under > mouse" ploicies, but NOT by "follows mouse" which expects the user to > /actively/ get the pointer into the window. I also think that this is the key question here: What should happen with either "focus follows mouse" policy or "focus under mouse" policy if the user actively navigates the mouse pointer from one window into another window? In both cases, I would expect the old window to lose focus (the mouse pointer has left the old window) and the new window to get the focus (as the pointer has entered that new window). If this happened by moving the pointer from one window to another window on the same desktop, or by switching from one desktop to another desktop, should not make a difference (at least not from a user's perspective). Therefore, I strongly agree with David Jarvie here. > [...] the request that "'follows mouse' should behave like 'under mouse'" > falls through to "remove 'follows mouse' feature", and you'll need some good > arguments for this :p No, "follows mouse" should NOT behave like "under mouse", and maybe I can indeed provide a good argument to this: If you use "focus under mouse", there are quite some disadvantages in comparison to the "focus follows mouse" policy, for example if a dialog window pops up: With "follows mouse", the main window gets darkened (so you better notice the dialog popup) and the dialog window gets the focus, so you can answer it by keyboard without using the mouse, and then continue to type into the main window. Using "under mouse", the dialog window pops up, but does not get the focus, so the main window does not get darkened, giving the illusion that you still can type into it (which you can't). You cannot answer the dialog by keyboard either, as the blocked main window still has the focus, so you now have to move the pointer to the dialog window, THEN the main window gets darkened, and you can then answer the dialog either by keyboard or mouse (as you already used it anyway to put focus on that dialog window). This really does not "feel right", and one would strongly prefer "focus follows mouse" policy in such situations. However, using "focus follows mouse" really is inconvenient (or close to unusable) if you have some virtual desktops each with a number of Konsole windows, switching desktops quite often, because after switching desktops you constantly end up with the mouse pointer inside a Konsole window which does not have the focus, and start typing commands which end up in a different window than that which is under the mouse, forcing you to move the mouse around (or, heaven forbid, to actually click it) to give focus to that exact window the pointer is already in, which is really annoying (and does not "feel right" either). Again: Technically I understand that there might be no XFocusChangeEvent produced by the X server when switching virtual desktops, but surely the user made an explicit action to remove input focus from the previous window on the previous desktop, and expects the focus to be in a window on the desktop he/she just switched to. Naturally, when using "focus follows mouse", the expectation would be that this is exactly the window with the mouse pointer in it, but not the window that had focus when he left that same desktop the last time. In that way, from a user perspective, I would argue that switching desktops is similar to "moving the mouse to a different window". For the reasons above (like dialog windows), I really tried to use "focus follows mouse" recently, but I repeatedly ended up with tying commands into the wrong Konsole window, with sometimes unpleasant results. ;-) I think I know the problems resulting of changing existing user interface behaviour, but in this case I would be surprised if anybody would prefer the current behaviour over the one we had if the described change would be implemented. If all else fails, there could be an additional checkbox like "[x] set focus after switching desktops" for the "focus follows mouse" policy. I could even live with an environment variable to set for this, if anybody thinks that such a checkbox would add too much clutter to the system settings interface (but hey, this is KDE, the last fully configurable desktop system on the planet ;-) ). The bugfix/feature described here would indeed be the best of both focus policies mentioned.
Holger argues the case very well. I have for a while given up on focus follows mouse for exactly the reasons Holger has - switching desktops frequently results in typing into the wrong konsole window afterwards. But focus under mouse is almost as inconvenient, having to move the mouse into popup windows to use the keyboard in them. If focus follows mouse is not going to be made to work logically from the user's perspective, rather than only using X events to determine movements into windows, then his suggestion of an additional checkbox would be the way to resolve this unsatisfactory state of affairs.
> then his > suggestion of an additional checkbox would be the way to resolve this > unsatisfactory state of affairs. As I think none of the core kwin developers is using ffm, I must say that patches are more than welcome. Given that we are already in string freeze we have another 6 months to add that checkbox
There's kwriteconfig --file kwinrc --group Windows --key NextFocusPrefersMouse true since 4.8 (was too late for a GUI, needs still to be done for 4.9) therefore i consider this to be fixed. The setting so far affects behavior on - desktop change - window closing (-> where to pass focus next) - window lowering (by mouse or alt+f3 menu, 4.8.1) - closing a popup, releasing a dnd icon (4.9)
Thomas, Thank you sir! Regards, George...