2.4 planning

[Bart Cerneels]

On Thu, Sep 23, 2010 at 16:41, Leo Franchi <lfranchi at kde.org> wrote:
> On Thu, Sep 23, 2010 at 10:32 AM, Mark Kretschmann <kretschmann at kde.org> wrote:
>> 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.
>
> Actually LastFm does not implement MultiSourceCapability. A Last.fm
> stream is 1 stream that changes URL over time, and so it implements
> the MultiPlayableCapability--which is different and not as messy to
> deal with in EngineController.
>
> The MultiSourceCapability stuff is what provides the cool feature of
> wrapping multiple alternative stream servers into 1 playlist item,
> rather than having them all be in the playlist as individual streams.
>
> leo

I have some ideas how to refactor that. Basically by letting the
StreamTrack select it's own playableUrl intelligently. By either
pre-checking or being EngineObserver it can select a working one or
become unavailable.
The handling of unavailable tracks is something required by many
missing/broken features so needs to be looked into as well.

I'm not sure if the multisource capability will still be needed after
this. Perhaps still for collection tracks we have multiple copies for
in different formats.