[Panel-devel] Plasma and Amarok

[Leo Franchi]

On 7/17/07, Aaron J. Seigo <aseigo at kde.org> wrote:
>
>
>
> +// prefix of applets and data engines, defaults to Plasma =>
> Plasma/Applet
> and Plasma/DataEngine
> +static QString pref
> that should be in plasma.cpp not plasma.h. in fact, i think we may be able
> to
> do away with this altogether ......


sure, that also works :)

as for this comment in theme.cpp:
> +    // TODO find a good modular way of doing this
>
> see the plasmaperaAppThemes.diff patch =)
>
> > the reason is this: in order to add more constraints we
> > would need to add more getters
> > and setters to each individual class that needs them,
>
> either that or add more parameters to the methods in question... and then
> it's
> only in certain places. looking at it some more, it occurs to me that it's
> pretty meaningless to add this to ::loadApplet since we're already using
> the
> library name which needs to be unique anyways. so as long as you prefix
> your
> applets decently to ensure unique names, e.g. add amarok somewhere in
> there,
> you're all fine without any changes to KServiceTypeTrader calls in
> loadApplet.
>
> and i don't think we need to touch DataEngine here as those are created on
> demand in response to applets. prefacing their name with "amarok" should
> be
> enough of a namespacing there. this is pretty much how things are handled
> for
> anything stored in ksycoca anyways, so we should be good.
>
> this leaves us with modifying knownApplets() and knownCategories() since
> those
> are things that are shown to the user. which is easy to do. see attached
> patch.
>
> this pretty much solves the entire issue, but in a much simpler way.


ok, that makes sense. so there would just be one namespace for applets,
which is way cleaner...


this leaves us with the context menu issue open, and your patch to set the
> mimetype is still valid. this would mean that setting up libplasma for use
> in
> amarok would be something like:
>
> Corona* corona = new Corona(this);
> corona->setAppletMimeType("x-amarokapplet");
> Theme::self()->setApplicationName("amarok");
>
> and then whenever you wanted to get a listing of applets or categories, it
> would look sth like this:
>
> QStringList applets = Plasma::Applet::knownApplets("amarok");
>
> and as long as the amarok specific applets have a X-KDE-ParentApp=amarok
> entry
> in their .desktop files, all is good. this should also prevent them from
> showing up in plasma. this also allows one to grab several sets of applets
> should they so choose.
>
> how's that?


sounds great!


hm.. looking at it even more here, i think i'm going to add a category
> parameter to the knownApplets method so we can load applets from a given
> category (we need this for the desktop toolbox anyways). this would allow
> amarok to have applets that would be useful to both plasma and amarok in
> an "Amarok" category and to list those easily.
>
> all together this provides for the following three scenarios:
>
> - amarok can access plasma applets
> - amarok can access applets specific to amarok
> - plasma can access applets from amarok that are also useful on the
> desktop
>
> i'm pretty happy with this now. and if you agree, please commit the
> mimetype
> part of your patch and i'll commit the two attached patches and we should
> be
> rockin'


this does seem to cover all the bases :) i'll commit the mimetype stuff
then... this is looking pretty awesome!

leo

> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Trolltech
>
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>
>
>


-- 
______________________________________________________
Leo Franchi                    angel666 at myrealbox.com
4305 Charlemagne Ct         lfranchi at gmail.com
Austin                                 cell: (650) 704 3680
TX, USA                              home: (650) 329 0125
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/amarok-devel/attachments/20070717/42f8a59f/attachment.html