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