> 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
