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

[Aaron J. Seigo]

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.

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.

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?

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?

-- 
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/51ca2f15/attachment.pgp