Hello Aaron,<br> First of all, thank you for the prompt reply to my initial mail about Plasma-like integration into Amarok. Now that I have spent a few days playing around with plasma in amarok (and trying various methods of making it work) I have a few issues which i think may be important.
<br><br>Given that the goal is to acheive a very plasma-like interface as the Context part of Amarok 2.0, i see two possible paths: first, plasma is copied into the amarok source, and modified where needed. second, plasma is linked internally (and svn externed, as you mentioned), and plasma functionality is extended via subclassing. now, the first method is easier, but since it practically forks plasma itself it cuts us (amarok) from any future improvements in plasma. however, in implementing the second solution via subclassing is not proving completely successful, because a *very few* things are hardcoded in plasma that subclassing cannot override (mostly KServiceTrader-related strings).
<br> <br>It would not be very difficult to modify plasma itself to allow for this kind of customization; with the ability to specify which KTrader plugin types as well as servicenames the svn extern method would be functional.
<br> <br>anyway, we (the amarok team) thought that it might be mutually beneficial to arrage some sort of meeting/conversation of sorts to talk these things through---if you are willing, of course. IRC was proposed, either #amarok.dev of #plasma or any channel really.
<br><br>best,<br>leo<br><br>______________________________________________________<br>Leo Franchi <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