← Back to team overview

unity-design team mailing list archive

Re: Global menu in Oneiric Ocelot (11.10)

 

But why then does some applications not have a global menu bar? Like
PlayOnLinux when you don't install it from the ubuntu repositories? And will
programs made with Qt also automatically work?

2011/5/19 Ian Santopietro <isantop@xxxxxxxxx>

> 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