← Back to team overview

unity-design team mailing list archive

Re: Global menu in Oneiric Ocelot (11.10)

 

Developers can choose to implement the Unity API for adding things to their
launcher item, such as progress bars and quicklists. However, the global
menu is done via gtk and dbus, and requires no effort on the part of the
developer, provided the developer has implemented a standard gtk menu
system.
On May 19, 2011 2:37 AM, "Niklas Rosenqvist" <niklas.s.rosenqvist@xxxxxxxxx>
wrote:
> Yes but this still would leave it up to the developers to make their
> programs Unity compatible and isn't that too much to ask from them? Can't
a
> simpler implementation be found which doesn't need any changes in the
> applications so that people doesn't need to make their programs Ubuntu
> compatible and not just Debian?
>
> 2011/5/19 Ian Santopietro <isantop@xxxxxxxxx>
>
>> 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.
>> >>>
>> >>>
>> >>
>> >>
>>

Follow ups

References