2.4 planning

[Bart Cerneels]

On Thu, Sep 23, 2010 at 15:21, Mark Kretschmann <kretschmann at kde.org> wrote:
> 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.
>

Crossfading does sound unrelated to the queue-management feature so it
shouldn't influence. But that is the nature of spaghetti code of
course.

Now I'm tempted to bring up the big Play Queue vs. Playlist debate
again which would simplify both EngineController (back to the simple
phonon wrapper or even less) and PlaylistModel. The complexity would
be entirely gone if we only determine playback order when adding to
the Play Queue i.e. completely remove our current queue feature.
In addition PlaylistModel and it's views could be used for other
purposes as well (Saved Playlists specifically) because it wouldn't
contain any of the nasty feature-creep bits.

Bart