Plasma and Amarok

[Leo Franchi]

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.



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

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 :)

leo

_______________________________________________
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/cd85ced8/attachment-0001.html