<br><br><div><span class="gmail_quote">On 7/11/07, <b class="gmail_sendername">Maximilian Kossick</b> <<a href="mailto:mkossick@gmx.de">mkossick@gmx.de</a>> wrote:</span><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
On Wednesday 11 July 2007, Leo Franchi wrote:<br>> On 7/10/07, Maximilian Kossick <<a href="mailto:mkossick@gmx.de">mkossick@gmx.de</a>> wrote:<br>> > SNIP<br>> ><br>> > > > So I guess the plan is to make Amarok::ContextView another formfactor
<br>> > > > (like desktop, panel, mediacenter). Does that mean we need to expend<br>> > > > some enum in plasma?<br>> > > ><br>> > > > Is there drag and drop support already? Some day I want to be able to
<br>> > > > drag plasmoids out of CV to plasma.<br>> > > ><br>> > > > Do we need a data engine inside of Amarok, the same process. It seems<br>> > > > kind of strange that the CV widgets talk to Amarok through an
<br>> > > > external process.<br>> > ><br>> > > well, not exactly. the way you are thinking of the new contextview is<br>> > > like simply<br>> > > another facet of plasma,
e.g<br>> > > . plasma "extended" into amarok. thats not actually how it (currently)<br>> > > works.<br>> > ><br>> > > right now i've copied/modified the relevant source files from the
<br>> > > plasma source tree into amarok. so we have our "own"<br>> > > plasma. we will have our own plugins, with our own servicetype. now,<br>> > > it would be cool<br>> > > if we could just drag and drop from plasma<->amarok, but that i think
<br>> > > is something to think about in the future. we can't have amarok be<br>> > > another<br>> > ><br>> > > another formfactor of plasma for a few reasons:<br>> ><br>> > I know that there are formfactors for putting plasmoids into horizontal
<br>> > or vertical task bars. Amarok's context view has some space constraints<br>> > too. Did<br>> > you already investigate which plasma formfactor we should use when<br>> > putting stuff into the context view?
<br>><br>> yes, there are form factors for plasmoids.<br>> but they are not exactly applicable to us. basically, the planar form<br>> factor mean you have 2 degrees of freedom (like normal). there is then<br>> a mediacenter form factor which assumes tha the user is ~10ft away
<br>><br>> >from the screen---not exactly applicable to us. and then there is a<br>><br>> horizontal/vertical form factor that constrain the applet's movement<br>> in one of the two directions.<br>>
<br>><br>> it seems to me that we have less of a use for the formfactors than plasma<br>> itself, as we don't have to deal with such a broad spectrum of use cases.<br>><br>> > a) we need a slightly different architecture. plasma is designed to be as
<br>> ><br>> > > extensible and decentralized as possible, but we need to handle events<br>> ><br>> > like<br>> ><br>> > > track changes, showHome, etc, which requires manual involvement in
<br>> ><br>> > plasma.<br>> ><br>> > > and that is just one example.<br>> ><br>> > I'm not sure what exactly you mean by "manual involvement in plasma". can<br>> > you
<br>> > create a branch with your code so that we can have a look? Shouldn't the<br>> > data<br>> > engine be able to tell the applets to hide themselves (by applets i mean<br>> > the<br>> > stuff which draws on the screen...i'm not very familiar with the plasma
<br>> > terminology yet). The data engine (or maybe more than one, we'll see)<br>> > will be<br>> > tightly tied to Amarok and will use our internal API, so it's not a<br>> > problem<br>> > to integrate all the events you mentioned there.
<br>><br>> first of all, there is a branch :) there still isn't any of my code<br>> there, because i'm wrestling with svn to get all my of changes<br>> registered and all that. you<br>> can find it here
<br>> <a href="https://svn.kde.org/home/kde/branches/work/amarok-plasmify">https://svn.kde.org/home/kde/branches/work/amarok-plasmify</a><br>><br>> the biggest obstacle that i foresee right now regards the data engines. the
<br>> way plasma is structures both data engines and plasmoids are KTrader<br>> plugins. that means that they are separately linked applications that<br>> communicate at runtime. we want to be able to have "internal" data engines
<br>> that run in the source and have access to amarok's internals. i'm still in<br>> the progress of figuring out how to best implement that.<br><br>Um, no. I just checked plasma in kdebase, and both applets and data engines
<br>are just plugins. And it's no problem to link plugins to libamarok. That's<br>what i'm doing for the collection plguins for example. </blockquote><br>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
<br> KTrader for plugins that fulfill a certain constraint, and then tell KTrader to load one, how can that <br>plugin have access to internals of the currently running amarok instance?<br><br><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
> > b) plasma is kdebase. AFAIK we want to only link to kdelibs, as kdebase<br>> > is<br>> ><br>> > > a pretty steep requirement, and ties us effectively to the KDE desktop.<br>> ><br>> > i
<br>> ><br>> > > mean, if the user isn't running KDE, amarok should still have an<br>> > > awesome<br>> > ><br>> > > context thingie :)<br>> ><br>> > That's not a problem. For the time being, we'll keep a copy of plasma in
<br>> > our<br>> > source tree. As Aaron mentioned in the original mail of this thread, they<br>> > are<br>> > planning to move parts or all of plasma to some place outside of kdebase<br>> > as
<br>> > soon as they can guarantee BC.<br>><br>> as i said in previous emails, the way it works, at least currently,,<br>> is not by keeping a copy of plasma in our source tree. that would<br>> entail having an svn extern entry and pulling/linking libplasma directly.
<br>> this is probably the most difficult decision/compromise that we have:<br>> on one hand, if we don't use plasma directly we don't keep up with plasma<br>> changes and we effectively fork the parts of the code that we have. thats
<br>> not good. because we lose bugfixes and features etc. (this is how it works<br>> now). but on the plus side, we can customize plasma to work for us because<br>> we *do* have different needs than the KDE desktop and need to have more
<br>> control: case in point, with stock plasma we can only register data engines<br>> and plugins via KTrader, so how do you have any data engines which run<br>> internally from amarok?<br><br>see above, we can link data engine plugins to libamarok. And I don't see any
<br>other reasons for forking plasma atm. Of course, I didn't actually work on it<br>as much as you did, so I'm probably missing something. </blockquote><br>i probably need to investigate this further. it seems to me at least that we would need to extend
<br>plasma's functionality to fit us. on track changes, for example, we need to notify plugins. we want to have saved<br>"states" of plugins, e.g. when a track ends our context area should return to how the home screen looked last.
<br> that way a user can add a plugin to the home screen and then it would be shown every time the home screen is<br> shown---and if he moves it around, that is where it will appear on the next showing of the home screen. right now
<br> that doesn't exist in plasma (because there is no use case for it). at least, i don't see anything like that. <br><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
> on the other hand, we could embed libplasma for now into our source, and<br>> eventually just link to libplasma once its been released. but then we run<br>> into the problems i mentioned above, and it seems to me that we would need
<br>> to write a considerable amount of glue code to make the two parts work ok.<br>><br>> but of course there are just my opinions... i'm completely open to being<br>> convinced :)<br>><br><br>_______________________________________________
<br>Amarok-devel mailing list<br><a href="mailto:Amarok-devel@kde.org">Amarok-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/amarok-devel">https://mail.kde.org/mailman/listinfo/amarok-devel</a><br><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>______________________________________________________<br>Leo Franchi <a href="mailto:angel666@myrealbox.com">angel666@myrealbox.com</a><br>4305 Charlemagne Ct
<a href="mailto:lfranchi@gmail.com">lfranchi@gmail.com</a> <br>Austin cell: (650) 704 3680<br>TX, USA home: (650) 329 0125