Hallo,

on Tuesday 09 February 2010 13:10 Seb Ruiz wrote:
> On 9 February 2010 22:38, Marius <furt@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" :)
_______________________________________________
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel