unity-design team mailing list archive

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

 2011/5/19 Florian Diesch <diesch@xxxxxxxxxxxxx>
> It's about impossible to use "focus follows mouse" and multiple windows
> with the global menu, which makes it unusable for me.

This is a great example for when the global menu isn't such a great idea as
everyone thought before Natty.

2011/5/19 Niklas Rosenqvist <niklas.s.rosenqvist@xxxxxxxxx>

> 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.
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >>
>>
>
>