[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: [Panel-devel] applet and data engine "management"
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2007-05-25 1:20:37
Message-ID: 200705241920.38355.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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)

[Attachment #5 (application/pgp-signature)]

_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel


[prev in list] [next in list] [prev in thread] [next in thread]