| Summary: | Bad usability of applets/panel configuration/widget explorer/activity switcher with "Focus follows mouse" | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Elias Probst <mail> |
| Component: | general | Assignee: | Sebastian Kügler <sebas> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | bharadwaj.raju777, bhush94, cspiegel, frapell, gandalflechner, gisk+kdebugs, kde, kde, kde, linus.kardell, mgraesslin, nate, notmart |
| Priority: | NOR | Keywords: | usability |
| Version: | master | ||
| Target Milestone: | 1.0 | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=336134 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Elias Probst
2014-06-15 22:42:40 UTC
should we watch the focus follows mouse setting and make it close only with x button in that case? (In reply to comment #1) > should we watch the focus follows mouse setting and make it close only with > x button in that case? Sounds good. This would improve the current situation greatly. Being able to dismiss the panels through an explicit out-of-focus click somewhere else would be nice too, but I think that's probably a little harder to implement. Marco's plan sounds good. Confirming. please provide output of qdbus org.kde.KWin /KWin supportInformation I know what you're looking for :) delayFocusInterval: 0 Still with the default of "300ms" this means one has to move the mouse in less than 1/3rd of a second from the right to the left edge - this will still confuse people unaware of the delay option why their panels sometimes simply disappear. > Still with the default of "300ms" this means one has to move the mouse in
> less than 1/3rd of a second from the right to the left edge - this will
> still confuse people unaware of the delay option why their panels sometimes
> simply disappear.
only if they move the mouse out of the window. As soon as they move in again everything is fine.
The big question here is whether we need to add specific code for the case of focus follows mouse given that:
a) the user changed to FFM deliberately (after all click-to-focus is default)
b) there is at the same KCM the option to set a delay
c) Focus (Strictly) Under Mouse cannot be worked around from Plasma at all
*** Bug 340280 has been marked as a duplicate of this bug. *** *** Bug 356039 has been marked as a duplicate of this bug. *** We shouldn't be having options that simly don't work. Either I want to expose what we need from kwin so we can work round it. Or I want the option removed. > Either I want to expose what we need from kwin so we can work round it.
> Or I want the option removed.
Obviously that won't help anything. This makes you work around the issue for KWin if KWin removed the option. But what if other window managers are used? So far Plasma doesn't enforce KWin, so you shouldn't assume that KWin is being used.
So the only relevant question is: how can Plasma detect that focus changed due to focus follows mouse. And that's actually relatively simple after thinking about it: Plasma needs to control the closing of the window. Let Plasma grab the mouse and explicitly close on click out side window. That way all the focus strategies of KWin get ignored.
>So far Plasma doesn't enforce KWin, so you shouldn't assume that KWin is being used.
I don't know about that. All the blur, and panel autohide, and such are kwin specific. You just wrote an email about how we shouldn't be doing window positioning but using kwin specific API.
But mouse grabbing plan sounds like it's worth a shot. Thanks
(In reply to David Edmundson from comment #11) > >So far Plasma doesn't enforce KWin, so you shouldn't assume that KWin is being used. > > I don't know about that. All the blur, and panel autohide, and such are > kwin specific. You just wrote an email about how we shouldn't be doing > window positioning but using kwin specific API. That's different: all those features like blur and panel autohide are optional. You lose some functionality if KWin is not used. Some for the moving of window: it will work with other WMs, just the animation is missing. Now if you consider this bug to be fine with other WMs: then yes it's a solution. What I wanted to point out is that it's not a solution if you actually want to fix the bug, instead of working around it. > > But mouse grabbing plan sounds like it's worth a shot. Thanks Of course won't work on Wayland ;-) There we'll need a different solution which can be KWin specific (we have a new Focus preservation protection which could be used for it). Any news on this? I use the activities system frequently and I've enabled "focus follows mouse" and this bug bothers me to no end. *** Bug 363897 has been marked as a duplicate of this bug. *** *** Bug 431585 has been marked as a duplicate of this bug. *** *** Bug 422477 has been marked as a duplicate of this bug. *** *** Bug 387231 has been marked as a duplicate of this bug. *** I feel like under Wayland, instead of the panels closing themselves on focus loss, they could indicate their desired behavior with a window class or hint, like xdg_popup or something similar, leaving it to the compositor to position them correctly and to dismiss them when when the user clicks elsewhere. The compositor would be aware of "Focus follows mouse", and could tell the difference between clicking and merely hovering over another window. Plasma would not need to care about focus at all. Of course, that may require some extension for it, if xdg_popup isn't enough. Though I notice on Wayland, application context menus have this same issue, they close when hovering a different window, which they don't do on X11. How do context menus handle this on X11, and why can't Plasma panels do the same? |