Re: A few comments regarding Gnome-shell

On Mon, Mar 7, 2011 at 12:29 PM, Robert Park <rbpark exolucere ca> wrote:
> On Mon, Mar 7, 2011 at 5:29 AM, Juergen Mangler
> <juergen mangler univie ac at> 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:
> 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 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.

> --
> _______________________________________________
> gnome-shell-list mailing list
> gnome-shell-list gnome org

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