Queue support and The Playlist

[Bart Cerneels]

On Tue, Dec 16, 2008 at 11:05 PM, Seb Ruiz <ruiz at kde.org> wrote:
> 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.
>

OK, so you want to change the order of playback without affecting the
order in the view. I think this is the root of the confusion.
We might need the input of leinir, Celeste or Ellen here (see how I
avoided the U word.).

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

I do get a feeling though, from various comments on blogs, stories and
bug reports that users do in fact struggle with these concepts since
they are in the same view.

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

OK, micro adjustments to the play order is the intended use case. Got it.

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

I don't really mean metadata editing is the main use case of a
playlist plasmoid but it can be used for that.

The reason it should be in the context area is because it can interact
with browsers and The Playlist that way. Certainly for drag & dropping
tracks from the collection into a Meta::Playlist, since the browsers
share the same space.

>
>>> 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.
>
It's not the functionality that is the problem, it's the concepts it's
build on. Now is the time to think about concepts right?

Bart