Signals and slots for containment show and hide actions (mainly for panels)

[Aaron J. Seigo]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090330/76f678d9/attachment.sig