Playlist Navigation (was: Queue Manager)

[Bart Cerneels]

On Tue, Feb 9, 2010 at 13:38, Marius <furt at gmx.de> wrote:
> Hallo,
>
> on Tuesday 09 February 2010 13:10 Seb Ruiz wrote:
>> On 9 February 2010 22:38, Marius <furt at gmx.de> wrote:
>> > Furthermore he should be able to compose sets of tracks and easily play
>> > both whole sets (random or ordered) and single tracks from a set in a
>> > defined order.
>>
>> I don't see any reason why we should support such a feature.  This is
>> introducing an increased complexity (which even I struggle to
>> understand) to a feature which was always intended to be bare bones.
>> The Amarok team was split over implementing queueing - so we settled
>> on a simplistic implementation; we wanted to avoid the playlist within
>> a playlist paradigm which can be so confusing.
>
> By "sets of tracks" I actually mean "saved playlists". And imho those are not
> too complex to understand, and its also a valid wish to play a playlist you
> have composed. Use cases for playlists could be playlists composed for a
> party, "songs I loved in summer 2009", "songs I want to push to my portable",
> ...
>
>>
>> > One way out of this is a queue manager. But additional thought brought me
>> > to a new idea: if we had a way to use a non-random current playlist *and*
>> > still be able to play saved playlists in random order, the need for queue
>> > concept would be totally superseded. You could simply drag the tracks to
>> > be played next behind the currently playing track.
>>
>> this is what the dynamic playlist is.
>
> That's part of what I wanted to express with my previous post.
>>
>> > For that we would need a dynamic playlist which plays tracks from a saved
>> > playlist in either random or non-random order (*wah*, we have way to many
>> > things called playlist :) ). Ideally, this dynamic playlist could easily
>> > be "programmed" by rightclicking on an existing saved playlist and select
>> > something like "play now".
>>
>> Much like in Amarok 1.4 - a dynamic playlist could be seeded by a
>> smart playlist (with random ordering or what not)
>
> As I have suggested - just do not feed just by smart playlists, but also by
> saved, static playlists.
>
>>
>> > [...]
>> So the solution here isn't a queue manager, but rather to allow drops
>> onto the playlist browser.
>>
>> > Summing up, amarok in its current state needs a queue manager.
>> > If we polish the handling of saved playlists, the queue concept is
>> > rendered useless. To achieve that, we need an easy way to access and
>> > navigate through saved playlists and an easy to use dynamic playlist,
>> > which plays tracks from saved playlists.
>>
>> I think this may be contradictory - you say that Amarok needs a queue
>> manager, but then say that queues are redundant with better saved
>> playlists.
>
> Sorry for not expressing myself clearly, what I meant to say is that as long
> if we don't have a dynamic playlist feeded from a saved playlist and a decent
> playlist browser, we need a queue manager. As soon as those features are
> implemented, we do not need a queue manager.
>
>>
>> Maybe you have missed the *simplest* case for queueing, which is
>> indeed why it exists:
>>    "There are many tracks in the playlist, which are played in random
>> order. On the spur of the moment, I see or think of a track that I
>> would like to hear next, and want to continue randomly afterwards."
>
> Agreed.
>
>>
>> > A decent saved-playlists-browser would be cool, probably with the
>> > possibility to open one or more playlists in a new window and drag tracks
>> > between them, the current playlist and the collection.
>>
>> I doubt this would get implemented (see the topic on Feature Creep)
>
> I've read those topics, and that's why I tried to give reasonable arguments
> for this feature, and not just said "we need a playlist browser" :)


So the conclusion is we don't need a queue manager. Congrats, we
understood that more then a year ago.

Now about that playlists browser: we have one in the "Saved Playlists"
category. What is missing from it to make your workflow (that now
requires a queue-manager) possible? Or wrong to prevent that.

Bart