Reposting to the list as I just replied to Max, sorry.

2009/5/26 Max Kellermann <m...@duempel.org>:

[snip]

We had this idea and feature request over and over, and we will NOT
have a "second" playlist.  This idea is complex and cumbersome,
because it requires to duplicate a lot of code inside MPD.

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

We will have a generic approach, which makes the "queue" a special
case.  It will be something like a "chained list of playlist" or
"nested playlists".  I hoped we could bring it into 0.15, but it
turned out the playlist code was so complex, I got lost during code
cleanup and never finished it.  I will continue work on that after the
final 0.15 release.

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.

If you want to help, have a look at src/playlist.c, src/queue.c and
the other related source files.  Try to judge where you can simplify
and generalize code.  Post your ideas and patches on this mailing
list, so we can discuss them.

Thanks, I'd already had a quick look at queue.c and playlist.c, I'll look in 
more detail.

I think it is quite important not to break older clients.  Sometimes,
that is hard to do.  There's a lot of unmaintained but well working
MPD client code floating around, and we should keep it this way.

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

Thanks

--
Matt Wheeler
m...@funkyhat.org

Attachment: signature.asc
Description: OpenPGP digital signature

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

Reply via email to