Re: [Rhythmbox-devel] Play Queue Bounty

On Mon, Mar 21, 2005 at 05:31:12AM +1100, James Livingston wrote:
> On Sun, 2005-03-20 at 11:19 -0500, Peter Schmidt wrote:
> > Thanks for your interest, James. Hope you are the one to get the $220.
> Like I said, I'm really busy for the next week or two, so if anyone else
> is keen just pipe up.

I'm having a go at it.. I'm just about finished, too.  Mostly UI
weirdness left to sort out, really.  My changes are based on 0.9, but 
it'd be easy to port it all back to 0.8 if needed.

It currently deviates from the original spec in a few places:

- the queue acts more like the source list panel than the browser panel.
  There's a menu item (and key combination) that toggles its visibility.
  I found having the show queue/hide queue widget wasted too much space.
  I'm still experimenting with different layouts, though.
- you can add selected tracks to the queue by hitting ctrl-T, rather
  than ctrl-enter (gtk_accelerator_parse knows nothing about this
  mythical 'enter' key, it seems)
- dragging songs out of the queue sort of works, at the expense of
  making all drag and drop operations from playlists move rather than
  copy songs (which I've always sort of wanted anyway, but that's
  neither here nor there).  Drag and drop to the library seems to be
  broken in 0.9, but I imagine that if this was fixed, songs could be
  removed from the queue as specified.  I plan to investigate, but it's
  fairly low priority (mostly because I hate working with drag and drop

- songs are removed from the queue once they've finished, not as they

- the queue length is shown in the status bar when the queue is not empty

- haven't done the expand on first entry / collapse on last bit as it
  doesn't really fit in

The spec didn't mention whether the queue should survive restarts, but
I basically got that for free, as the queue is just a playlist that gets 
treated a bit differently.

> > Also, I'm not really sure if the queue panel should be above the track
> > list or below it. Any reasoning why either position is better?
> Well you'd be grouping the expandable bits together. This might be a
> good thing, keeping similarly looking UI elements together, but could
> also be bad, because they have two orthogonal functions. If it was at
> the bottom it would also be more symmetrical, which from 5 seconds
> though would seem to be more aesthetically pleasing, but could very well
> be wrong.

The problem I'm having is in making a clear distinction between the
queue and the visible library/playlist view without scribbling a huge
"THIS IS THE QUEUE" label over it, which is ugly, wastes space, and
just annoys people who have already figured out the difference.

I've currently got a simple label there, but it doesn't look terribly

I don't need to take a screenshot with the queue hidden, because you
can already see what that looks like.

Arch repository will follow once I convince myself that the remaining
weirdness is existing 0.9 breakage rather than anything I've done


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