<span class="gmail_quote">On 7/10/07, <b class="gmail_sendername">Bart Cerneels</b> <<a href="mailto:bart.cerneels@gmail.com">bart.cerneels@gmail.com</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 Tuesday 10 July 2007, Leo Franchi wrote:<br>> Max is indeed correct: i already have Plasma working in the context<br>> view. so far, its only<br>> plasma--e.g<br>> . no applets, no management, no anything. but hey, its still plasma,
<br>> and the architecture is there :)<br>><br>> anyway, since applets will be first-class plugins (we'll use the<br>> KTrader system for applets) it makes it much easier to theme---as max<br>> says, a desktop theme can just include svgs for amarok and we will be
<br>> themed too :)<br><br>wow, impressive.<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.</blockquote><div><br>well, not exactly. the way you are thinking of the new contextview is like simply <br>another facet of plasma, e.g. plasma "extended" into amarok. thats not actually how it (currently) works.
<br><br>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:
<br><br>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.
<br>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 :)
<br></div><br>so to sum up, no plasma code is being changed.<br> <br>leo<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">
Bart<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></blockquote><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