Re: [Rhythmbox-devel] status

[Gisli Ottarsson <gisli ottarsson mscsoftware com>]

This special playlist smells a lot like the Queue idea I was peddling a
few weeks ago.  See item 1) in this posting.

http://mail.gnome.org/archives/rhythmbox-devel/2003-September/msg00067.html

Many ideas for how this might be implemented were floated in the ensuing
thread.

I still think that one of the ways to handle this might be to make the
area occupied by the Source pane modal like Evolution's side-bar. 
Start Evolution and imagine that its Shortcuts are Rhythmbox's Source. 
Then right-mouse in the Shortcut area and select Add Group.  Name this
group Queue.   

Songs would be added to the play play-queue by dragging into the Queue
area.  No buttons would be needed.  If there are songs in the Queue,
the top one is played next.  If the Queue is empty, Rhythmbox works as
it does today.  Once played, a song is deleted from the Queue.

The user scenario I have described is a party.  Guests looking at
Rhythmbox can see which songs are coming up, re-arrange their order,
add their wishes, remove songs they hate, etc.   Everybody is a DJ.

I think the only interface problem with the queue idea is that it
conflicts with the Shuffle selection at the bottom of the interface.
What does it mean if there is a Queue and Shuffle is selected?  Perhaps
it means that rather than FIFO, Rhythmbox treats the Queue as a pot to
make a random selection from, but once played, the song is removed.
Perhaps all we need to do is find a better name than Queue. "Currently
Playing" is not bad although "Coming Up" might be better.

Gisli





On Mon, 2003-10-06 at 20:32, Mike Rhodes wrote:
> Hi,
> 
> Colin Walters wrote:
> 
> > 
> > 
> >>Another idea I would put forward is to have a special playlist called 
> >>Currently Playing which allows you to build up a quick playlist without 
> >>having to create a permanent playlist. Say I just feel stressed and want 
> >>a quick chillout I just search for a few bands and then hit an Enqueue 
> >>button and they get placed in the Curently Playing list. Like a scratch 
> >>pad for playlists. Just makes it a little quicker to start listening!
> > 
> > 
> > I would like something like this too.  The question is exactly what form
> > the UI would take.  I don't know where we'd put another button, and even
> > if we had room it would kind of feel like a kludge.  
> > 
> > Maybe we will need to go to a multi-toplevel-window paradigm, so you can
> > just drag and drop.  But that brings with it its own complications...
> > 
> 
> Currently, there are Shuffle and Repeat check boxes at the bottom of the 
> screen. Maybe Play/Enqueue [selection] and Play All/Enqueue All buttons 
> could go along side these, lined up with the files box? That would imply 
> their connection with the files currently in the window.
> 
> I'm not sure quite how you could also imply their connection with a 
> "Currently Playing" list though. However, I don't think it would take 
> long for a user to work this out. Perhaps mention it in a tooltip. 
> Though how often tooltips are read, I don't know.
> 
> You could make the Currently Playing list look special by laying out the 
> left hand list like this
> 
> +----------------------+
> | Library              |
> | Radio Stations       |
> | -------------------- |
> | Currently Playing    |
> | -------------------- |
> | [User's other lists] |
> | ...                  |
> | ...                  |
> | ...                  |
> +----------------------+
> 
> The currently playing would list anything that is playing, eg radio, 
> user's own playlist as well as the 'off-the-cuff' list from the user 
> just picking a few tracks at random. This would reinforce the Currently 
> Playing idea.
> 
> > 
> >>Much of the music in my library is stored on network PCs that go on and 
> >>off etc. quite often. As it stands, the refresh process stalls when it 
> >>tries to refresh these folders (mounted via samba). I guess this is done 
> >>differently in the new version as it seems to have a different 
> >>architecture. 
> > 
> > 
> > Well, currently it doesn't do any refreshing at all :)
> > But once it does, it will probably be much like the previous way.  How
> > do you think we could improve this?
> 
> Does Rhythmbox build a new database of songs when it is started from a 
> list of the folders in the current database, go through the database 
> pruning dead songs or some other method?
> 
> I would suggest the following method on startup and perhaps when a user 
> manually chooses to refresh the database:
> 
> 1. List source folders in database currently (I don't know if Rhythmbox 
> stores the source folders for files or not)
> 2. Check each folder exists. If a folder exists, check it for new songs, 
> prune dead songs.
> 3. If the folder doesn't exist, don't do anything. It may be a network 
> share that isn't available, in which case just skip songs from it when 
> you come to it.
> 
> Also an option to remove a source folder could be provided for folders 
> that a user moves or deletes?
> 
> Finally I would provide an option to stop the auto-regen of the database 
> at startup as it could be quite a network hog (I have around 4,000 songs 
> pulled from the network in my db currently).
> 
> > 
> > 
> >>Also when a music file on a non-existant share plays, 
> >>there is an error message which halts playing of other music. A silent 
> >>failure mode here would be good, which just skips the file and plays the 
> >>next.
> > 
> > 
> > Yeah, a few people have requested that.  It shouldn't be too hard at all
> > to make rb_error_dialog_nonmodal and use that in error_cb in
> > rb-shell-player.c.
> > 
> 
> I might even not have a dialog at all. What happens if you leave your 
> music playing all night and then come back in the morning to find a 
> hundred "Missing file" dialogs about the screen?
> 
> A few thoughts...
-- 
Gisli Ottarsson <gisli.ottarsson@mscsoftware.com>
MSC.Software