<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 Juli 24th, 2015, 1:25 vorm. 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 Juli 24th, 2015, 1:38 vorm. 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 Juli 24th, 2015, 11:16 vorm. 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 Juli 24th, 2015, 11:51 vorm. 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>
</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;">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>
<br />
<p>- Martin</p>
<br />
<p>On Juli 24th, 2015, 11:51 vorm. 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 Juli 24, 2015, 11:51 vorm.</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>