<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/123671/">https://git.reviewboard.kde.org/r/123671/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On Mai 7th, 2015, 11:23 vorm. UTC, <b>Marco Martin</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;">I think i would like more either all panels always shown or always hidden.
however I'm fine, given the discussion on this if this mechanism is used instead.
just a question: wouldn't make more sense to use this in a private component of the show desktop applet instead of giving api for everything? I feel the use case so far is quite limited to a potential single applet.
If then more applets come out that would need this, it could be moved in bindings (of which i would prefer in appletinterface rather than appletquickitem)</p></pre>
</blockquote>
<p>On Mai 7th, 2015, 12:31 nachm. UTC, <b>Sebastian Kügler</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;">I've talked with Heiko and Thomas about hiding the panel, and they were pretty clear that hiding the panel is an oversight (especially when triggered from a widget in the panel).</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I'm strongly for not introducing a whole bunch of API for the distinction "comes from panel or not", but keep the panel visible regardless. This keeps behaviour more consistent and seems to be the common/traditional expectation how a panel should behave in the "show desktop" feature.</p></pre>
</blockquote>
<p>On Mai 7th, 2015, 12:35 nachm. UTC, <b>Kai Uwe Broulik</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;">+1 for just keeping the panels visible and be done with it :)</p></pre>
</blockquote>
<p>On Mai 7th, 2015, 4:58 nachm. UTC, <b>Heiko Tietze</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;">Plasmoids and fix panels are sticky things that must not get minimized or greyed out. The latter is the fact for conkys, for instance, when window/task switcher (alt+tab) is shown. So +1 for the issue (I cannot validate the solution).</p></pre>
</blockquote>
<p>On Mai 7th, 2015, 5:16 nachm. UTC, <b>Thomas Lübking</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;">It's not like the usability team was not explicitly attached to the review request that introduced this and explicitly (exclusively) asked what to do with panels
:-P</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Ok, when we show all panels unconditionally there're some concerns (ultimately probably only one) also raised by Thomas P. in the original request:
clicking entries in the taskbar will not make the corresponding window visible unless (as of present condition) it's set to be kept above or the window is <em style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">actually</em> minmized (where the latter will break the showing desktop state) - this might be unexpected inconsistency?</p>
<h2 style="font-size: 100%;text-rendering: inherit;padding: 0;white-space: normal;margin: 0;line-height: inherit;">Possible solutions:</h2>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">a) the taskbar is adjusted to break the showing desktop state whenever any entry is clicked
b) keep above windows are <em style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">not</em> kept visible while showing the desktop
c) well, that's just the way is is, buddy
d) the taskbar disables itself while showing the desktop</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">(a) would get us very close to the former behavior and ppl. coming up with "KWin unminimizes all windows instead of one after i minimized all" bugs
(b) would eg. hide yakuake (though it and krunner can still set themself transient for the desktop what will keep them above the desktop all the time
(c) ;-)
(d) would maybe make most sense? keep above windows can in general still be activated/raised (like yakuake through its global shortcut) but without a "special" access, they're are "lost" once you click the dektop (until the state is broken, of course)</p></pre>
</blockquote>
<p>On Mai 7th, 2015, 8:54 nachm. UTC, <b>Thomas Pfeiffer</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;">"Oversight" might not be the right word, rather "idea not thought completely through". I must admit that I had missed the issue that people who switched to this mode via the Plasmoid in a panel couldn't get back in the same way if the panel was hidden. And by the time I replied to Sebas' email I'd already forgotten the issue with clicking a window in the task manager. So much to think about...</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Both issues (not being able to exit the made the same way it was started and having windows not visibly appear when clicking a taskbar entry) are quite serious. Having two different modes depending on how it was started would probably add more to the confusion than it would help, though (also the problem with the hidden windows would then still persist if the mode was triggered from the panel).</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Would it be possible to break the show desktop mode as soon as one clicks a taskbar entry?</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;">The state can be broken "anytime" by either KWin or any client (incl. the taskbar), ie. either the taskbar breaks it or kwin breaks it whenever there's a forceful call to activate a window (as usually performed by taskbars and pagers)</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Itr, please bear in mind https://bugs.kde.org/show_bug.cgi?id=67406</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">The fundamental question here is:
Should one be implicitly kicked out of this mode by an opening window?</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">If the answer is "no", would it be seen as inconsistent (a problem) that activating a window through the taskbar does, but starting one via krunner or even kickoff does <em style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">not</em> break the state (KWin does not really know whether a window opens because you just started a process or "something" (daemon) just started a process or a running process feels it's time to annoy you with a dialog; kickoff/krunner could explicitly break it on running a command, though)</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Status quo is (still) that whenever a "normal" window is re/shown, the state is broken.</p></pre>
<br />
<p>- Thomas</p>
<br />
<p>On Mai 7th, 2015, 11:14 vorm. UTC, Thomas Lübking 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 Marco Martin.</div>
<div>By Thomas Lübking.</div>
<p style="color: grey;"><i>Updated Mai 7, 2015, 11:14 vorm.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="http://bugs.kde.org/show_bug.cgi?id=346837">346837</a>,
<a href="http://bugs.kde.org/show_bug.cgi?id=346933">346933</a>,
<a href="http://bugs.kde.org/show_bug.cgi?id=347212">347212</a>
</div>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
plasma-framework
</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;">plasmoids only need to add
Plasmoid.visibleWhileDesktopShown: true;
to ensure their panel (and thus them) remains visible while showing the desktop</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">This is achieved by setting the panel transient for the (first found, under them and visible) desktop type window.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">This is mostly relevant for the showdesktop plasmoid (for now)</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Notice that all bugs are only CC, we need this to be used in the showdesktop plasmoid.</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;">added/removed (multiple) showdesktop plasmoids - panel transient for correct desktop window (and visible) unless the last is gone (they seem to be deleted with a short random delay?)</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>src/plasmaquick/appletquickitem.h <span style="color: grey">(dffbcf3)</span></li>
<li>src/plasmaquick/appletquickitem.cpp <span style="color: grey">(0748a8d)</span></li>
<li>src/plasmaquick/private/appletquickitem_p.h <span style="color: grey">(a1ec683)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/123671/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>