Queue support and The Playlist

[Seb Ruiz]

2008/12/17 Bart Cerneels <bart.cerneels at kde.org>:
> 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

Queuing and the Queue Manager are two totally separate features in the
Amarok 1.4 codebase. The manager was the little dialog which allows
you to reorder the queue as you like, and then commit to the playlist.
As it stands, this feature will not return to Amarok 2. The queuing
functionality will return however.

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

The simplest and best example I can give is listening to a set of
albums on random mode, but wanting to listen to a particular song
next. Since the user can't guarantee the order of playback, the queue
is used. The idiom of using the Playlist as a "play sequence" where
all tracks are played in order is not totally encompassing.


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

This is actually using the queues in a method they weren't intended to
be used, and I'll place a lot of money that this isn't how the
majority of people use it.


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

You've missed the primary use case of queuing, but I've detailed it above.

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

I fail to see how batch playlist metadata editing fits in with the
context view, aside from providing space. The two areas are for
different purposes.

>> 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
>>
>
> OK, so I've committed something that shows that advanced queue
> features are possible without to resorting to a queue manager. 2) is
> now possible by Ctrl+ Right Click on a track or album header. The
> track or album group will then be moved to right below the last
> selected track or the end of the list.
>
> I've chosen to commit this despite not having a consensus since I
> realize the sentiment is "who does the work decides". I seem to be
> able to explain better in code then email anyway.
> Sebr can still present his work and my patch can then be reverted if
> needed. I just want to show the direction I feel we should take.

Well, as I've previously stated a few times, I have a queuing
implementation which is very similar to 1.4 functionality. I think
that this is the best way to proceed, as it is a proven and excellent
queuing system. It really is kickass.

Ultimately, I think it's better to restore proven functionality than
to start from scratch once again trying to figure out what works and
what doesn't.

Seb

-- 
Seb Ruiz

http://www.sebruiz.net/
http://amarok.kde.org/