Review Request 123671: add visibleWhileDesktopShown property

Sebastian Kügler sebas at kde.org
Fri May 8 04:12:51 UTC 2015 


> On May 7, 2015, 11:23 a.m., 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?
> 
> Thomas Lübking wrote:
>     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.

Short: I think show desktop should be a lot less modal, interaction with application windows is a central part of this feature
Long: I've sent an email to the kwin and plasma list discussing this issue, subject: 'Behaviour of "Show Desktop"'


- Sebastian


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


On May 7, 2015, 11:14 a.m., Thomas Lübking wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123671/
> -----------------------------------------------------------
> 
> (Updated May 7, 2015, 11:14 a.m.)
> 
> 
> 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20150508/e10200f1/attachment-0001.html>

More information about the Plasma-devel mailing list