Re: [Rhythmbox-devel] rhythmbox interface

> I kinda like the current design. Here's a few notes about it.

This e-mail got me thinking, and i realised that i hadn't really
bothered to try out groups extensively. So , in a semi-comatose state i
decided to make a playlist, and it was remarkably easy. And once I had a
playlist make it was actually really great to be able to go to another
view. I could focus on my playlist and not be distracted by the ui for
the library.

So I started thinking: what do groups need?

* maybe /s/Group/Playlist /s/Groups/Playlists
* Make groups re-orderable
* Save groups while program is running - either after each change or at
reqular intervals if anything has changed

Other than that groups are a really good way to make playlists - drag
and drop takes a bit of getting used to. But as rhythmbox is now it is a
LOT better than winamp and mmjb and "the other other media player".

And how can we "play a song after the current one"?
* Add Toolbar Button: "Queue"
* Add 'Music->Clear Queue' menu item
* Add context-menu items:
	Add to Queue
	[Remove from Queue]
* Add a way to view the queue, posibilities:
	- A seporate window
	- A box integrated into the library view
	- A meta-group on the sidebar (this is my favourite and i've 					been
suggesting it for weeks ;) )
	- Use the leftmost column in the song view to indicate a songs
	position in the queue and to toggle it's inclusion in the queue.

Other notes 

- only one item on the menu changes when switching from hte library to a
group - to me this is ok
- oliver wants to add a browser to groups - this would make groups even
more powerfull as it would be possible to make groups that are large
subsets of the library - i'm not sure if this is a good thing or a bad
thing. at least it should definatly be off by default.
- we already have a sepporate audiocd player - it would be much better
to have this functionality integrated into rhythmbox
- a sepporate iradio application would be really sucky :(
- ripping should NOT be dont through nautilus - ripping and burning
integrated into file managers is simply wrong - you need a different
interface for ripping and burning than you do for file management.

		 .--= [ MArk Finlay - sisob ] =--.

	   [ My Weblog: ]
        [ Gnome User's Board : ]
     [ Want to be a Hacker?: ]

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