Not a full UI review, but I happen to have iTunes running in my MOL window at
the moment for comparison, so here's what a more iTunes-like File menu could
look like:

File[1]

   New Playlist                 Ctl-N
   New Automatic Playlist...    Ctl-Shift-N
   ---
   Open Playlist...             Ctl-O           
   Open Song...                 Ctl-Shift-O
   Open Song Folder...          Ctl-Alt-O
   Import CD...                 Ctl-M
   ---
   Add Radio Station...         Ctl-I
   ---
   Save Playlist...             Ctl-S
   Export as CD...              Ctl-Shift-S
   ---
   Properties                   Alt-Enter
   ---
   Quit                         Ctl-Q

Have tweaked some of the wording along the way just for fun... it's by no means
perfect (not sure about "Song" in particular, but that's what iTunes uses), but
I thought the mixture of Add/Import/Opens and Export/Saves might be a bit
confusing.  I also haven't given too much thought to the shortcuts, they're
mostly off the top of my head.

I've removed the separate item for Delete Playlist, because Edit->Delete should
just delete whatever is selected.

I don't see anything significantly wrong with the other menus as they are, to be
honest.

[1] Personally I think "Music" was fine until Internet Radio Stations came along
with their enticing chat-based light entertainment :)  (And I daresay podcasts
might have a role to play soon, too...)

(This isn't to say that splitting out the playlist stuff into its own menu
mightn't work too... that just isn't what iTunes does...)

I was intentionally vague in this bug report.  I wanted to identify a problem
and suggest a possible solution but encourage the Rhythmbox developers to come
to their own conclusions.  iTunes may not have a seperate playlist menu but it
does have a fairly flat menu hierarchy although the file menu is somewhat crowded. 

Any application manipulating files (mp3s are files too) should include a
standard file menu.  Breaking the standard consistent menu layout should need to
be proven to be significantly better to justify the iconsistency.  (As Calum may
recall I attempted to clarify a section of the HIG so it did unintenionally
encourage this inconsistency.  It is an error I want to see corrected in various
Gnome apps or failing that fully justified as better not just different.)

I have taken screenshots of the top level menus in iTunes and intended to post
them today but neglected to bring them with me.  will post them soon I hope.  
I'm still not if the big oval object with the apple logo on it in the middle
actually serves any function beyond branding, iTunes seems to have been designed
with a little more emphasis on form than function. 

I was interested to read an article by the KDE founder 
http://www.icefox.net/articles/kdeosx.php
in particular his comment on how Mac applications usually use a single toolbar
contianing the most frequently used features.  Funny thing is Rhythmbox could
make itself less like iTunes and more compliant with the Mac Interface
Guidelines (and Gnome HIG) by using a standard toolbar widget and having the
controls like shuffle and repeat on there instead of at the bottom in the
non-standard pseudo-statusbar.  a standad toolbar might help improve the small
display feature too.  but this probably belongs in a seperate request.  

I agree that moving the playlist menu items out from their submenu is a good
idea - although I'm unsure whether there should be a "Playlist" top-level menu,
or they should be combined into the File menu.

My main concern with putting them into the File menu is that it might get more
crowded in the future. As Calum mentioned Rhythmbox could gain Podcast support
in the future, and there was a patch posted to the RB mailing list recently
which added a new item to the playlist menu (a item that creates a new playlist,
based on the current browser selections).

As to the name of the menu; I agree that consistancy with other applications is
good, although several of the items don't have anything to do with files. I am
unsure of why the "File" menu tends to be the dumping ground for things that
don't have a menu of their own, especially in applications where not a single
item in the file menu has anything to do with files (*cough* gnome-terminal
*cough*).


A toolbar sounds good, and would help discoverability, as well as moving shuffle
& repeat of of the status bar.

This should definitely be a seperate bug report (I'll go file one), but I'm not
even sure we should have shuffle & repeat buttons at all, because a) who
actually knows the different between shuffle/repeat and shuffle/no-repeat, and
b) I'm not sure of how useful no-shuffle/no-repeat is, because does anyone use
RB to play a playlist once and then stop? Having a better way of select the
play-order would also encourage development of new play-orders (such as the oft
requested IMMS-based play ordering).

I've just searched bugzilla, and bug 163196 (Multiple random algorithms) is
about play-orders. Any furthur discussion of shuffle/repeat buttons is probably
better over there, if any of the usability people want to comment.

Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.

We have a toolbar now.  Calum, any chance you could take another look at this with RB from CVS HEAD and let us know what you think?

Sure, will try and have a look next week.

Has this been resolved so that we can close the bug or do we need further work on this bug?

This has been obsolete by the new design.