[Panel-devel] Plasma and Amarok

[Maximilian Kossick]

SNIP

>
> - the other two static setters introduced in Applet are really just
> changing the same string (Plasma, or plasma, as the case may be). we have
> the same issue in DataEngineManager again.
>
> i wonder if it doesn't make sense to just use one setter for all of these.
> we could easily have a single setter/getter pair in plasma.cpp for a static
> QString in the Plasma namespace that sets/gets the prefix. this can then be
> used whereever we do KTrader lookups, etc..
>
> so in plasma we'd use Plasma (making Plasma/Applet, Plasma/DataEngine,
> Plasma_foorc) and in amarok you might use Amarok (making Amarok/Applet and
> amarok_foorc). the two static strings can be kept (in the Private class)
> but having just one method for this would be nice. this would bring the
> number of calls to set up libplasma for use in other apps from 5 down to 2
> (one for the theme prefix and one for the applet prefix). if we use this
> same approach for the drag-and-drop mimetype, we could even get rid of one
> more setter.
>
> the downside to this approach is that, while simpler to use, it means that
> it's an all-or-nothing approach ... it wouldn't be possible to use
> DataEngines for plasma in amarok and vice versa as a side effect of setting
> up separate applets.

How about using additional constraints instead of changing the service type? 
Amarok could add a constraint [X-Plasma-Domain] == 'Amarok' to KTrader 
queries and only get results that were designed for Amarok. Plasma would not 
use the additional constraint and could load Amarok's Applets and 
Dataengines.

Some of Amarok's dataengines are probably going to link to libamarok, so 
Plasma shouldn't load them...i'm not sure how to solve this...maybe another 
constraint?

> hm ... for that matter, i'm really not sure why we need to namespace
> DataEngines at all? they are only requested by applets so the user never
> sees them; we just need to be sure to avoid name collissions which should
> be pretty easy to do. that removes the whole "namespacing applets affects
> dataengines" issue with the above approach.
>
> we'd probably want to add some convenience methods to Plasma:: as well for
> the "final" products (applet service type, drag and drop mimetype, etc)
>

SNIP

Cheers, Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20070716/d0dfd9e8/attachment-0001.pgp