<span class="gmail_quote">On 7/10/07, <b class="gmail_sendername">Maximilian Kossick</b> <<a href="mailto:mkossick@gmx.de" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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">
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 external<br>> > 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 is<br>> something to think about in the future. we can't have amarok be another
<br>> another formfactor of plasma for a few reasons:<br><br>I know that there are formfactors for putting plasmoids into horizontal or<br>vertical task bars. Amarok's context view has some space constraints too. Did
<br>you already investigate which plasma formfactor we should use when putting<br>stuff into the context view?</blockquote><div><br></div>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.
<br><br>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.<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">
> a) we need a slightly different architecture. plasma is designed to be as<br>> extensible and decentralized as possible, but we need to handle events like<br>> track changes, showHome, etc, which requires manual involvement in plasma.
<br>> and that is just one example.<br><br>I'm not sure what exactly you mean by "manual involvement in plasma". can you<br>create a branch with your code so that we can have a look? Shouldn't the data
<br>engine be able to tell the applets to hide themselves (by applets i mean 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) will be
<br>tightly tied to Amarok and will use our internal API, so it's not a problem<br>to integrate all the events you mentioned there.</blockquote><div> </div>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
<br><a href="https://svn.kde.org/home/kde/branches/work/amarok-plasmify" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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 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.
<br><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 is<br>> a pretty steep requirement, and ties us effectively to the KDE desktop. i<br>> mean, if the user isn't running KDE, amarok should still have an awesome
<br>> context thingie :)<br><br>That's not a problem. For the time being, we'll keep a copy of plasma in our<br>source tree. As Aaron mentioned in the original mail of this thread, they are<br>planning to move parts or all of plasma to some place outside of kdebase as
<br>soon as they can guarantee BC.</blockquote><div> </div>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:
<div><br>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?
<br><br>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.
<br><br>but of course there are just my opinions... i'm completely open to being convinced :)<br><br>leo</div><br>_______________________________________________<br>Amarok-devel mailing list<br><a href="mailto:Amarok-devel@kde.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
Amarok-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/amarok-devel" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> https://mail.kde.org/mailman/listinfo/amarok-devel</a><br><br>
<br><br><br clear="all"><br>-- <br>______________________________________________________<br>Leo Franchi <a href="mailto:angel666@myrealbox.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
angel666@myrealbox.com</a><br>4305 Charlemagne Ct <a href="mailto:lfranchi@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">lfranchi@gmail.com</a> <br>Austin cell: (650) 704 3680
<br>TX, USA home: (650) 329 0125