On Monday 30 March 2009, Emdek wrote: > Currently when containment (mainly panel) becomes hidden or shown there is > no notification for applets on it. There could be emitted signals, for > example containmentShown and containmentHidden and maybe property with > visibility state. > This is not big problem to emit these signals and in some cases this > information could be useful, examples:
"not a big problem" is the wrong measuring stick. "worthwhile" is the right measuring stick. there's all sorts of things we can do because they are relatively easy. the problem is that we have all sorts of things that are going on. each one inevitably results in more code paths somewhere (in this case, we'd now expect widgets to behave properly when the containment is visible or not) and results in more maintenance burden. that's why it's important to prove "worthwhile". > - applet manages top level widget (for example to make menu button that > partially obscures window - yes, I know, this is hack, but I know also that > one of Plasma developers suggested this) and it should be hidden when panel > is hidden and shown when shown; we manage to do this with the system tray just fine, and it's doing exactly this sort of hack. that said, these sorts of hacks should not be designed for. they are hacks, and not of the good sort. :) > - this could be used also for desktop containments, for example we use some > player plasmoid - it could stop playback (of course this could be optional, > and remember, this is only example of possible usage, this could be used > for different things) but if we can't enumerate the uses clearly, we don't have a clear need for it :) > when we switch to another desktop (containment with > player becomes not visible for us - not hidden by windows but being hidden > panel or currently not visible desktop activity). and yet, as i noted in the bug report comment i made earlier, this is not something one would always want to happen. it would really need additional information, possibly from the user. as such, i'm not comfortable with this as a compelling use case. if it is something we feel we need (and i'm still not 100% sure if it is) then this could probably be added as a Plasma::Constraint. and that would require us to think of what this constraint is all about. in this case you are thinking of being hidden or visible. what about a Containment that the user decides to "freeze"? what about a Containment that has no associated View (even though it may well still be visible)? etc.. if passed in as a constraint (and again, what is that constraint, really?) then widgets who care to can react to being "frozen" or "paused" due to outside intervention. and even then ... it's hard to know when this could really be applied. should RSS feeds stop updating because they aren't visible? do media players always want to be paused, or does this depend on what is being played? do translucent overlays count as a pausing event? etc... i'm not convinced in either direction on this one. it needs more thought and to be worked out in greater detail. > Additionally there could be added slots (or signals emitted by applet, so > only specialized containments could get and handle these request) to show > and hide containment (panel), for example showContainment and > hideContainment. i'm ok with the concept of this, but the API should describe what the widget needs, not what it results in because that's not something we can know from inside the plasmoid. what we really want is for the widget to be visible to the user, if at all possible and reasonable. the fact that the containment might be hidden or not, and what "hidden" means for a given application is besides the point. moreover, what we need is something that works when more than one widget sets this property. consider: widgets A and B, containment Z: * A says "unhide" * Z decides whether to show itself or not, decides it can and should, therefore shows itself. * B then also says "unhide" * A says "hide" * C musn't hide, because B still needs it! * B eventually says "hide" * C can now go back into hiding so we need something reference counted and an easy way to react from either the Containment or the View. i'd recommend a simple property that can be set in Applet (requestingVisualFocus and setRequestingVisualFocus?) which passes it on to Containment internally, and a signal in Containment (visualFocusRequested(bool)?) emitted when the count becomes >0 and again when it reaches 0. then in View::setContainment it could connect the signal from Containment to a similar signal in View, relieving View subclasses from the burden of setting/unsetting this connection? > Hiding slot could be used to achieve manual hiding (click > on plasmoid that invokes this slot, unhiding done like in autohide), forced hiding should probably be avoided, actually; but when needed then probably a call to Applet::releaseVisualFocus should reset the count to zero (and all applets in the containment as well)... still, i think this would make more sense as part of the View itself rather than part of the containment. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
