unity-design team mailing list archive

[Niklas Rosenqvist <niklas.s.rosenqvist@xxxxxxxxx>]

 2011/5/18 Henrik Peytz <henrik.peytz@xxxxxxxxx>
> [...] and dragging the window will be problematic if the menus span the
entirety of the window due to menu-overflow or resizing the window too
small.

Agreed, it was the first thing I thought about when I read the suggestion.

> Or have a menu-toggle-button next to the other window-controls (close,
maximize etc.) so the user can decide on a per-window-basis whether he wants
the menus visible or not.

This on the other hand was highly interesting. This together with the title
and menu merging with the top panel when an application is maximized would
probably solve the most problems. Consider when you use nautilus, I at least
never uses the menu since I only use it for browsing and lots of menu
entries have keyboard shortcuts. But when you use a program like GIMP you
always want to be able to reach the menu. If the setting is saved per
application this could work really good. It would also leave it up to the
developers how they want to design their menus, because when your not moving
the menu up to the top panel you can choose to create menu buttons as Opera
and Firefox 4 features. This would leave much more freedom to the
developers.

Or as an alternative can menu buttons ala Opera (can't call it firefox style
since Opera actually was first with it) get created automatically and be an
entry in the title bar. But what would cause other problems, e.g. the
developers actually creating their own menu button and in that case it could
get confusing.

2011/5/18 Thorsten Wilms <t_w_@xxxxxxxxxx>
>  Actually it's the several non-maximized windows case where a global menu
shines regarding space efficiency, as you don't save only one menu bar area,
but several.

This is of course true but that leads us to the question whether it's more
important to have an efficient workflow or save 24px vertical space? For
myself is the ease of access a higher priority, since an ineffective work
flow will get you frustrated and slow down your effective work time.


2011/5/18 Henrik Peytz <henrik.peytz@xxxxxxxxx>

> Or have a menu-toggle-button next to the other window-controls (close,
> maximize etc.) so the user can decide on a per-window-basis whether he wants
> the menus visible or not.
> I think auto-hiding menus would be bad since it's possible for a user to
> want to retain an overview of available menus, even if that particular
> application is not in focus. This is particularly true when learning a new
> application and the user doesn't remember all the options available to him.
>
> Moving the menu to the titlebar is also a solution, though people will
> probably complain a about the clutter, and dragging the window will be
> problematic if the menus span the entirety of the window due to
> menu-overflow or resizing the window too small.
>
>
> 2011/5/18 Thorsten Wilms <t_w_@xxxxxxxxxx>
>
>>
>> Actually it's the several non-maximized windows case where a global menu
>> shines regarding space efficiency, as you don't save only one menu bar area,
>> but several.
>>
>>
>> It would be an interesting _experiment_ to render non-maximized windows
>> sans menus, and have the menu slide in inside a window, once it gets and for
>> as long as it has focus. Or to avoid movement, switch between titles and
>> menus in the titlebars.
>>
>>
>> --
>> Thorsten Wilms
>>
>> thorwil's design for free software:
>> http://thorwil.wordpress.com/
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~ayatana
>> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~ayatana
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>