<span class="gmail_quote">On 7/11/07, <b class="gmail_sendername">Maximilian Kossick</b> <<a href="mailto:mkossick@gmx.de">mkossick@gmx.de</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">
SNIP<br><br>> > Um, no. I just checked plasma in kdebase, and both applets and data<br>> > engines<br>> > are just plugins. And it's no problem to link plugins to libamarok.<br>> > That's what i'm doing for the collection plguins for example.
<br>><br>> you're most probably right. i'll take a look at your collection plugins to<br>> see how you're doing it.<br>> maybe i just don't get something fundamental about how these plugins<br>
> work, but if we query<br>> KTrader for plugins that fulfill a certain constraint, and then tell<br>> KTrader to load one, how can that<br>> plugin have access to internals of the currently running amarok instance?
<br>><br>plugins are just dynamically loaded code. plugins can use any class/method<br>that is exported by libamarok using the AMAROK_EXPORT macro </blockquote><br>yep, i realized my error as soon as i actually tried it :) the lastfmevents engine does exactly that.
<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">
> > see above, we can link data engine plugins to libamarok. And I don't see<br>> > any<br>> > other reasons for forking plasma atm. Of course, I didn't actually work<br>> > on it<br>> > as much as you did, so I'm probably missing something.
<br>><br>> i probably need to investigate this further. it seems to me at least that<br>> we would need to extend<br>> plasma's functionality to fit us. on track changes, for example, we need to<br>> notify plugins. we want to have saved
<br>> "states" of plugins, e.g. when a track ends our context area should return<br>> to how the home screen looked last.<br>> that way a user can add a plugin to the home screen and then it would be<br>
> shown every time the home screen is<br>> shown---and if he moves it around, that is where it will appear on the next<br>> showing of the home screen. right now<br>> that doesn't exist in plasma (because there is no use case for it). at
<br>> least, i don't see anything like that.<br>><br>Because data engines can have basically full access to all important<br>components of libamarok, it's no problem to make them EngineObservers or<br>TrackObservers and notify the applets if the underlying data changes(
<br>assuming data engines can notify applets, otherwise the applets would have to<br>poll)</blockquote><div><br>true :) </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">
I'm not sure how to save and restore the contents and layout of the context<br>view. I suppose there's some support for it in plasma because it's probably<br>able to restore the layout of the desktop after a reboot. We probably need to
<br>talk to the plasma guys about this if we can't figure out a way to do it<br>ourselves. still, i think forking plasma should be the *very* last resort.<br>And i'm pretty sure we'll be able to get some support for this from the
<br>plasma guys if we ask nicely :)</blockquote><div><br>this is a good point. on the other hand. all of the work up to now has taken me exactly 2.5 days (or is it 3.5, i lost track), of maybe 6 hours a day. its not that much work to throw away if we decide to go with the linking strategy. and as now i'm writing engines/applets, this is useful for either decision.
<br><br>what i mean is i don't think i need to halt what i'm doing until we have this figured out, but we can play it by ear as we go along. <br></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">
SNIP<br><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