Plasma and Amarok

[Maximilian Kossick]

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?

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

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

> so to sum up, no plasma code is being changed.

yay:)
-------------- 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/20070710/f6694532/attachment.pgp