[Panel-devel] applet and data engine "management"

[Aaron J. Seigo]

On Thursday 24 May 2007, Matt Williams wrote:
> On Friday 25 May 2007 00:07:35 Aaron J. Seigo wrote:
> > hey all...
> >
> > so you may have noticed that there is a DataEngineManager class in
> > libplasma, but no AppletManager. instead, the applet loading is built
> > right into the Applet class through a set of (static) factory methods.
> >
> > here's my rational on this:
> >
> >  - DataEngineManager keeps track of how many users, via ref/deref (thank
> > you QAtomic!), of each engine it has loaded there are. this extra bit of
> > logic manages the lifespan of the engine. i'm half wondering if at some
> > point there will be a need/desire to have multiple managers handling
> > separate sets of data engines. i'm really not sure at this point, so i've
> > left it as a separate class
> >
> >  - Applets, on the other hand, are managed by the container that displays
> > them. there is no additional management that goes on, so all we need are
> > a couple of static factories. additionally, some of the data must be
> > global to work properly; specifically, the appletID which should be
> > globally unique.
>
> That 'container' being the QGraphicsScene and therefore the Desktop class?
> So the Desktop is in a way the AppletManager?

right, for geometry and grouping. and of course panels will also be made of a 
Desktop widget. which is .. counterintuitive =) i need a new name for that 
class.

> Each applet will only be managed by one container at a time so I guess
> reference counting is un-necessary.

correct.

> Moving from panel to panel to desktop.. would this mean that they are
> changing the container which is in charge of their management and
> destruction?

yes. the applet will be managed by whatever QGV it is currently a part of; i'd 
like to keep the applet as unaware of this situation as possible.

> > i'd like to keep geometry and grouping information separate here so that
> > there is no chance of clobbering things. i'm tempted to make these return
> > KConfigGroup objects instead, but i'm not sure that would be flexible
> > enough. it would encourage the right behaviour in 95%+ of the plasmoid
> > cases, but some applets may wish to store information in other groups.
> > granted, you can get the KConfig* from the KConfigGroup ... so perhaps
> > it's not that big of a deal. anyone have any thoughts/preferences on
> > that?
>
> I guess this geometry information will be handled and stored by
> whatever 'Layouts' manager (and its config file(s)) we have since that's a
> purely visual distinction.

correct.

> As you say, if the applet doesn't need to worry about it's position or what
> Layout it's in or if it's in a panel or a desktop, then I think that a
> KConfigGroup is sufficient. It will offer each applet a place to store
> key/value pairs and that's all most of them will need. If they really need
> more they can, as you say, get the KConfig*. It will simplify the API for
> the vast majority of users and a simpler API is Good Thing imho.

yeah, i think you're right. i'll make the API change now (before we start 
getting too many applets)

> > hopefully this is all flexible enough for our needs going forward.
> >
> > btw, is anyone on this list wiling to play the part of "official court of
> > plasma scribe" and collect these bits of information into Real
> > English(tm) as pages on the wiki?
>
> I'd be willing to make a start on this. Though, the beauty of the wiki is
> that anyone can help :)

i'll certainly keep an eye on it and touch things up here and there, but i 
really appreciate someone taking this on. and hopefully others will help out 
as well..

> Incidentally, Do I get a badge for this? :P

i'll start making it now. =)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20070524/0f60ead1/attachment-0001.pgp