2.4 planning

[Mark Kretschmann]

On Thu, Sep 23, 2010 at 3:54 PM, Bart Cerneels <bart.cerneels at kde.org> wrote:
> 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.

To be fair, it's not only the Queue code causing complexity, but
especially also the "Multi-Source" code needed for Last.fm playback.
This is because a Last.fm "stream" is like a mixture of radio stream
and single track. A track that contains multiple songs, so to speak.

Moving this logic out of EngineController would help a lot.

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