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