Plasma and Amarok

[Maximilian Kossick]

On Wednesday 11 July 2007, Leo Franchi wrote:
> On 7/10/07, Maximilian Kossick <mkossick at gmx.de> wrote:
> > SNIP
> >
> > > > So I guess the plan is to make Amarok::ContextView another formfactor
> > > > (like desktop, panel, mediacenter). Does that mean we need to expend
> > > > some enum in plasma?
> > > >
> > > > Is there drag and drop support already? Some day I want to be able to
> > > > drag plasmoids out of CV to plasma.
> > > >
> > > > Do we need a data engine inside of Amarok, the same process. It seems
> > > > kind of strange that the CV widgets talk to Amarok through an
> > > > external process.
> > >
> > > well, not exactly. the way you are thinking of the new contextview is
> > > like simply
> > > another facet of plasma, e.g
> > > . plasma "extended" into amarok. thats not actually how it (currently)
> > > works.
> > >
> > > right now i've copied/modified the relevant source files from the
> > > plasma source tree into amarok. so we have our "own"
> > > plasma. we will have our own plugins, with our own servicetype. now,
> > > it would be cool
> > > if we could just drag and drop from plasma<->amarok, but that i think
> > > is something to think about in the future.  we can't have amarok be
> > > another
> > >
> > > another formfactor of plasma for a few reasons:
> >
> > I know that there are formfactors for putting plasmoids into horizontal
> > or vertical task bars. Amarok's context view has some space constraints
> > too. Did
> > you already investigate which plasma formfactor we should use when
> > putting stuff into the context view?
>
> yes, there are form factors for plasmoids.
> but they are not exactly applicable to us. basically, the planar form
> factor mean you have 2 degrees of freedom (like normal). there is then
> a mediacenter form factor which assumes tha the user is ~10ft away
>
> >from the screen---not exactly applicable to us. and then there is a
>
> horizontal/vertical form factor that constrain the applet's movement
> in one of the two directions.
>
>
> it seems to me that we have less of a use for the formfactors than plasma
> itself, as we don't have to deal with such a broad spectrum of use cases.
>
> > a) we need a slightly different architecture. plasma is designed to be as
> >
> > > extensible and decentralized as possible, but we need to handle events
> >
> > like
> >
> > > track changes, showHome, etc, which requires manual  involvement in
> >
> > plasma.
> >
> > > and that is just one example.
> >
> > I'm not sure what exactly you mean by "manual involvement in plasma". can
> > you
> > create a branch with your code so that we can have a look? Shouldn't the
> > data
> > engine be able to tell the applets to hide themselves (by applets i mean
> > the
> > stuff which draws on the screen...i'm not very familiar with the plasma
> > terminology yet). The data engine (or maybe more than one, we'll see)
> > will be
> > tightly tied to Amarok and will use our internal API, so it's not a
> > problem
> > to integrate all the events you mentioned there.
>
> first of all, there is a branch :) there still isn't any of my code
> there, because i'm wrestling with svn to get all my of changes
> registered and all that. you
> can find it here
> https://svn.kde.org/home/kde/branches/work/amarok-plasmify
>
> the biggest obstacle that i foresee right now regards the data engines. the
> way plasma is structures both data engines and plasmoids are KTrader
> plugins. that means that they are separately linked applications that
> communicate at runtime. we want to be able to have "internal" data engines
> that run in the source and have access to amarok's internals. i'm still in
> the progress of figuring out how to best implement that.

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.

> > b) plasma is kdebase. AFAIK we want to only link to kdelibs, as kdebase
> > is
> >
> > > a pretty steep requirement, and ties us effectively to the KDE desktop.
> >
> > i
> >
> > > mean, if the user isn't running KDE, amarok should still have an
> > > awesome
> > >
> > > context thingie :)
> >
> > That's  not a problem. For the time being, we'll keep a copy of plasma in
> > our
> > source tree. As Aaron mentioned in the original mail of this thread, they
> > are
> > planning to move parts or all of plasma to some place outside of kdebase
> > as
> > soon as they can guarantee BC.
>
> as i said in previous emails, the way it works, at least currently,,
> is not by keeping a copy of plasma in our source tree. that would
> entail having an svn extern entry and pulling/linking libplasma directly.
> this is probably the most difficult decision/compromise that we have:
> on one hand, if we don't use plasma directly we don't keep up with plasma
> changes and we effectively fork the parts of the code that we have. thats
> not good. because we lose bugfixes and features etc. (this is how it works
> now). but on the plus side, we can customize plasma to work for us because
> we *do* have different needs than the KDE desktop and need to have more
> control: case in point, with stock plasma we can only register data engines
> and plugins via KTrader, so how do you have any data engines which run
> internally from amarok?

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.

> on the other hand, we could embed libplasma for now into our source, and
> eventually just link to libplasma once its been released. but then we run
> into the problems i mentioned above, and it seems to me that we would need
> to write a considerable amount of glue code to make the two parts work ok.
>
> but of course there are just my opinions... i'm completely open to being
> convinced :)
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20070711/c7fb5a3e/attachment.pgp