On 2009/05/26 13:21, Matt Wheeler <m...@funkyhat.org> wrote:
> I'm not sure I understand, a queue has a lot of similarities to a
> playlist, so surely re-using playlist code would result in less
> duplication of code than a separate solution (although that may mean
> the current playlist code would need generalising a little).
A while ago, a queue patch was merged into subversion, but was removed
when the former MPD lead developer found the code too ugly. It sure
was awful, and I'm grateful it was already gone when I took over.
Now if we generalize the playlist code, we can expose that generic
solution to the clients, instead of providing one single very special
feature like the "queue".
> The idea of queueing/nesting playlists is interesting, I hadn't
> thought of that, but restricting a queue to this format means the
> use case of "playing library on shuffle, but now I want to add a
> song to a queue to be played next" is not satisfied (unless I'm
> missing something), without "remove all other songs from current
> sub-playlist, add song I want to next sub-playlist, add library
> again to sub-playlist after next" which just feels awkward.
Create sub-playlist with "queued songs" ("consume mode" enabled),
insert it before the "shuffled playlist", move "current song" before
"queued songs". Agree, this is a complex operation, but it's only as
complex as the user's wish.
> That is what I meant, if the queue is implemented just as a special
> playlist, then old unmaintained clients will continue to work, and
> support the queue, the client doesn't need to know it is special
> (nested playlists may break old clients as well, but users aren't
> forced to nest playlists anyway).
With nested/chained playlists, you could serve only the current/first
"sub-playlist" to clients calling "old-style" playlist manipulation
commands. Only clients which speak "new-style" commands would see the
big picture.
Max
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com
_______________________________________________
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
