Plasma and Amarok
Leo Franchi
lfranchi at gmail.com
Wed Jul 11 10:07:09 CEST 2007
just a heads up, i upped all the code i have so far to
https://svn.kde.org/home/kde/branches/work/amarok-plasmify
have fun :)
On 7/11/07, Leo Franchi <lfranchi at gmail.com> 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.
>
>
>
> > 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
>
--
______________________________________________________
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/e589c2da/attachment.html
More information about the Amarok-devel
mailing list