<br><br><div><span class="gmail_quote">On 7/16/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">
On Monday 16 July 2007, Maximilian Kossick wrote:<br>> > the downside to this approach is that, while simpler to use, it means<br>> > that it's an all-or-nothing approach ... it wouldn't be possible to use
<br>> > DataEngines for plasma in amarok and vice versa as a side effect of<br>> > setting up separate applets.<br>><br>> How about using additional constraints instead of changing the service<br>> type? Amarok could add a constraint [X-Plasma-Domain] == 'Amarok' to
<br>> KTrader queries and only get results that were designed for Amarok. Plasma<br>> would not use the additional constraint and could load Amarok's Applets and<br>> Dataengines.<br><br>heh.. i was just talking with Ian on irc about this and sent a similar email.
<br>it certainly is an approach with merit and potential.<br><br>> Some of Amarok's dataengines are probably going to link to libamarok, so<br>> Plasma shouldn't load them...i'm not sure how to solve this...maybe another
<br>> constraint?<br><br>this shouldn't be a problem, as dataengines are loaded on demand by applets.<br>plasma doesn't load any engine until it is requested. moreover, if the<br>dataengine exists, then its library dependencies also must exist ... the only
<br>issue would be one of overhead, unless libamarok operates under the<br>assumption that only one copy of it is in use at a time (though i would<br>imagine that is not the case)...<br><br>so as long as no applets that load an engine that links against libamarok are
<br>loaded, it's really a non-issue. personally, i'd like to see dataengines<br>proliferate in this manner as it would make it easier to write desktop/panel<br>components for specific applications.</blockquote><div>
<br>this seems like a cleaner solution than changing the ServiceType on demand. it would definitely allow for more flexibility, after all, amarok *is* able to display plasma applets perfectly well. and as you so clearly state, the other way around is a non-issue as unless the user loads amarok-specific applets, nothing would happen (and if he did, well, they would be pretty useless).
<br><br>i'll take a look at this too, doesn't seem too outrageously complicated.<br></div><br>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>Full time KDE developer sponsored by Trolltech (<a href="http://www.trolltech.com">http://www.trolltech.com
</a>)<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></div><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