Ready. Steady. Amarok 2.0 development begins!!

[Jeff Mitchell]

Quoting Alexandre Oliveira <aleprjlists at gmail.com>:

> On 2/2/07, Seb Ruiz <me at sebruiz.net> wrote:
>> * Engines to be external processes due to licensing?
>
> Or maybe just use phonon?

If Phonon looks like it's going to be good for our purposes but we  
don't want to lose support for engines we already have we could work  
on porting our engines to Phonon.  That way people used to xine  
dependencies, helix, etc. will find similar options in Phonon.   
Obviously this comes much later but it as devs of one of the more  
preeminent audio apps on KDE it may come to us to do it...

>> * MVC designed browsers/components?
>
> I'll be so happy when the time to refactor comes...

Sorry...MVC?  All I can think of is Microsoft Visual C++.  Which I  
know it's not.  Model/View comes to mind from past things I've heard  
but I don't really have a grasp on what that's all about.


>> * Interface redesign. We had a couple of suggestions already, but are
>> we ready to take such a huge leap? Conversely, Amarok has always been
>> at the front of the pack because we do take risks.
>
> Everybody has its share of suggestions regarding this. I'd like to see
> some testing with a playlist without columns. Maybe with the user
> setting the look of it in a similar way to how we set OSD now. Maybe
> having other playlists inside of the playlist, and having them show
> they're subplaylists. Maybe having grouping for contiguous tracks by
> the same artists/albums.

This could perhaps fit into the Firefox way of thinking?  Perhaps the  
interface itself could be defined by APIs.  Think Winamp skins.  Some  
people may love playlists without columns; others may want no such  
thing but may want support for multiple playlists open via tabs; etc.  
etc.

> More complete plugin API (not just scripting). Think Firefox extensions.

I'm all for this.  I think we need to have a very good and very  
generic set of high-level APIs, and we need to ensure that they're  
flexible for whatever may come.  Think of how the MediaBrowser had to  
be tweaked to hell once we wanted to support things other than just  
iPods, and had to handle capabilities that some devices may or may not  
have.  Adding this support to devices, because of inheritance, etc.  
meant that most devices ended up with lots of useless variables and  
functions defined.  Muy confusing.

To this end I think that our APIs need to allow for clients to define  
new capabilities on the fly -- almost like Bluetooth with service  
discovery.  For instance, some media device could come in and tell our  
manager that it supports PodcastSyncing.  Our manager shouldn't have  
to know ahead of time what PodcastSyncing is or what it requires; it  
should just know what capabilities each device supports.  Then other  
plugins or Amarok itself could query the manager, and if a device  
supports PodcastSyncing, then the plugin can make calls on the device.

In essence, I think we should try to decentralize defining all  
possible capabilities in Amarok itself, like was done in 1.x (scripts  
were just DCOP calls, for instance), and let plugins do it dynamically.

*HOW* this is all done, well...  :-)

--Jeff