Re: [Rhythmbox-devel] Rhythmbox gnome 3 mockup

[Calvin Walton <calvin walton gmail com>]

On Tue, 2010-12-28 at 18:05 -0500, Sean McNamara wrote:
> On Tue, Dec 28, 2010 at 1:24 PM, Hillar Liiv <liivhillar gmail com> wrote:
> > Hello!
> >
> > I have some made gnome 3 mockup for rhythmbox:
> > http://ubuntuone.com/p/Vgn/
> > http://ubuntuone.com/p/Vgp/
> >
> > I used elements from:
> > http://gitorious.org/gnome-design/gnome-design/trees/master/mockups
> >
> > Any suggestions? Is there any way to make rhythmbox look like this?
> 
> 1. Is there any way you can re-do these mockups using the Clearlooks
> GTK engine? The point would be to reinforce the idea that we are going
> to use system-provided widget styles. Cleanlooks engine provides us
> with the "stock" look and feel (which you find, for example, in RHEL,
> Fedora, and the Devhelp GTK+ guides) to remind us that all the
> controls are actually drawn by the installed engine, not custom drawn
> by our own code. We probably don't want to get into our own custom
> drawing code, because such code is difficult to maintain, and the more
> we have of it, the less the UI looks well-integrated into the rest of
> the user's desktop. The built-in system GTK engine is there to provide
> a uniform look and feel across all GNOME applications.

This is actually part of the point of this mockup – the mockup is drawn
using what will become the default Gtk+ theme for the GNOME-3 release.
Its working name is “Adwaita” if I remember correctly, and it can
already be used on live Gtk+-3 applications if you use jhbuild or so.

> 3. I notice that the shuffle icon is also a combo box (drop-down). How
> exactly does this work? Is it one of those things where clicking on
> the leftmost part of the button toggles shuffle, while left-clicking
> on the right edge pops up a combobox menu with (presumably) one item
> -- the repeat toggle button? This seems kind of weird; if we had
> several different options to toggle, it might be worthwhile, but
> making the user learn this UI pattern for one extra button is not
> really worth it. This is especially true considering that you have so
> much unused space in the toolbar: you could still fit it on a netbook
> if you collapsed all the empty space between the seek slider and the
> playlist summary ("2 songs, 7 minutes, 8 MB").

The thing is, we do actually have several different items to toggle
through, and many of them aren't currently exposed. There’s at least
linear, linear-loop, shuffle, random-equal-weights, random-by-age,
random-by-rating, random-by-age-and-rating. Only linear, linear-loop,
shuffle, and random-by-age-and-rating can be selected using the shuffle
and repeat buttons in the current UI.

> 4. I like the idea of putting stuff into the window titlebar where the
> native decorations go. This is something that Google Chrome has done
> for a while, and does it well; other browsers like Opera and Firefox 4
> are starting to follow suit. It seems like you have some widgets
> overlapping the horizontal space with the max/min/close buttons,
> suggesting that we would have to override the native window
> decorations.
> 
> This is an interesting problem. On the one hand, this places the onus
> on the application to draw the max/min/close buttons. We could either
> "try" and get the native max/min/close buttons rendered exactly right
> on our own; or we could develop a generic set of them and ship them by
> default, like Chrome does. The problem with that is it reduces
> platform integration and uniformity by having our own custom
> max/min/close buttons that may not resemble those from the native
> window manager.

There’s an experimental Gtk+ branch working on shared support for this,
but I wouldn’t expect it to be ready any time soon, and I wouldn’t build
a UI based on it quite yet :)

> 5. If you look at how we display the currently-playing track in the
> traditional UI, we kind of cram it directly above the seek slider.
> This is cool: it doesn't add a lot of width to the toolbar, but it
> gives you basically a full stripe across the horizontal of the UI to
> list a very long album name / artist / track name combo. Would be nice
> to replicate this in your mock-up while retaining most of the other
> changes. If you collapse the menus into the title bar as discussed in
> item 4, you'll have the same amount of vertical headroom as before for
> the playlist (unless you use that really big font for the track name
> like your mock-up shows).

One of the main points of the current UI is that you can get a seek bar
which is the full width of the window; that’s something that it would be
nice to keep, although it does cost quite a bit of vertical real-estate.

-- 
Calvin Walton <calvin walton gmail com>