Queue support and The Playlist

[Jeff Mitchell]

Bart Cerneels wrote:
> OK, micro adjustments to the play order is the intended use case. Got it.

Yes...to echo everyone else, this is how I use it...and to echo (I
think) illogical, this is one of the things that makes Amarok rok and
iTunes (and co.) suck.  It's extremely useful.

Queueing that is.  I don't know if I ever even opened up the manager,
except if I had for some reason queued up 9 tracks and wanted to flip #3
and #7.  In which case it could actually be very useful.  But a way
around this, without requiring such a manager, is to allow (maybe in the
right-click menu) a way to move a queued track to a specified position
in 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.

Actually, metadata editing is one of the main use cases for an
alternate, spreadsheet, Amarok 1.4-style view for the Playlist, and
several of are interested in implementing it for 2.1.  A simple toggle
that swaps to the spreadsheet view and extends it over the CV, with all
(commonly edited) fields accessible for easy one-click metadata editing,
would be a fine addition to our capabilities and keep people from having
to right-click on each track, hit the button to edit track information,
fill it in, hit OK, and so on.

I don't really see how it'd fit as a plasmoid, if nothing else because
of the horizontal space requirements.  I think doing this editing would
require at least extending the playlist (temporarily) across the CV, if
not across the entire app.

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

I'm not sure the concepts are the issue.  Maybe with the concept of the
queue manager, which probably can be done away with by incorporating a
tiny bit more functionality into queued tracks, but I don't really see
the issue with the queue concept in a general sense.

--Jeff