Re: [Rhythmbox-devel] Interface ideas

> The point of the queue is to be a simple FIFO list. Say I'm listening to
> a playlist, and decide I want to hear songs X and Y next. I add them to
> the queu. After whatever song was playing finishes, X is played and
> removed from the queue, same with Y, and then rhythmbox resumes playing
> from the playlist/library/whatever source it was on. 

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).
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).
Actually, if you are space constrained (ie if you have the play queue
shown at the same time as the library), removing songs may make sense to
save precious screen estate, but if it's a separate source, I guess it's
ok to keep all the songs (to provide some kind of "play history").


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]