The reasoning for the global menu bar isn't just about saving screen space. It's also about reduction of UI chrome to provide an interface that looks cleaner and simpler. Mouse travel distance *is* irrelevant since mouse acceleration allows for great travel distances from short, twitchy movements. It is also easy to hit the menu, as it's on a screen edge and easy to hit vertically. I work with a *trackpad* on a very large monitor, and of all if the pointing issues I have, the only serious one is when I need to aim in two dimensions.
This brings to the real flaw with the global menu. As it's hidden by default, users don't know what to aim at, thus forcing them to stop and re-aim at the menu they want to use. This is the real speed killer with the current global menu implementation. A better solution would be to have the global menu visible by default.
In the current implementation, there is a way to disable the global menu. This should be easier to configure for users that don't want the global menu. Also, I think adding an option to keep the current behavior would be good, as I'm sure some people like the lack of visual clutter it provides.
On May 18, 2011 2:54 PM, "Niklas Rosenqvist" <
niklas.s.rosenqvist@xxxxxxxxx> wrote:
> Sorry people for accidentally sending duplicates, here is the real version:
>
> 2011/5/18 Bazon <
bazonbloch@xxxxxxxx>
>> i could also imagine a window grip button
>> for moving the window when the whole title bar is occupied by menus for
>> moving the window.
>
> Without testing I just get the feeling that this would be ineffective since
> I know that I much more often move a window than go to it's menu. A small
> grip will probably be annoying to always find with your cursor. The whole
> title bar provides a much easier and faster way of rearranging windows.
>
> I made some sketching on this and came up with a mockup which you can find
> here:
>
http://i.imgur.com/f8q2c.png
>
> The three top images is describing the solution we've talked about and the
> fourth image is an extension of the implementation we've discussed. This
> implementation is possible today thanks to a plugin, but it would be sweet
> to have it natively.
>
> 2011/5/18 Niklas Rosenqvist <
niklas.s.rosenqvist@xxxxxxxxx>
>
>> 2011/5/18 Bazon <
bazonbloch@xxxxxxxx>
>> > i could also imagine a window grip button
>> > for moving the window when the whole title bar is occupied by menus for
>> > moving the window.
>>
>> Without testing I just get the feeling that this would be ineffective since
>> I know that I much more often move a window than go to it's menu. A small
>> grip will probably be annoying to always find with your cursor. The whole
>> title bar provides a much easier and faster way of rearranging windows.
>>
>> I made some sketching on this and came up with a mockup which you can find
>> here:
>>
http://i.imgur.com/f8q2c.png>>
>> The three top images is describing the solution we've talked about and the
>> fourth image is an extension of the implementation we've discussed. This
>> implementation is possible today thanks to a plugin, but it would be sweet
>> to have it natively.
>>
>> 2011/5/18 Bazon <
bazonbloch@xxxxxxxx>
>>
>>> Am Mittwoch, den 18.05.2011, 15:15 +0200 schrieb Niklas Rosenqvist:
>>> > Or to avoid movement, switch between titles and menus in the
>>> > titlebars.
>>>
>>> I like that idea:
>>> Consistent (menu/title toggle as for maximized window now, than simply
>>> for all windows)
>>> and contextual (it's clear where every menu belongs to).
>>>
>>>
>>>
>>> Additionally to the before mentioned idea of a menu/title toggle button
>>> next to the window controls, i could also imagine a window grip button
>>> for moving the window when the whole title bar is occupied by menus for
>>> moving the window.
>>>
>>>
>>
>>
