Review Request 124434: [Panel] Delay disappearance of panel configuration bar on focus lost

David Kahles david.kahles96 at gmail.com
Fri Jul 24 22:45:48 UTC 2015



> On July 24, 2015, 1:25 a.m., David Edmundson wrote:
> > the panel doesn't currently hide when the mouse leaves, only when another window gets focus.
> > 
> > Do you have focus follows mouse set?
> 
> David Kahles wrote:
>     Yes I have, without focus follows mouse it works as expected, I didn't think about that. Is this something we don't fix?
> 
> David Edmundson wrote:
>     ah cool, it explains the different behaviour.
>     
>     >Is this something we don't fix?
>     
>     I don't know, I don't think we want to change the normal experience for this one edge-case. If you explicitly click on another window, there's no reason to make this delay closing.
>     
>     On the other hand, if we are going to provide an option to do a thing we should damn well actually support it.
>     
>     Does kwin expose if the user has focus follows mouse (we have a similar bug with the add widgets dialog and this option) ? 
>     If so can we come up with a good compromise that doesn't complicate code too much?
> 
> David Kahles wrote:
>     > I don't know, I don't think we want to change the normal experience for this one edge-case
>     [snip] if we are going to provide an option to do a thing we should damn well actually support it.
>     
>     I fully agree to both statements. There are multiple bug reports about this/smimilar problems. In bug [1] Martin Gräßlin said
>     > We could alter the behavior of the add widget dialog by allowing Plasma to query KWin's focus policy, but I would not recommend to go that road.
>     
>     Martin: Could you explain why you wouldn't do this?
>     
>     [1] https://bugs.kde.org/show_bug.cgi?id=262835#c8
> 
> Martin Gräßlin wrote:
>     Sure I can explain a little bit about it. We have several focus strategies going from click to focus to focus strictly under mouse. With every step the mouse gets more precendence. The strategies F(S)UM are called "unreasonable" in the KWin source code. The idea is to pass focus always and only to windows under the mouse. It's the users wish to have it behave that way and that includes that windows close when focus changes. Given that I consider it as wrong in Plasma to work around the users wish as it's also against what the users of these strategies expect.
>     
>     That said I think we all agree that F(S)UM is not reasonable and that we should not consider them. So lets look at FFM. Here the situation is similar: KWin has an additional focus delay, but default that's 300 msec. So only if the user moves the cursor to another window and stays there it will switch focus and then close the window. Again I consider this as the users wish and the expected result if the window closes.
>     
>     Now exporting to Plasma would mean introducing a complex protocol to announce the currently used strategy and focus delay time for both X11 and Wayland. It's kind of making Plasma interpret deep KWin internals. It's also extremely KWin specific so with other window managers it wouldn't work.
>     
>     If the default of 300 msec is too short, we should rather look into getting a better default into KWin than trying to work around in Plasma.

Thank you for your explanation.
> It's the users wish to have it behave that way and that includes that windows close when focus changes. Given that I consider it as wrong in Plasma to work around the users wish as it's also against what the users of these strategies expect.

I think the users wish only applies to normal windows, which don't close when they loose focus. But this is a different case, as the plasma windows behave abnormal.
> Now exporting to Plasma would mean introducing a complex protocol to announce the currently used strategy and focus delay time for both X11 and Wayland. It's kind of making Plasma interpret deep KWin internals. It's also extremely KWin specific so with other window managers it wouldn't work.

I understand the technical problems, would be very ugly.
> If the default of 300 msec is too short, we should rather look into getting a better default into KWin than trying to work around in Plasma.

I don't think this would fix it. I have my delay usally set to 0ms because a higher delay interrupts my workflow. But again: this is no normal window, so the normal delays don't work here. It's even worse at the widget explorer dialog (Yes I know, a different issue, but related), because I have to move my mouse over 2 monitors to get there. This would need a delay of about 1sec.

>From a user perspective, as I said above, I think we shouldn't increase the normal delay, because this are abnormal windows. Saying we should respect the users choice isn't right too IHMO because of the same reason.
I think it's wrong that plasma windows behave so much different than normal application windows. Of course this saves click to focus users a mouse click, but brings big drawbacks to users of different focus strategies. I think we should alter the behavior of plasma windows if we support multiple focus strategies, but this is just my personal opionion, as I don't know the design reasons for the focus policy of the plasma windows.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124434/#review82849
-----------------------------------------------------------


On July 24, 2015, 11:51 a.m., David Kahles wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124434/
> -----------------------------------------------------------
> 
> (Updated July 24, 2015, 11:51 a.m.)
> 
> 
> Review request for Plasma and Martin Gräßlin.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> -------
> 
> Wait (per default) 600ms to hide the panelconfigview, because
> sometimes it happens that a user inadvertently leaves
> the panelconfigview with his mouse.
> Then he/she has to reopen the panelconfigview because it hides
> immediately. 600ms should be long enought to move the mouse back into
> the panelconfgview and prevent the hide.
> 
> 
> Diffs
> -----
> 
>   shell/panelconfigview.h 98705d13875c92acdc46355f600ce8541e4596f4 
>   shell/panelconfigview.cpp dee2acc8618bf6341de1427dc18c2a2a00463c15 
> 
> Diff: https://git.reviewboard.kde.org/r/124434/diff/
> 
> 
> Testing
> -------
> 
> Using the panel configuration bar works much better now as it doesn't hide immediately.
> 
> 
> Thanks,
> 
> David Kahles
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20150724/7ece6155/attachment.html>


More information about the Plasma-devel mailing list