Plasma and Amarok

Wed Jul 11 10:22:43 CEST 2007

On 7/11/07, Maximilian Kossick <mkossick at gmx.de> wrote:
>
> 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.

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?

> > 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.

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.

> 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 :)
> >
>
> _______________________________________________
> 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/d557aed0/attachment-0001.html 