[prev in list] [next in list] [prev in thread] [next in thread] 

List:       amarok-devel
Subject:    Re: Playlist Navigation (was: Queue Manager)
From:       Seb Ruiz <ruiz () kde ! org>
Date:       2010-02-09 12:10:36
Message-ID: 60ebdd0b1002090410p1389be13gc20fca106df4860c () mail ! gmail ! com
[Download RAW message or body]

On 9 February 2010 22:38, Marius <furt@gmx.de> wrote:
> on Monday 08 February 2010 22:20 Bart Cerneels wrote:
> > On Mon, Feb 8, 2010 at 22:00, Seb Ruiz <ruiz@kde.org> wrote:
> > > Whilst I am not against the feature (I wrote it in 1.4), we did
> > > explicitly remove the queue manager for Amarok 2.x. I can't remember
> > > the exact reasoning, except that it was deemed overkill and
> > > unnecessary in the face of culling features.
> > > 
> > > Has there been any change in direction in this regard, and do the \
> > > core Amarok team regard the queue manager as a worthwhile and \
> > > reasonable feature to implement, regardless of who does the work?
> > > 
> > > --
> > > Seb Ruiz
> > 
> > Nope, I personally still think it's useless feature creep that will
> > only increase the complexity of the   playlist.
> > 
> 
> While I don't know about the previous discussion on the queue concept, I \
> think in its current state amarok needs a queue manager. I guess we \
> agree, that the user should be able to define which track or tracks are \
> played next - be it because he personally likes them, or they are wishes \
> by listeners (at a party), or whatever. If he is able to do that, he \
> should be able to change that list of queued tracks.

This is the extent of the functionality of the queue manager from Amarok \
1.4

> 
> 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.

> 
> 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.

> 
> 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)

> 
> Additionally we have the problem, that the current playlist tends to \
> become a mess of random tracks, like the desktop of older windows \
> distributions, which makes navigating and ordering quite hard. That is \
> because for anything you do with saved playlists, you need to put tracks \
> on the current playlist. You can't drag tracks directly from the \
> collection to a saved playist, but have to go the indirection through the \
> current playlist. It's also rather hard to drag tracks from one playlist \
> to another if you have many playlists or playlists with many tracks. If \
> you want to create a new saved playlist, you even have to clear the \
> current playlist, drag the desired tracks for the new saved playlist on \
> it and save it - that's obviously not possible while playing another set \
> of tracks.

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.

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."

> 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)


-- 
Seb Ruiz

http://www.sebruiz.net/
http://amarok.kde.org/
_______________________________________________
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel


[prev in list] [next in list] [prev in thread] [next in thread]