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

Matt Williams matt at milliams.com
Fri May 25 01:40:42 CEST 2007


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?

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

> the reason for the appletID needing to be globally unique is that i'm
> banishing the idea of a "unique" applet as there was in kicker. it's a Bad
> Idea(tm) imho; most unique applets were later turned into non-unique
> anyways. and generally, it was just a way to cut corners ..... though in
> the long run it didn't save any work at all.
>
> additionally, if applets can be moved from panel to panel to desktop to
> panel, they need to keep their id's with them so we can associate related
> data, such as configuration information. this should be more robust than
> small labarynth of configuration references in kicker.

Unique IDs are definitely a good idea.

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?

> related to this, every applet has two kconfig objects it can access:
> appletConfig and globalAppletConfig. the latter is for information that is
> meant to be shared between all instances of that applet; the former is for
> settings and information specific to that applet. both files live in
> plasma's appdata directory rather than the usual share/config/. kicker
> poluted that so badly in kde2/3, and i'd like to avoid duplicating that
> experience.
>
> 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.

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.

> 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 :)

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

-- 
Matt Williams
http://milliams.com


More information about the Panel-devel mailing list