2.4 planning

[Mark Kretschmann]

On Mon, Sep 20, 2010 at 8:19 PM, Mark Kretschmann <kretschmann at kde.org> wrote:
> On Mon, Sep 20, 2010 at 7:57 PM, Lydia Pintscher <lydia at kde.org> wrote:
>> Heya folks :)
>>
>> Let's start some thinking and planning for Amarok 2.4.
>> What are your plans? What are the big (and small) things that need to
>> happen? (Not including GSoC projects - separate thread)
>> I'll try to start making a release plan next week when I'm back home.
>
> I think visualization support is a much requested feature, it would be
> nice to have. I think Daniel Dewald and maybe Sandsmark were working
> on it?
>
> Another  *very* important aspect would be rewriting our media devices
> framework. Currently it's so broken that I can't even transfer a
> single album to my Sansa without crashing Amarok. Bart Cerneels said
> that there is little hope of just "patching" it, but that the whole
> system needs a full rewrite - a lot of work.
>
> As for myself, I've wanted to implement applet versioning for a long
> time, maybe I'll get around to it this time. Generally I'd also like
> to emphasize bug fixing. Amarok has many features, but few of them
> actually work correctly.
>
> I probably want to do many other things too, but can't think of them
> now ;) Maybe I can add it to the plan later on.

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.

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.

-- 
Mark Kretschmann
Amarok Developer
Fellow of the Free Software Foundation Europe
http://amarok.kde.org - http://www.fsfe.org