-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Luke Benstead wrote on 15/03/11 21:53:
>...
> Erm, I hate to point out the obvious, but why don't we just put the
> menu back in the windows and abandon appmenu as a failed experiment?
> Keep the title and window controls in the panel for maximized windows
> only (at least just for Natty).
>
> I can already imagine the replies to this email, so let me save you
> guys the trouble:
>
> 1. Someone will bring up Fitt's Law. Yes I know what it is. No, I
> don't think it should be used as an overriding reason to squash,
> overlap, and generally complicate a UI and shove it into an edge. I
> especially don't see why Fitt's law is so important for menu bars,
> when users get on perfectly fine with buttons, sliders, window resize
> grips and icons, and well, everything else.
That's looking at it backwards, I think. Screen edges are efficient
target areas for whatever is put there. Given that, what should they be
used for? Menus are used a lot, ergo, they're a good candidate to be
made more efficient.
> 2. Someone will likely bring up the space saving of the global menu.
> Firstly, the global menu only saves vertical space on a maximized
> window, on non-maximized windows they only save on "chrome".
It also saves space whenever two or more windows are stacked vertically.
> By
> keeping the title in the panel for maximized windows, we are still
> saving 22px on Gnome 2, with the removal of the bottom panel that
> brings it up to 44px. It's about finding a balance of space saving vs
> usability and I really think we have shot past that balance point with
> the global menu.
"Space saving vs usability" is a false dichotomy. Space saving reduces
scrolling and memory load, which is part of efficiency, which is part of
usability.
> So, the question again raised is why exactly are we using a global
> menu?
Benefits:
* Much faster to use.
* Saves vertical space.
* Menus no longer need to be cramped by, or overflow beyond, the
window width (e.g. Empathy, Gimp, Inkscape).
* Menus no longer surprisingly open upwards when the window is near
the bottom of the screen.
* Allows the desktop to have the same menus as any other folder
(which, in turn, will reduce the complexity of context menus).
* In future, will allow dialogs to have "Edit", "Help" etc menus
consistent with other windows.
* In future, will allow visual unification of title bars and toolbars.
> I know I've brought it up before, but alongside the issues we are
> having fitting it into the panel with the title, it also brings issues
> with dual monitors, large resolutions and focus-follows-mouse. It
> doesn't fit all use cases.
>...
Dual monitors are not a problem (though if they're stacked vertically,
the bottom one loses its speed benefit). Large screens make the menus a
bit slower, but not nearly as slow as they would be inside windows. The
loss of focus-follows-mouse is a real tradeoff, though. (I've specified
how it could be made compatible, but no-one has been interested enough
to work on it yet.)
- --
mpt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk2B7wIACgkQ6PUxNfU6ecr/hgCfQmwbIB8XbywmWUL6zHOJRAI8
nMkAmwbgxluzK5tYZjwp0HOM9Ssl+xFR
=PTeU
-----END PGP SIGNATURE-----
_______________________________________________
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help : https://help.launchpad.net/ListHelp
