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

[Aaron J. Seigo]

On Monday 30 March 2009, Emdek wrote:
> - in my Run Command plasmoid that uses KHistoryComboBox to make it
> work in panels (I've created report about problems with them and others on
> GraphicsView);

this is working around a problem in QGraphicsScene/View, really; it will get 
fixed (it's being worked on) so there's no reason to hack around it today. 
there may even be other ways to do it nicely with the combo being "manually" 
shown as the popup for the applet, which would also keep the panel from 
hiding.

> - in my task manager applet (MacOS X dock like) for icons
> moving outside panel in zoom animation;

this probably ought to be done with compositing with input masks instead.

> - I'm also thinking about working
> on next alternative menu, with this fancy button that moves outside panel
> (yes, I know, like in Vista, but many users love this... personally I don't
> like things that permanently obscures part of window).

again, compositing and input masks.

> And there is problem when panel hides, is it currently possible to do
> something with these widgets visibility when it occurs, without having kind
> of notification mechanism (I don't how exactly it is done in systray, but
> there it works)?

the tray tracks the location of the QGraphicsWidget and manually positions the 
items. this is fraught with problems, though, such as not being able to be 
visible in more than one view at a time, not working when zoomed out ... same 
kinds of problems any "manage a top level QWidget" approach will face actually 
(c.f. the "embed an application window" plasmoid)

> By the way, I was also thinking about possible use of constraints but
> forget to write. :-D It could be clearer to find what it does when it would
> be well documented (one sentence is often not enough if you first use new
> API).

if you have specific questions, we can certainly answer them (and add it to 
the apidox as well)

> >> 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.
>
> I'm afraid that I'm better in suggesting than projecting API that must be
> good from start and be enough even some years later. ;-) 

it's a learned skill (one i'm still working on, too) ... we can work it out 
together, though. :)

> But your example
> with widgets and containment is very interesting. One thing is clear (at
> least for me ;-)), that using applet's activate signal for unhiding
> autohidden panels should be separated from activation that comes from
> activation of applet's keyboard shortcut, because when you want also to use
> it to perform action

yes, that's a good point. so we could use this same thing in that case as 
well.

so now we just need some sort of name for this :) we have releaseVisualFocus() 
... so .. requestVisualFocus(bool)? releaseVisualFocus would remain a heavy 
handed "hide things!" signal, and requestVisualFocus would allow one to ask 
for visual focus or to notify it isn't needed anymore.

maybe it should be two method? i just can't think of two good names for it :) 
anyone else?

> I've more suggestions about current status of keyboard
> shortcuts for applets, but these should be discussed separately. ;-)

sure thing (and yes, there's more work to be done there, indeed!)

> >> 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.
>
> I see this method as easiest possible way to reintroduce manual hiding of
> panel (lack of this is for me bigger problem that need of using Panel
> Spacer for applets positioning ;-)) by introducing simple plasmoid for
> triggering hiding. And I don't like autohiding, when everything moves to
> often (it would be useful for me for example only for hiding tasks list
> when I want to hide names of running apps when someone watches ;-)).

thing is that hiding is an attribute of the View, not the Containment. 
plasmoids that only work on some views (PanelView) but not others 
(DesktopView, DashboardView, MIDView, etc) are no-nos. so i think this is 
something that should go directly into PanelView itself.

-- 
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/708379b8/attachment.sig