2011/5/19 Florian Diesch <die...@spamfence.net> > 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.rosenqv...@gmail.com> > 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 <isan...@gmail.com> > >> 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.rosenqv...@gmail.com> 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 <isan...@gmail.com> >> > >> >> 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.rosenqv...@gmail.com> wrote: >> >> > Sorry people for accidentally sending duplicates, here is the real >> >> version: >> >> > >> >> > 2011/5/18 Bazon <bazonbl...@arcor.de> >> >> >> 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.rosenqv...@gmail.com> >> >> > >> >> >> 2011/5/18 Bazon <bazonbl...@arcor.de> >> >> >> > 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 <bazonbl...@arcor.de> >> >> >> >> >> >>> 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
