Plasma and Amarok
Leo Franchi
lfranchi at gmail.com
Thu Jul 12 12:50:19 CEST 2007
On 7/11/07, Leo Franchi <lfranchi at gmail.com> wrote:
>
> 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 :)
>
>
so i went ahead and tried to import plasma with an svn extern entry
and link to it as a shared library, but i'm running into issues
re-implementing what i need. for example, at the least, we need to
reimplement the parts where it looks for plasma widgets,
e.g
. when it specifies the KTrader type Plasma/Applet for example. the
problem is that, as some of the functions that do this rely on private
object data, subclassing and reimplementing does not work.
one option would be to talk to the plasma guys and get them to
abstract the code a little more so we could
specify the plugin type etc.
leo
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
>
--
______________________________________________________
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/20070712/63e89282/attachment.html
More information about the Amarok-devel
mailing list