<span class="gmail_quote">On 7/17/07, <b class="gmail_sendername">Aaron J. Seigo</b> <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>> wrote:</span><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
<br><br>+// prefix of applets and data engines, defaults to Plasma => Plasma/Applet<br>and Plasma/DataEngine<br>+static QString pref<br>that should be in plasma.cpp not plasma.h. in fact, i think we may be able to<br>do away with this altogether ......
</blockquote><div><br>sure, that also works :) </div><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
as for this comment in theme.cpp:<br>+ // TODO find a good modular way of doing this<br><br>see the plasmaperaAppThemes.diff patch =)<br><br>> the reason is this: in order to add more constraints we<br>> would need to add more getters
<br>> and setters to each individual class that needs them,<br><br>either that or add more parameters to the methods in question... and then it's<br>only in certain places. looking at it some more, it occurs to me that it's
<br>pretty meaningless to add this to ::loadApplet since we're already using the<br>library name which needs to be unique anyways. so as long as you prefix your<br>applets decently to ensure unique names, e.g. add amarok somewhere in there,
<br>you're all fine without any changes to KServiceTypeTrader calls in<br>loadApplet.<br><br>and i don't think we need to touch DataEngine here as those are created on<br>demand in response to applets. prefacing their name with "amarok" should be
<br>enough of a namespacing there. this is pretty much how things are handled for<br>anything stored in ksycoca anyways, so we should be good.<br><br>this leaves us with modifying knownApplets() and knownCategories() since those
<br>are things that are shown to the user. which is easy to do. see attached<br>patch.<br><br>this pretty much solves the entire issue, but in a much simpler way.</blockquote><div><br>ok, that makes sense. so there would just be one namespace for applets, which is way cleaner...
</div><br><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
this leaves us with the context menu issue open, and your patch to set the<br>mimetype is still valid. this would mean that setting up libplasma for use in<br>amarok would be something like:<br><br>Corona* corona = new Corona(this);
<br>corona->setAppletMimeType("x-amarokapplet");<br>Theme::self()->setApplicationName("amarok");<br><br>and then whenever you wanted to get a listing of applets or categories, it<br>would look sth like this:
<br><br>QStringList applets = Plasma::Applet::knownApplets("amarok");<br><br>and as long as the amarok specific applets have a X-KDE-ParentApp=amarok entry<br>in their .desktop files, all is good. this should also prevent them from
<br>showing up in plasma. this also allows one to grab several sets of applets<br>should they so choose.<br><br>how's that?</blockquote><div><br>sounds great! </div><br><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
hm.. looking at it even more here, i think i'm going to add a category<br>parameter to the knownApplets method so we can load applets from a given<br>category (we need this for the desktop toolbox anyways). this would allow
<br>amarok to have applets that would be useful to both plasma and amarok in<br>an "Amarok" category and to list those easily.<br><br>all together this provides for the following three scenarios:<br><br>- amarok can access plasma applets
<br>- amarok can access applets specific to amarok<br>- plasma can access applets from amarok that are also useful on the desktop<br><br>i'm pretty happy with this now. and if you agree, please commit the mimetype<br>
part of your patch and i'll commit the two attached patches and we should be<br>rockin'</blockquote><div><br>this does seem to cover all the bases :) i'll commit the mimetype stuff then... this is looking pretty awesome!
<br> </div>leo<br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
--<br>Aaron J. Seigo<br>humru othro a kohnu se<br>GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43<br><br>KDE core developer sponsored by Trolltech<br><br>_______________________________________________
<br>Amarok-devel mailing list<br><a href="mailto:Amarok-devel@kde.org">Amarok-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/amarok-devel">https://mail.kde.org/mailman/listinfo/amarok-devel</a><br><br>
<br></blockquote><br><br clear="all"><br>-- <br>______________________________________________________<br>Leo Franchi <a href="mailto:angel666@myrealbox.com">angel666@myrealbox.com</a><br>4305 Charlemagne Ct
<a href="mailto:lfranchi@gmail.com">lfranchi@gmail.com</a> <br>Austin cell: (650) 704 3680<br>TX, USA home: (650) 329 0125