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 <mailto: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 <mailto: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
<mailto:niklas.s.rosenqvist@xxxxxxxxx>> wrote:
>> > Sorry people for accidentally sending duplicates, here is the real
>> version:
>> >
>> > 2011/5/18 Bazon <bazonbloch@xxxxxxxx <mailto: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
<mailto:niklas.s.rosenqvist@xxxxxxxxx>>
>> >
>> >> 2011/5/18 Bazon <bazonbloch@xxxxxxxx <mailto: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 <mailto: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.
>> >>>
>> >>>
>> >>
>> >>
>>
_______________________________________________
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~ayatana
More help : https://help.launchpad.net/ListHelp
