Queue support and The Playlist

[Bart Cerneels]

On Tue, Dec 16, 2008 at 3:44 PM, Bart Cerneels <bart.cerneels at kde.org> wrote:
> Hi all,
>
> I promised to start a discussion about the queue manager.
>
> Fact: users want the queue manager back:
> https://bugs.kde.org/show_bug.cgi?id=171939
>
> In my mind The Playlist is a queue, and the order of tracks in there
> is the order they will be played. I couldn't imagine anyone trying to
> use it any other way. In fact, when I learned about the queue manager
> I literally didn't understand it's use-case.
> Now I've realized that the people who use the queue manager for a
> couple of different reasons:
>
> 1) Playlist editor:
> Because Amarok doesn't have a separate playlist editor, people started
> using the PlaylistView like the Juk editor. Not wanting to destroy
> their precious works of (playlist-)art, mainly sort order, they use
> the queue-manager to play those tracks in an order other then the
> list-order.
> note: they could have just saved the playlist to disk and then
> rearranged, but the human mind probably perceives that as destroying
> previous work. We can't blame our users for being human, even tough
> they want us to be super-human.
>
> 2) Single click queue adjustment:
> Not everyone enjoys drag and drop. Especially if you want to arrange a
> large number of tracks fast clicking is easier. The queue-manager
> allows you to do that with Ctrl+"Right Click".
>
>   There might be other use cases. Reply if you can think of some.
>
> These are both useful features, both of which are missing in Amarok 2.
> A straight port of the queue manager from 1.4 would indeed solve 2)
> and allow users to do 1) sort of like before. But we still have the
> opportunity to rethink the concept now and implement it in a simpler
> way.
> So I propose we solve both separately, a Meta::Playlist editor and
> added functionality to PlaylistView for queueing.
>
> One click queueing we could easily implement with a mode that sends a
> track to right below the playing track when left-clicked (think
> touchscreen). Or use the middle button for this regardless of mode.
>
> I propose to make a playlist editing plasmoid to cover 2) and make
> mass tagging like in 1.4 possible. This should obviously be a
> spreadsheet view, which some users can't seem to do without. This
> would *not* be a queue editor. But since playlists can be saved,
> edited and then loaded in the queue the functionality is the same, if
> not better. It also allows any group of tracks from a Meta::Playlist
> to be added to the queue.
> We could still implement queue sorting in the way leinir proposed [1]
> but at least it will be used for queue ordering and not the only, or
> the prefered, UI for playlist editing.
>
> Now I understand Seb has queue-manager for 2.0 in a git tree. So
> perhaps it's similar to what I propose or a port from 1.4, need to see
> the code. Anyway I've started on the middle-click queue adjustment
> already, the playlist plasmoid is something I want for 2.1.
>
> [1] http://amarok.kde.org/blog/archives/810-The-Old-style-Playlist-Is-Dead,-Long-Live-The-Old-style-Playlist.html
>

I've had a chat with Nikolaj today which has given both of us some
more insight into what I'm really talking about here.

In his reply to commentors to his latest blog post [1] (2008-12-18
10:57) nhn writes:

    The playlist in Amarok 2 is meant as a much more transient thing.
Of course you can save and restore playlist, move stuff around and all
that, but its not meant to be "permanent" in the sense that the
collections are. This is in contrast to the usage pattern of the
versions of Winamp I was using many years ago, Xmms and many other
apps. Which is why, I am guessing, that many users take this usage
pattern with them to Amarok.

This is exactly what I mean when I say we should separate the
"permanent" playlist editing from the transient queueing. I take a
radical stance in this and say we should have different UI's for both,
with Queue being the main one that is always visible. And we should
also adhere very strictly to the queue concept, where the only
navigation to the next track is row++, with the exception of "repeat
track" and "repeat album".

The main idea behind the Queue is that it is a direct visualization of
what will be played next and what has already played. With normal,
sequential, playback this behaves exactly the same as The Playlist
does now.
In other modes:
 Random: when starting playback, on user request or at the end of a
track, the upcoming tracks are shuffled. This should be animated of
course. After shuffling the next track in the list is played.

 Repeat Track: stays in the same row but increments a visual counter.
 Repeat Album: at the end goes back to the first track and increments
the play counter.

Then only thing you'll have to let go is the "destruction" of the
order and grouping in the queue. But I believe as long as the playlist
is represented separate from the queue this is no problem. And as once
we get more grouping possibilities like "by genre", "by artist", ...
that might not be such an issue at all.

I've created a page for this idea on the wiki:
http://amarok.kde.org/wiki/Proposals/Queue

[1] http://amarok.kde.org/blog/archives/854-Amarok-2-playlist-searching.html