Re: [Rhythmbox-devel] User Interface proposals

On 01/22/2012 01:33 PM, Sean McNamara wrote:
1. Need to know size of library before I attempt to transfer songs
to an mp3 player (or mobile device with limited space), so I can
figure out if I need to recompress songs to a lower bitrate or remove
songs entirely, etc 2. Number of songs is a useful metric for me as a
DJ because it helps me communicate with other DJs how diverse my
collection is. Sure I could write a shell script to gather the same
info, but _why_ should I have to when this excellent functionality is
already there?
Thanks for those! Did not think about them.

On the other hand, if you remove the status bar but maintain the
information that is displayed in it somewhere else in the Rhythmbox
UI, that's fine with me. I guess I should clarify my viewpoint: I
don't care that the information *is in the status bar*; I care that
it is easily accessible *somewhere within Rhythmbox*. If you want to
remove the status bar but maintain the information (in the same
textual format it's in now) elsewhere, I'd almost agree with that
without even looking at the new location where you're going to place
it. I've come to rely on Rhythmbox for this information, and I'd
really like to see a shift in GNOME, away from the philosophy of
flat-out culling features for the sake of simplicity, and toward
cleverly obscuring or hiding the least-used features so that power
users accustomed to complexity (*raises hand*) can still use rich
feature sets, while non-power-users won't be overwhelmed by the
default behavior.
Took note of this and incorporated it (and more) into the wiki:


On 01/22/2012 05:03 PM, Sriram Ramkrishna wrote:
Thank you for doing this.  It's a very nice detailed analysis and I
appreciate it.

A couple of things: 1)  It would be best to get Jonathan's take on
the UI.  Without the maintainer involved it will be hard to get a lot
of the changes.  I would prefer to see understand where RB is going
to go from his perspective as is proper.  He may or may not have a
roadmap on the UI.
I'd be glad to discuss this with Jonathan and collaborate to incorporate
his plans. Also, I'll hang out on #rhythmbox, feel free to ping me.

2) Secondly, UI design should go through #gnome-design on IRC if we
want to make it into a proper GNOME 3 app that fits with the GNOME 3
I'm pinging #gnome-design about this proposal right now.

Also check the which has
some designs already on a music player.
I'm not sure it's a good idea to include the "polish" changes I'm
proposing in the long-term roadmap of the Music app. Music looks
exciting as hell, but it's a looong way. I'd rather see the small
changes discussed here implemented in the current RB, one incremental
change at a time. This is why I separated my proposals in the wiki, so
that they can be filed as individual bugs, and worked on individually.


On 01/22/2012 07:29 PM, Michael Gratton wrote:
3. Determining the play length of an album/playlist. I am rather
old-school in that I prefer to listen to whole albums or EPs, in
their entirety. I never listen to individual tracks. Knowing how long
a disc will play for can therefore be a useful aid in selecting what
to listen to[1].
Since a collection of music on a disc isn't a concrete concept in RB,
it doesn't do things like display or allow one to sort on disc
length. The status bar is currently the only way to determine that. I
believe this also applies to play lists, and hence is important in
constructing them.
Of course, if RB would display album length elsewhere, say in the
browser, I'd be happy for the status bar to go away.
OK, took note of this too in the wiki. Thanks.


On 01/23/2012 10:32 AM, Olaf Hering wrote:
Convert an audio CD to FLAC format. There is now this rather
uninformative progress bar instead of what was shown in 0.13.3.
Showing whats really going on like '#4/#13 (42%)' would be really
Indeed, thanks for the use case. Regarding the functional regression
("RB 2.95 no longer reports detailed progression of extractions", I
encourage you to file a bug.)


So let's see what's the take of #gnome-design team, and I hope Jonathan will jump in when he has a moment.

Thanks everybody for the feedback!


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