2.4 planning

[Leo Franchi]

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



-- 
_____________________________________________________________________
leo at kdab.com                                 KDAB (USA), LLC
lfranchi at kde.org                             The KDE Project