<span class="gmail_quote">On 8/2/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 Thursday 02 August 2007, Bart Cerneels wrote:<br>> 1. Backup of settings and the kiosk-tool. These deal with the rc file.<br>> An rc file should contain settings of only one application. The kiosk<br>> system is complex enough as it is.
<br><br>kiosk isn't particularly relevant here (it's pretty straightforward still),<br>but the backup of settings might be slightly annoying (though that's<br>certianly a very small percentage of use cases; how many people will
<br>backup -just- their amarokrc but not the rest of their configs?) ...<br><br>this means coming up with a nice solution for use cases such as krunner which<br>must use plasmarc and preferable (e.g. as a requirement) it should not need
<br>to know about plasmarc.<br><br>> 2. What if many other applications start embedding plasma? plasmarc<br>> will contain settings of all of them. What's the use of separate<br>> rc-files then? Imagine the clutter and user confusion.
<br><br>same can be said for any such file, including kdeglobals. plasmarc is used by<br>libplasma, which should be self explanatory from a design perspective.</blockquote><div><br>i think editing plasmarc should be fine, so i'm gonna side with maxx_k on this one. if we provide easy configuration from the Amarok GUI the user never needs to know
<br>that the settings exist there, everything will work *by default* and *transparently* </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">
> And for drag'and'dropping applets to the plasma corona (desktop) I<br>> suggest a system that uses plamoid packages that are included in<br>> Amaroks binaries. So d'n'd would be logicly the same as installing a
<br>> plasmoid with GHNS.<br><br>essentially, yes. plasma is already for this, amarok just needs to ship said<br>plasmoids.</blockquote><div><br>yes, i have been meaning to look into the packaging/plasmoid stuff, but honestly just haven't gotten there yet. also, looking at what i want to do next
<br>i'm not going to get there for a while yet.... so anyone that wants to pick this stuff up is more than welcome, i can't be everywhere :) </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">
> I guess the dataengines would have to be available<br>> outside of Amarok, maybe even by default.<br><br>well, yes, they have to be in order to be found. they are plugins that are<br>loaded via kservicetypetrader.
<br><br>> Is there a DBUS API for adding dataengines?<br><br>engines are loaded on demand by applets that use them. there is no need for a<br>dbus api.</blockquote><div><br>regarding the dataengine-outside-amarok thing, i'm not sure how we want to deal with this. dataengines are always available---if the desktop plasma loads an applet that requests an amarok dataengine, it *will* be loaded. question is, do we want to elegantly not do anything
<br>if amarok is not running? also, what about if amarok *is* running and plasma loads an amarok applet? ideally, it would work just as it would inside amarok. </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>KDE core developer sponsored by Trolltech<br><br>_______________________________________________
<br>Panel-devel mailing list<br><a href="mailto:Panel-devel@kde.org">Panel-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/panel-devel">https://mail.kde.org/mailman/listinfo/panel-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