Hi, I'm aware of Jonathan's response, but I'm neither going to agree nor disagree directly with him here; I just want to provide some additional feedback. (Disclaimer: I am a developer, but not maintainer of RB.)
Also, the original links in your mail seem to work fine for me; no HTTP/503 here. On Tue, Dec 28, 2010 at 1:24 PM, Hillar Liiv <liivhil...@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. 2. The movable toolbar is ok, but personally, having it on the bottom of the screen is really distracting to me. It seems like it doesn't belong there at all. In fact, I didn't notice it in the `Vgn' image at all for quite some time, despite staring at it several times. I'm worried that a user will inadvertently tap right-click / left-click, change the position of the toolbar, and complain that they don't know how to get it back to where it was. We don't currently support changing the location of the toolbar; in fact, our UI is not very user-customizable at all, except for resizing a few of the separate areas. Extremely customizable media players (e.g. Winamp, for lack of a better FOSS example) have the limitation of increased code complexity, and increased risk of user confusion if they do something inadvertently changing around the UI. 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"). 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. The benefits of this are significant, though. The title bar usually contains a lot of wasted space, and this is a significant proportion of the vertical real estate on a small screen (e.g. netbooks). In an effort not to waste this space, web browsers pioneering the concept of "widgets where the tittlebar used to be" have tended to put an application-wide main menu of some sorts in the top left corner, either with a single button, or just the standard menubar. Chrome puts its tabs in this space, but obviously we don't have that concept in RB. The only other elements that should go in the titlebar space should be the application title ("Music Player" or "Rhythmbox") and the min/max/close buttons. 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). Also, what program are you using to create these mock-ups? I might play around with it and pump out some of my own. Of course I could use Glade/GtkBuilder Designer and do it that way... All in all, an interesting experiment! Thanks, Sean > > Hillar > > _______________________________________________ > rhythmbox-devel mailing list > rhythmbox-devel@gnome.org > http://mail.gnome.org/mailman/listinfo/rhythmbox-devel > > _______________________________________________ rhythmbox-devel mailing list rhythmbox-devel@gnome.org http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
