Plasma and Amarok

[Seb Ruiz]

On 09/07/07, Leo Franchi <lfranchi at gmail.com> wrote:
> On 7/9/07, Aaron J. Seigo <aseigo at kde.org> wrote:
> > On Sunday 08 July 2007, you wrote:
> > > basically, i was wondering if you had any particular
> > > reservations/comments/whatever as to the use of a plasma-inspired
> > > contextview in amarok, mostly because you *are* plasma :) i'm not
> planning
> >
> > ..
> >
> > > so if you don't think that amarok is a good place for a plasma-like
> > > graphicsview, or have any specific comments, feel free to point them
> out. i
> > > just wanted to give you a heads up on what i'm planning to try.
> >
> > i think it makes lots of sense.. it turn out to be some very cool stuff =)
> > i'll be making libplasma publicly available in 4.1 (e.g. by guaranteeing
> > binary compat; we already install headers with dptrs and whatnot but there
> > are no BC guarantees currently) and at that point moving parts or perhaps
> > even all of the lib to somewhere outside of kdebase... at that point we
> may
> > be able to remove some of the duplication in code and what not.
> >
> > for 4.0 you could also just put libplasma into amarok itself and compile
> it in
> > as a static lib; with an 'svn extern' entry in the amarok tree you could
> then
> > track libplasma from kdebase without having an actual kdebase dependency.
>
> thank you for the prompt reply :) the compiling of a static
> plasma library directly in the amarok source
> looks interesting, but i'm not sure if
> we'll need the full resources/complexity
> of plasma to justify it. either way, i'll
> start doing it bit-by-bit and if it turns
> out that i'm pretty much bringing all of
> it in to amarok, i'll go ahead and svn extern
> it and compile libplasma statically.
>
> amarok devs: what do you guys this?

I'm still having difficulty compiling kdebase/kdepimlibs so I haven't
been able to test plasma first hand. That said, my gut feeling is that
it would be better to use libplasma as a guide, and not simply copy it
over - for the primary reason of unneeded complexity.

Seb

-- 
http://www.sebruiz.net/