[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Review Request 123671: add visibleWhileDesktopShown property
From: Thomas_Lübking <thomas.luebking () gmail ! com>
Date: 2015-05-07 22:19:48
Message-ID: 20150507221948.16998.59932 () mimi ! kde ! org
[Download RAW message or body]
--===============0096164839870546712==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
> On Mai 7, 2015, 11:23 vorm., Marco Martin wrote:
> > 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)
>
> Sebastian Kügler wrote:
> 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).
> 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.
> Kai Uwe Broulik wrote:
> +1 for just keeping the panels visible and be done with it :)
>
> Heiko Tietze wrote:
> 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).
> Thomas Lübking wrote:
> 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
>
>
> 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 *actually* minmized \
> (where the latter will break the showing desktop state) - this might be unexpected \
> inconsistency?
> Possible solutions:
> --------------------
> a) the taskbar is adjusted to break the showing desktop state whenever any entry is \
> clicked b) keep above windows are *not* 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
>
> (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)
> Thomas Pfeiffer wrote:
> "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...
> 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).
> Would it be possible to break the show desktop mode as soon as one clicks a taskbar \
> entry?
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)
Itr, please bear in mind https://bugs.kde.org/show_bug.cgi?id=67406
The fundamental question here is:
Should one be implicitly kicked out of this mode by an opening window?
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 \
*not* 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)
Status quo is (still) that whenever a "normal" window is re/shown, the state is \
broken.
- Thomas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123671/#review80028
-----------------------------------------------------------
On Mai 7, 2015, 11:14 vorm., Thomas Lübking wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123671/
> -----------------------------------------------------------
>
> (Updated Mai 7, 2015, 11:14 vorm.)
>
>
> Review request for Plasma and Marco Martin.
>
>
> Bugs: 346837, 346933 and 347212
> http://bugs.kde.org/show_bug.cgi?id=346837
> http://bugs.kde.org/show_bug.cgi?id=346933
> http://bugs.kde.org/show_bug.cgi?id=347212
>
>
> Repository: plasma-framework
>
>
> Description
> -------
>
> plasmoids only need to add
> Plasmoid.visibleWhileDesktopShown: true;
> to ensure their panel (and thus them) remains visible while showing the desktop
>
> This is achieved by setting the panel transient for the (first found, under them \
> and visible) desktop type window.
> This is mostly relevant for the showdesktop plasmoid (for now)
>
> Notice that all bugs are only CC, we need this to be used in the showdesktop \
> plasmoid.
>
> Diffs
> -----
>
> src/plasmaquick/appletquickitem.h dffbcf3
> src/plasmaquick/appletquickitem.cpp 0748a8d
> src/plasmaquick/private/appletquickitem_p.h a1ec683
>
> Diff: https://git.reviewboard.kde.org/r/123671/diff/
>
>
> Testing
> -------
>
> 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?)
>
> Thanks,
>
> Thomas Lübking
>
>
--===============0096164839870546712==
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
<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>
--===============0096164839870546712==--
[Attachment #3 (text/plain)]
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic