2.4 planning

[Ralf Engels]

<snip>

> Here are two more popular requests that I just remembered:
> 
> 1)
> Reading cover images from file metadata. This shouldn't be very hard
> to do, I suppose? Maybe a good project for our university students
> from Germany, or maybe for the OpenHatch folks.
> 

If you mean embedded cover support, then it's already in since two or
three months.


> 2)
> Crossfading support. This one is a very popular wish, because Amarok
> 1.x supported it as well. From my point of view, the implementation is
> probably not very difficult to do in theory (as long as Phonon
> supports it). But:
> 
> Our EngineController is one big ugly mess of code. It wasn't always
> that way; in fact it started out as a very thin wrapper around Phonon
> when we began creating Amarok 2.0. However, we added more and more
> features, and they were implemented by different people. One aspect
> that very much complicates the EngineController logic is our Queue
> feature.
> 
> I know it's a popular feature with some (I personally find it a
> misfeature), but I challenge any fans of this feature to take a look
> at EngineController, and try to make sense of the code that provides
> the next upcoming track from the Queue or Playlist. If you can
> untangle this mess and simplify it, more power to you! Before that
> happens, I'd find it a bad idea to add even more code to the
> EngineController class.
> 

Just today I've done some things for the EngineController and I noticed
that it could use some refactoring.
However it didn't look that broken. Just overly complex. I personally
would leave it for now.


> I also missed the Queue Manager in the beginnings of Amarok2, but after I had 
> thought about it and long discussions on this list I think the problem is not 
> the missing QM, but the fact that for many people (including me) the current 
> playlist tends to become a container for anything you want to "remember" for 
> playing later. Thus it grows uncontrolled and it becomes hard to "queue" songs 
> by rearranging their order. A possible solution I would really love to see is 
> consists of two things:
> 1) a dynamic playlist, which feeds the current playlist from songs of a static 
> playlist (sounds complicated, I hope you understand me :)
> 2) detach the saved playlists view from the collection view, so you can show 
> them side by side and drop songs directly from the collection or file browser 
> into saved playlists. That would prevent people from misusing the current 
> playlist as a container for everything.
> 
> If you use the "dynamic playlist from static playlist" approach, you have only 
> a few tracks in the current list at a time, and if you want to "queue" a song, 
> it should be easy to place it directly behind the playling one.
> 

I am using the dynamic playlist all the time.
It could use some improvements (e.g. a bias that plays song in the disk
order) but I am currently quite satisfied with it.
However the static playlist bias sounds like a cool idea.

What I am really wondering... why do you people take the effort to
create a playlist after all?
If you only want to play your favorite songs, why not set the rating and
use the dynamic playlist?
How are you using the static playlists?

BR,
Ralf