Moving KPart args from QStringList to QVariantList

[Aaron J. Seigo]

On March 4, 2007, David Faure wrote:
> 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

the concept is simply to keep as much of the mechanics away from the applets 
themselves so there is less for the applets to screw up. yes, that includes 
getting their name right. this is all about setting the bar low, low, low. 
there's little point in offering javascript capabitilies if there are still 
N^2 rules to follow.

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

perfect =)

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

yeah, the idea is to avoid having this information duplicated in the applet. 

> Hmm, so you do create one .desktop file per applet instance? (clock1 and
> clock2)?

no, no =) one .desktop file per type of applet. information in that file is 
used to put together the bits of information needed, e.g. what is the applet 
specific versus the applet global config file (as an example; likely not the 
only such case).

> Well if the instance name is given via the factory, then it's easy 
> to lookup the kservice::ptr with e.g. findByDesktopPath.

hm. maybe we'll just go with handing in the serviceID and do the lookup in 
Applet's ctor ... i seem to recall that being either faster or more accurate 
or something? anyways... we'll live with two calls to KServiceTypeTrader; 
we're ding all that god awful expensive svg stuff anyways.

> But the overall idea seems strange to me; 

good thing that isn't what we're doing then ;)

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

it already is; i'm just pointing out that the applet is already handed 
everyone to it that the Apple superclass needs to be able to piece together 
what is what. having that "find the right kservice" code in one place is 
pretty nice.

-- 
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/20070304/e1f3cde2/attachment.sig>