Plasma and Amarok

[Leo Franchi]

On 7/11/07, Maximilian Kossick <mkossick at gmx.de> wrote:
>
> SNIP
>
> > > Um, no. I just checked plasma in kdebase, and both applets and data
> > > engines
> > > are just plugins. And it's no problem to link plugins to libamarok.
> > > That's what i'm doing for the  collection plguins for example.
> >
> > you're most probably right. i'll take a look at your collection plugins
> to
> > see how you're doing it.
> > maybe i just don't get something fundamental about how these plugins
> > work, but if we query
> >  KTrader for plugins that fulfill a certain constraint, and then tell
> > KTrader to load one, how can that
> > plugin have access to internals of the currently running amarok
> instance?
> >
> plugins are just dynamically loaded code. plugins can use any class/method
> that is exported by libamarok using the AMAROK_EXPORT macro


yep, i realized my error as soon as i actually tried it :) the lastfmevents
engine does exactly that.

> > see above, we can link data engine plugins to libamarok. And I don't see
> > > any
> > > other reasons for forking plasma atm. Of course, I didn't actually
> work
> > > on it
> > > as much as you did, so I'm probably missing something.
> >
> > i probably need to investigate this further. it seems to me at least
> that
> > we would  need to extend
> > plasma's functionality to fit us. on track changes, for example, we need
> to
> > notify plugins. we want to have saved
> > "states" of plugins, e.g. when a track ends our context area should
> return
> > to how the home screen looked last.
> > that way a user can add a plugin to the home screen and then it would be
> > shown every time the home screen is
> > shown---and if he moves it around, that is where it will appear on the
> next
> > showing of the home screen. right now
> > that doesn't exist in plasma (because there is no use case for it). at
> > least, i don't see anything like that.
> >
> Because data engines can have basically full access to all important
> components of libamarok, it's no problem to make them EngineObservers or
> TrackObservers and notify the applets if the underlying data changes(
> assuming data engines can notify applets, otherwise the applets would have
> to
> poll)


true :)


I'm not sure how to save and restore the contents and layout of the context
> view. I suppose there's some support for it in plasma because it's
> probably
> able to restore the layout of the desktop after a reboot. We probably need
> to
> talk to the plasma guys about this if we can't figure out a way to do it
> ourselves. still, i think forking plasma should be the *very* last resort.
> And i'm pretty sure we'll be able to get some support for this from the
> plasma guys if we ask nicely :)


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.

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.

SNIP
>
>
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>
>
>


-- 
______________________________________________________
Leo Franchi                    angel666 at myrealbox.com
4305 Charlemagne Ct         lfranchi at gmail.com
Austin                                 cell: (650) 704 3680
TX, USA                              home: (650) 329 0125
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/amarok-devel/attachments/20070711/fdd74207/attachment.html