<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="12" style="border: 1px #c9c399 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/124434/">https://git.reviewboard.kde.org/r/124434/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On July 24th, 2015, 1:25 a.m. CEST, <b>David Edmundson</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">the panel doesn't currently hide when the mouse leaves, only when another window gets focus.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Do you have focus follows mouse set?</p></pre>
</blockquote>
<p>On July 24th, 2015, 1:38 a.m. CEST, <b>David Kahles</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Yes I have, without focus follows mouse it works as expected, I didn't think about that. Is this something we don't fix?</p></pre>
</blockquote>
<p>On July 24th, 2015, 11:16 a.m. CEST, <b>David Edmundson</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">ah cool, it explains the different behaviour.</p>
<blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Is this something we don't fix?</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">On the other hand, if we are going to provide an option to do a thing we should damn well actually support it.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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?</p></pre>
</blockquote>
<p>On July 24th, 2015, 11:51 a.m. CEST, <b>David Kahles</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I fully agree to both statements. There are multiple bug reports about this/smimilar problems. In bug [1] Martin Gräßlin said</p>
<blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Martin: Could you explain why you wouldn't do this?</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">[1] https://bugs.kde.org/show_bug.cgi?id=262835#c8</p></pre>
</blockquote>
<p>On July 24th, 2015, 6:14 p.m. CEST, <b>Martin Gräßlin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p></pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Thank you for your explanation.</p>
<blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
<blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I understand the technical problems, would be very ugly.</p>
<blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p></pre>
<br />
<p>- David</p>
<br />
<p>On July 24th, 2015, 11:51 a.m. CEST, David Kahles wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="12" style="border: 1px #888a85 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tr>
<td>
<div>Review request for Plasma and Martin Gräßlin.</div>
<div>By David Kahles.</div>
<p style="color: grey;"><i>Updated July 24, 2015, 11:51 a.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
plasma-workspace
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p></pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Using the panel configuration bar works much better now as it doesn't hide immediately.</p></pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>shell/panelconfigview.h <span style="color: grey">(98705d13875c92acdc46355f600ce8541e4596f4)</span></li>
<li>shell/panelconfigview.cpp <span style="color: grey">(dee2acc8618bf6341de1427dc18c2a2a00463c15)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/124434/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>