On Mon, 2005-09-19 at 20:32 -0400, Charles Schmidt wrote: <having the queue both as a source and in the main UI> > I'm not sure what the impl is like, or if the whole "previously played > songs" bit (ala iTunes Party Shuffle) has been discussed, but if thats a > feature, then the queueview could show the last played song in a dimmer > font or whatever, and then the currently being played & to be played > below that. The sourceview could show the previous 5 songs or whatever. > > Having just thought of this whole idea, I really like it, however do see > a few immediate pitfalls: > > Potentially confusing. I'm not sure that having two ways of simultaneously accessing the queue is a good idea. It would be very confusing to have both visible at once, if you had the main-UI queue visible while viewing the queue source. > Still clutters the UI. If you don't want the in-main-UI queue, you can turn it off via View->Hide Queue. One thing that hasn't really been discussed much, is that we don't have to use the same mechanism to handle both use cases. We could use the queue to handle the "queue up a few songs" use case and something else for the "lots of songs at a party" use case. In particular I'm thinking of amaroK's "Dynamic Playlists" - we could make the "Show Browser" widget "Show Options" for normal playlists, with the following: * A "remove played tracks" checkbox * A spinner to enter the minimum number of tracks that the playlist should contain * Some widget to select which other source to use for filling * Some widget to select how it chooses the tracks from the above source (probably using play orders) When first created a playlist would have the options set so that it acts as a normal playlist (i.e. don't remove tracks, no minimum). Comments? Cheers, James "Doc" Livingston -- Unix cluedo: Was it "kernel panic with the named piped in the linked library"?
Attachment:
signature.asc
Description: This is a digitally signed message part