Moving KPart args from QStringList to QVariantList

[David Faure]

On Saturday 03 March 2007, Aaron J. Seigo wrote:
> first, applets should not need to know where their configuration is kept. [...]
OK I see that part now, but I don't see the relation? If the config comes from clock_1 and clock_2
for two instances of the clock, are you really autocreating two service desktop files,
or can't this simply be done by passing a (string!) argument to the applet (via the factory),
to tell it its instance name (hehe here the old kde3 name worked) -- I mean its componentdata name in kde4 terms --.
That would be the instance-specific config; the applet-global config is obviously easy to get to,
the applet knowing its own name.

> 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.
For that part I recommend KPluginInfo - which is indeed about storing this info in
the desktop files (without reinventing the wheel) to avoid instanciating the applets.
In the applet code itself, either this info is duplicated (when creating the aboutdata)
or the applet needs to look up the kservice (which is easy and fast when knowing its filename).

> 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.
Hmm, so you do create one .desktop file per applet instance? (clock1 and clock2)?
Well if the instance name is given via the factory, then it's easy to lookup the kservice::ptr
with e.g. findByDesktopPath. But the overall idea seems strange to me; I add a clock,
it creates a .desktop file, I have to wait for kbuildsycoca to run, and then finally the applet
can appear. It would seem more efficient to only use the original desktop file and simply
pass a "clock2" name to the applet so that it loads/saves its config from clock2rc.

> 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.
OK, no experience on that part...

> 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.
Yes, so it needs to be passed to the applet. But I would pass it as a string and use
that for config, not for kservice/desktop file stuff. After all the meta-information
in the desktop file (author/license/etc.) is going to be the same for both instances
of the applet :)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).