On 4/18/05, Christophe Fergeau <[EMAIL PROTECTED]> wrote: > And what's wrong with doing exactly that, but without removing the songs > as they finish ? (apart from not behaving exactly like the FIFO abstract > data type). This brings us back to a normal playlist...
> Sorry, but either I'm dumb, either you didn't answer my question... > It's easy to give me an answer I like. If you keep the songs, you can > easily reschedule a song you just heard and which was particularly cool. > I just want a similar real world example about an issue caused by not > removing songs (or an advantage we have if we remove songs). So this is getting nowhere... My instinct tells me that a queue is a thing you can put songs, they are played and then they are gone (from that list) and the player changes back to what it was doing before. When I put something in again, it will play the queue again, as long as it contains songs, but when it returns to its previous task, I can be sure that the queue is empty. This is the behavior *I* expect, but I think most people think this way, if I want the songs to sty in the list I do a playlist, which is just that. I cannot say what itunes does in this regard as I don't have access to windows machines or macs but copying that is not the way to go anyway. If having the played songs at hand is really such an issue for a queue, to a "played songs" expander in style of the "show browser" and put the played songs in that list... But then, why don't we have a list for played songs from the library? last played radio stations? If this is to be done, a global history function would be a much better solution because if it's done for the queue, there's absolutely no reason why other sources shouldn't have this also. Naturally this gets harder to implement as we talk... I'm currently happy with how the queue works in merged (fifo, no special tricks). Btw this is currently the "few songs in queue" usecase that was said to be besser solved with that in-sidebar-queue... works pefectly for me. -Michi _______________________________________________ rhythmbox-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
