On Mon, Mar 7, 2011 at 12:29 PM, Robert Park <[email protected]> wrote: > On Mon, Mar 7, 2011 at 5:29 AM, Juergen Mangler > <[email protected]> wrote: >> On 03/07/2011 11:43 AM, David Prieto wrote: >>> Hi Jürgen, >>> >>> I do not comprehend the advantages of the menu on top approach >>> (apple approach). With high resolution, big screens and several (not >>> maximised) windows, the distance i have to move the mouse grows much >>> higher. >>> >>> My experience with top-panel menus has been that yes, they're farther >>> away but no, they're not more difficult to reach because I could "throw" >>> the cursor to the top of the screen and be sure it would land on the menu. >> >> Okay, i buy this one. > > David is describing Fitt's Law: > > http://en.wikipedia.org/wiki/Fitts%27s_law#Success_and_implications > > The disadvantage of the MacOS approach here is that it renders > focus-follows-mouse worse than useless (as it becomes impossible to > access the application menu if there are any other windows in between > that window and the top of the screen, which would be common for any > non-maximized window). > > On a side note, I was recently annoyed when I tried out v0.0.6 of the > GNOME ISO (from gnome3.org) and I was not able to activate the clock > menu by clicking on the topmost row of pixels above the clock applet, > I had to move the mouse down in order to click. That's a failure to > implement Fitts Law.
That was a Clutter bug that's been fixed. >>> As for the advantages, I think it would go well with Gnome3's efforts to >>> remove clutter and distractions, by hiding every menubar except for the >>> one from the active window. Seriously, I can't recall ever having wanted >>> to open the menubar of an inactive window, partly because in most cases >>> they're half-hidden anyway and you need to raise the window first, so >>> why not go all the way and hide them entirely? >> >> Gnome-shell has some tiling features built in *, and when the windows are >> side by side its two clicks vs. one. Of course it can be weighted against >> additional clutter on the screen. I like having everything in one place (the >> window). But maybe thats old-fashioned. > > I'm a HUGE fan of how GNOME3 has implemented tiling. It's so smooth, > and the UI for it is so deliciously consistent with how maximization > now works. I've been pondering the implications of widescreen monitors > for a while now, and it frequently occurs to me that vertical space is > incredibly precious, while horizontal space is so ample that I can't > even think of ways to use it all up. It's easier to read text when > it's in narrow columns, so it makes sense for UIs to allow windows to > be arranged into columns (and indeed, I already have configured my > mail client to have columns for the inbox and message view, rather > than the more traditional inbox above message view below), and similar > for my RSS client, etc. > >> Regarding unity: i confess i like that in unity the titlebar is integrated >> with top panel when windows are maximized. So I think removing the close >> button from windows altogether (as others have done), and maybe moving it to >> the top panel (not only context menu of activity, but explicit) is at least >> worth a try. > > Yeah. I'm absolutely in favor of anything that can reduce the usage of > vertical space. On my netbook right now (screen size 1024x600), I > actually have a very wide gnome panel along the left edge with various > launchers, and then the panel across the top (with a clock and > notification area) is actually set to autohide because I just can't > spare a single pixel of vertical space. > > What if titlebars occupied the left edge of the window instead of the > top edge? Rotate the text 90 degrees. It's only slightly less > readable, but it would save a LOT of space for people with wide > screens. I think someone tried something similar in gnome-panel when you have the panel on the side. It's not readable at all. A minor gain of vertical space is not more productive than readable text. > -- > http://exolucere.ca > _______________________________________________ > gnome-shell-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-shell-list > _______________________________________________ gnome-shell-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-shell-list
