Moving KPart args from QStringList to QVariantList

[Aaron J. Seigo]

exec summary:

yes, it is all do-able without the applet requiring a kservice object. it is 
also less elegant, both for plasma internals as well as for people writing 
applets.

On March 3, 2007, David Faure wrote:
> On Friday 02 March 2007, Aaron J. Seigo wrote:
> > this only works if you don't need that information during construction.
> > in this case, it would mean having a rule for applets that they couldn't
> > call their globalAppletConfig or appletConfig methods until after the
> > constructor. and then we'd have to make ++sure that the -first- thing
> > that happens after instantiating the applet is to call setService on it.
> > that is so ugly.
>
> I don't see why an applet needs a KService to get a config object.

it doesn't, but it's a matter of convenience and consistency.

> Everywhere else in KDE, "objects" know their own instance name and simply
> use that to get hold of everything they need.

there area few interesting things we're doing. 

first, applets should not need to know where their configuration is kept. this 
is for a number of reasons, including consistency and the ability to save and 
restore configurations (the latter requiring an internal consistency that 
demands centralized management).

second, many applets need to have both applet-global and instance-specific 
configurations; e.g. a clock may want a consistent face type between all 
instances of that clock, but different timezones. this was an issue in both 
kicker and superkaramba where applets/themes would either not support this 
(leading to user frustration) or they would each reinvent the system over and 
over again. and again, with no consistency.

so the location of the configuration files (which may even move over time, and 
the applet should not need to know about that) as well as the naming 
convention is handled by the applet super-class.

there are other minor wrinkles such as non-c++ applets; the plan at the moment 
is to have the container applet receive the service description and us that 
to load the script and data files (from a compressed archive) and as needed 
run them through the interpreter. so some applet containers will most 
naturally operate if they have access to the service description.

there's also the matter of attribution and license. we'd like to be able to 
show this information without instantiating each plugin to retrieve 
kaboutdata, so we're back to using kservices and custom entries there-in.

now, you are right that we could simply have each applet register a 
(hopefully) unique name that we then use to construct the configuration file 
path(s). but given how much we are already using kservice to enable other 
things, and how some applet containers will want the kservice pointer to work 
with internally anyways, it seemed quite natural to remove the need for every 
applet to register itself with a unique name when it has already done so in 
the sycoca.

in the case of non-C++ applets, using kservice makes it a trivial matter of 
the 'developer' filling out a form in the plasmagik packager app and voila! 
it creates a file with all the information we need without them needing to do 
any particularly specific initialization steps.

> > another way to go is to change how we do things like figure out the
> > config file names and not base it on the service information, though
> > using the kservice seems like a pretty obvious/elegant way to do that.
>
> That's arguable. It's like you looking me up in the phone book, by my name,
> and then calling me to tell me "your name is David". Well, thank you but I
> knew that :) Applets should know their own name, that seems pretty obvious
> to me.

applets have names, yes. they are in their .desktop files. keeping all the 
naming information there seems pretty natural. moreover, applets only know 
part of their name, since each applet is assigned a unique id that becomes 
part of their "address" at run time and that id can not be internally 
generated, but must be done globally outside the applet.

using your analogy it's like a government worker phoning you to let you know 
what your new house # and postal code that they just assigned to you will be. 
yes, you could cooperate and provide part of the information ("my last name 
is faure") every time it is needed, but that's what they have government 
records for.

> > it's ok, we just won't use KGenericFactory and friends and do the loading
> > more manually, just as kicker ended up doing.
>
> That doesn't really sound like a good solution to me. Makes writing applets
> more complicated than it could be.

it's actually simpler for non-C++ applets and not a big deal for C++ ones 
either. you just copy and paste a slightly different factory line.

-- 
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/kde-core-devel/attachments/20070303/b3664d92/attachment.sig>