<br><br><div><span class="gmail_quote">On 8/2/07, <b class="gmail_sendername">Ian Monroe</b> <<a href="mailto:ian@monroe.nu">ian@monroe.nu</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 8/2/07, Maximilian Kossick <<a href="mailto:mkossick@gmx.de">mkossick@gmx.de</a>> wrote:<br>> Loading the Amarok applets in plasma means IPC, so there is a need for some<br>> kind of dbus api. The question is just how to design the dbus api.
<br>> The obvious solution is that we, the Amarok developers, write a dataengine<br>> which communicates with Amarok using dbus all the time, using a custom dbus<br>> interface. (There's some optimisation potential here when the engine is
<br>> actually loaded by amarok, but i don't think that will be necessary).<br><br>Everything that happens on a track change is speed-critical since<br>something that bogs things down too much can cause noticable pauses
<br>(especially in single-procs)... also when a song begins is when your<br>mostly likely to want to look at this stuff.<br><br>Anyways straight-up dbus might still be fast enough.<br><br>As far as what lfranchi is working on, probably wouldn't be hard to
<br>switch to a dbus-based system from the current libamarok-system in the<br>future, so I would say he already has plenty to worry about currently.<br>:)</blockquote><div><br><br>amen to that. :) </div>i welcome anyone who wants to implement their ideas, but i currently just don't have enough hours in a day to do everything that could be done.
<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">
> Another option would be a generic proxy data engine in plasma/libplasma which<br>> uses a generic dbus interface that has to be implemented by the application.<br>> I don't know if there are other apps which want to integrate
<br>> plasma the way we do, or want to be able to ship with plasma applets for the<br>> desktop, but each of them will have the same problem: without a reusable<br>> proxy data engine, they'll have to write code for both sides of the
<br>> communication. A generic proxy data engine would reduce the necessary work for<br>> the application developers.<br>><br>> Cheers, Max<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></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