Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On Fri, Jun 17, 2011 at 01:08, Stefanos A. stapos...@gmail.com wrote: Matthew, I love your idea. With little twist: loving the idea, too. i wouldn't make it that humble tho, proper fields, perhaps the size of browser tabs, would make sense to me for each menu ( View, Go, Edit ...) - unmaximized windows get a menu button that displays (drops down?) the menu when clicked. this idea feels good, too. Until today, i have been unable to figure out what appmenus are actually really gonna be needed for in the future of interface. A11y perhaps? A blind person is unlikely to be using Gimp or Blender, whereas both applications are good examples of context-menu lived app-menu functionality. Perhaps appmenus can be of interest to people who use only a keyboard, yes that would make sense. But obviously our interaction hardware is aiming at immediacy, correspondence, rather than symbolic crypticism or text-driven menu-isms. I've also been thinking that interface is becoming more complex, but that's only true if you look at it from the code point of view. To the human naive perception, interface is becoming simpler, it corresponds more and more with the actual content, i.e. the sense realms we are trying to connect with. So a menu-button would be a good step towards making the interface perceptively simpler. Maybe this is a good opportunity to rethink the role of the the Context Menu Button on our desktop computer keyboards. Pressing it should at least visualize those *context relevant,* usually panel-lived menus, which might be hidden in the model you describe. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On 06/17/2011 11:14 AM, frederik.nn...@gmail.com wrote: But obviously our interaction hardware is aiming at immediacy, correspondence, rather than symbolic crypticism or text-driven menu-isms. I can only guess you must be referring to (multi-)touch surfaces. But that's an addition, not a replacement. Keyboard and mouse are still great to have for word processing, graphics, CAD and so on. The nature and quantity of required or useful commands and options in such fields hasn't changed. So a menu-button would be a good step towards making the interface perceptively simpler. The perception is not limited to a first look. It includes what happens during interaction. In this sense, hiding something only to reveal it at some point does not make anything simpler. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On Fri, Jun 17, 2011 at 12:10, Thorsten Wilms t...@freenet.de wrote: On 06/17/2011 11:14 AM, frederik.nn...@gmail.com wrote: But obviously our interaction hardware is aiming at immediacy, correspondence, rather than symbolic crypticism or text-driven menu-isms. I can only guess you must be referring to (multi-)touch surfaces. But that's an addition, not a replacement. yes, i thought of that, and i thought further, as you did: what i'm trying to imply is rather that interaction is becoming more immediate, which includes a stronger emphasis on pointing devices, where keyboards are becoming more and more a pool for click modifiers. An unfortunately not so successfull attempt was made be the Mustux/Protux team a decade ago with the so-called JMB - Jog Mouse Board, and Blender is also another example, or Ardour, where you point with the mouse and press a key to perform an action. So I'm not trying to say everything is going multi touch, even if it does happen to be a strong trend nowadays, i'm rather thinking along the lines of interaction is focusing more and more on the object of your interaction, and less on some distant menu at the edge of the screen. Your regular ILM engineer would surely appreciate such a development, on the long run. Keyboard and mouse are still great to have for word processing, graphics, CAD and so on. The nature and quantity of required or useful commands and options in such fields hasn't changed. Yes, i think so too, whereas word processing would be the only example here which would fit the target audience of the interaction environment we are discussing. How CGI engineers use menus and $ 15.000 CAD suites is more of a specialized problem outside the topic at hand imo. So a menu-button would be a good step towards making the interface perceptively simpler. The perception is not limited to a first look. It includes what happens during interaction. In this sense, hiding something only to reveal it at some point does not make anything simpler. agreed. But the first look will be all the ordinary user will ever get, and the less cluttered the first look is, the simpler the interface appears, which makes it easier to use already. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On Fri, Jun 17, 2011 at 12:43, frederik.nn...@gmail.com frederik.nn...@gmail.com wrote: On Fri, Jun 17, 2011 at 12:10, Thorsten Wilms t...@freenet.de wrote: On 06/17/2011 11:14 AM, frederik.nn...@gmail.com wrote: But obviously our interaction hardware is aiming at immediacy, correspondence, rather than symbolic crypticism or text-driven menu-isms. I can only guess you must be referring to (multi-)touch surfaces. But that's an addition, not a replacement. yes, i thought of that, and i thought further, as you did: what i'm trying to imply is rather that interaction is becoming more immediate, which includes a stronger emphasis on pointing devices, where keyboards are becoming more and more a pool for click modifiers. An unfortunately not so successfull attempt was made be the Mustux/Protux team a decade ago with the so-called JMB - Jog Mouse Board, and Blender is also another example, or Ardour, where you point with the mouse and press a key to perform an action. So I'm not trying to say everything is going multi touch, even if it does happen to be a strong trend nowadays, i'm rather thinking along the lines of interaction is focusing more and more on the object of your interaction, and less on some distant menu at the edge of the screen. Your regular ILM engineer would surely appreciate such a development, on the long run. one could also simply say, object oriented design is becoming less and less abstract, the objects are beginning to correspond with actual physical or mental objects, rather than with abstract steps of interaction, which one would have to learn anew for each software application. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On Fri, Jun 17, 2011 at 12:43 PM, frederik.nn...@gmail.com frederik.nn...@gmail.com wrote: On Fri, Jun 17, 2011 at 12:10, Thorsten Wilms t...@freenet.de wrote: On 06/17/2011 11:14 AM, frederik.nn...@gmail.com wrote: But obviously our interaction hardware is aiming at immediacy, correspondence, rather than symbolic crypticism or text-driven menu-isms. I can only guess you must be referring to (multi-)touch surfaces. But that's an addition, not a replacement. yes, i thought of that, and i thought further, as you did: what i'm trying to imply is rather that interaction is becoming more immediate, which includes a stronger emphasis on pointing devices, where keyboards are becoming more and more a pool for click modifiers. An unfortunately not so successfull attempt was made be the Mustux/Protux team a decade ago with the so-called JMB - Jog Mouse Board, and Blender is also another example, or Ardour, where you point with the mouse and press a key to perform an action. So I'm not trying to say everything is going multi touch, even if it does happen to be a strong trend nowadays, i'm rather thinking along the lines of interaction is focusing more and more on the object of your interaction, and less on some distant menu at the edge of the screen. Your regular ILM engineer would surely appreciate such a development, on the long run. Keyboard and mouse are still great to have for word processing, graphics, CAD and so on. The nature and quantity of required or useful commands and options in such fields hasn't changed. Yes, i think so too, whereas word processing would be the only example here which would fit the target audience of the interaction environment we are discussing. How CGI engineers use menus and $ 15.000 CAD suites is more of a specialized problem outside the topic at hand imo. So a menu-button would be a good step towards making the interface perceptively simpler. The perception is not limited to a first look. It includes what happens during interaction. In this sense, hiding something only to reveal it at some point does not make anything simpler. agreed. But the first look will be all the ordinary user will ever get, and the less cluttered the first look is, the simpler the interface appears, which makes it easier to use already. A beautiful example of a menu button: http://lh5.googleusercontent.com/_1QSDkzYY2vc/TdFlT_A0vxI/Eco/lWRn14SImeo/s500/mockups%20menu-experiments%20eog-menu-experiments.png http://lh4.googleusercontent.com/_1QSDkzYY2vc/TdFsJwK3UPI/Ecs/Dn-8Qorj6Tc/s500/mockups%20menu-experiments%20epiphany-mega-menu.png ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
...or at the very least to be able to disable global menus for non-maximized applications and to disable the menu hiding. -~Chris On 06/16/2011 05:51 PM, Ralph Green wrote: Howdy, OK, Is there going to be some easy way to turn off the global menu? It is already clear to me that I would never want to use it. I can adapt to many of the features of Unity, but the global menu is such a poor idea that I would love to be able to turn it off. For now, I have switched to the Classic desktop, but I would continue with Unity if I could turn off global menus. Good day, Ralph On Wed, Jun 15, 2011 at 9:22 AM, Matthew Paul Thomasm...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Yes, that would be the price of wanting to use focus-follows-mouse in an environment that has a global menu bar: you would have to remember which is the active window for yourself. If you don't want to do that, don't use it. - -- mpt ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On 16/06/11 22:17, Matthew Bassett wrote: On 15/06/11 21:28, Matthew Bassett wrote: [some stuff deleted] 1) to not activate menu drop downs until mouse-up (so you can grab the the menu bar/title bar without issue and drag the menu around), or 2) only make the menu appear when you mouse over the left hand half of the title bar. Or: 3) When the pointer goes over the title bar of a non-maximised window, have the menu bar appear floating below the title bar, to the right of the window buttons (for consistent horizontal alignment with the menu of maximised windows). This leaves the title bar free for grabbing to move the window, without having special unexpected behaviour for those people that are used to scrubbing the pointer down on a menu to select the desired item. [all the cool kids are using balsamiq, so I have used it WRONG:] Here is my illustration of a window where the mouse pointer is not near the Window title bar (this is only here so you can compare it to the other version): http://ubuntuone.com/p/zkH/ Here is my illustration of when the pointer has gone over the title bar: http://ubuntuone.com/p/zkI/ Some notes: 1) maybe it looks better if you don't overlap the floating menu with the title bar, but instead extend the menu out from the window title (as I have tried to illustrate above). 2) it would be simple to dock the floating menu bar (although you would use up vertical real estate in the window) for those that wish to see the menu permanently. 3) it would be simple to change the behaviour to require a mouse down on the menu title in order to make the menu appear... 4) For maximised windows you can have the menu appear consistently with this (i.e. floating below the panel) thus keeping the application name / window title visible, instead of it being concealed by the menu. Feedback? ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On 17/06/11 12:06, Adrian Maier wrote: Hiding the menu seems to be considered by some people eye-pleasing , but it breaks productivity. It's irritating to click on something that is_not_yet_visible_until_you_reach_there . I understand your concern; I think this something that someone (!) somewhere (!!) could do some research on :) ... also I wonder if making the Alt key toggle the presence of the menu would be a worthwhile change in behaviour that would in someway mitigatge your concerns? (effectively making the Alt-key into a menu button). It is certainly nearer to my fingers when they are thinking about menus than the F10 key is... At that point you have the issue of making this kind of behaviour discoverable... ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On 17/06/11 14:10, Joost Verdoorn wrote: A beautiful example of a menu button: http://lh5.googleusercontent.com/_1QSDkzYY2vc/TdFlT_A0vxI/Eco/lWRn14SImeo/s500/mockups%20menu-experiments%20eog-menu-experiments.png http://lh4.googleusercontent.com/_1QSDkzYY2vc/TdFsJwK3UPI/Ecs/Dn-8Qorj6Tc/s500/mockups%20menu-experiments%20epiphany-mega-menu.png I think these require careful redesign of the application's menu rather than Unity's global menu though... ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
Hello, Am 15.06.2011 22:28, schrieb Matthew Bassett: What about just having the menu bar consistently appearing with the window buttons: i.e. in the panel when the window is maximised, and on the title bar on non-maximised windows -- appearing when the mouse goes over the title bar. This leaves the issue of how to grab the title bar of a non-maximised window in order to move it, which I would assume to be an easier problem to design/resolve; my naive suggestions would be to either 1) to not activate menu drop downs until mouse-up (so you can grab the the menu bar/title bar without issue and drag the menu around), or 2) only make the menu appear when you mouse over the left hand half of the title bar. There could also be a grab handle in the title bar, e.g. a fourth button. I think move window fits nicely into the row of close, minimize and maximize. When clicking on this button, you wouldn't need to keep your mouse button pressed until the window is in the final position, which might help some people that have problems with drag'n'drop. For windows with short menus, clicking on the empty space beyond the right-most menu bar entry could also allow dragging around, so you'd need to use the small button only for windows with too long menus (which are relatively rare I guess). Greetings, Philipp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
Hi, Am 16.06.2011 10:24, schrieb Adrian Maier: On Thu, Jun 16, 2011 at 09:53, Philipp Wendlerubu...@philippwendler.de wrote: Am 15.06.2011 22:28, schrieb Matthew Bassett: What about just having the menu bar consistently appearing with the window buttons: i.e. in the panel when the window is maximised, and on the title bar on non-maximised windows -- appearing when the mouse goes over the title bar. This leaves the issue of how to grab the title bar of a non-maximised window in order to move it, which I would assume to be an easier problem to design/resolve; my naive suggestions would be to either 1) to not activate menu drop downs until mouse-up (so you can grab the the menu bar/title bar without issue and drag the menu around), or 2) only make the menu appear when you mouse over the left hand half of the title bar. There could also be a grab handle in the title bar, e.g. a fourth button. I think move window fits nicely into the row of close, minimize and maximize. When clicking on this button, you wouldn't need to keep your mouse button pressed until the window is in the final position, which might help some people that have problems with drag'n'drop. For windows with short menus, clicking on the empty space beyond the right-most menu bar entry could also allow dragging around, so you'd need to use the small button only for windows with too long menus (which are relatively rare I guess). Such a titlebar button seems tedious to use (too small) . Of course it is very small, but as I said I think it will be needed only for a minority of windows. Actually there is a nice similarity to the minimize and maximize buttons here. These also handle window management, and both are very small, too. But for experienced users that want to work faster, there is a shortcut that involves mouse interaction with the title bar. The buttons are there despite the existence of a shortcut, because their are more discoverable for new users. So the same rationale that is used for the minimize and maximize buttons actually applies to a move button as well, I think. So is there a reason why we don't have a move button? Having a titlebar for moving windows is not an absolute must : it can be replaced with Alt + mouse_dragging. Right, though I think there should exist a mouse-only way to move windows. I enjoy to use this method wherever it's available because it doesn't matter where you click inside the window . In the other hand , I think that it would be interesting to consider merging the titlebar and the menu : - use the first 50 or 60 pixels of the titlebar for the window label . I think for the normal state (no current interaction) this is too short. A lot of window titles only differ at their end, and so I'd prefer to see the full title. Greetings, Philipp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
[bother. pressed the wrong button. Sorry, Ian, you'll see this twice...] On 16/06/11 00:25, Ian Santopietro wrote: Then, wouldn't the menu open after you finish dragging the window around? And what about people that click once on the menu, then drag down to the item they want, then release the mouse button? OK: I should have written: * On hovering the mouse over the title bar, display the menu bar over it. * on mouse-down, if the pointer is moved consider the window to have been grabbed and thus move it. * on mouse up, if the window was not grabbed, activate the menu item under the pointer. Having refined the above: I suspect the experience would be frustrating for those people who expect to drag the pointer down an active menu after mouse-down. On Wed, Jun 15, 2011 at 14:30, Matthew Bassett li...@mbassett.net mailto:li...@mbassett.net wrote: On 15/06/11 21:28, Matthew Bassett wrote: [deletia] 1) to not activate menu drop downs until mouse-up (so you can grab the the menu bar/title bar without issue and drag the menu around), or That should have been drag the WINDOW around... ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net mailto:ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Ian Santopietro /Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html/ Eala Earendel enlga beorohtast Ofer middangeard monnum sended Pa gur yv y porthaur? Public GPG key (RSA): http://keyserver.ubuntu.com:11371/pks/lookup?op=getsearch=0x412F52DB1BBF1234 http://keyserver.ubuntu.com:11371/pks/lookup?op=getsearch=0x412F52DB1BBF1234 ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On 15/06/11 21:28, Matthew Bassett wrote: [some stuff deleted] 1) to not activate menu drop downs until mouse-up (so you can grab the the menu bar/title bar without issue and drag the menu around), or 2) only make the menu appear when you mouse over the left hand half of the title bar. Or: 3) When the pointer goes over the title bar of a non-maximised window, have the menu bar appear floating below the title bar, to the right of the window buttons (for consistent horizontal alignment with the menu of maximised windows). This leaves the title bar free for grabbing to move the window, without having special unexpected behaviour for those people that are used to scrubbing the pointer down on a menu to select the desired item. For improved aesthetics I think it would probably be good to float the menu bar so that overlaps the title bar slightly (this would then give the alignment of the menu to the right of the window buttons a more reasonable appearance). The menu would persist whilst the pointer was over the title bar, or over the floating menu bar (and possibly for a short delay after it had moved away from either). This would also allow for menu bars that are wider than the windows with which they are associated without it looking too wierd. I have attempted (an extremely poor) illustration of what I mean at: http://ubuntuone.com/p/zZp/ (I would not propose the use of something quite as ugly as I have illustrated...) Thoughts anyone? ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On 16/06/11 09:34, Philipp Wendler wrote: Hi, Am 16.06.2011 10:24, schrieb Adrian Maier: On Thu, Jun 16, 2011 at 09:53, Philipp Wendlerubu...@philippwendler.de wrote: Am 15.06.2011 22:28, schrieb Matthew Bassett: What about just having the menu bar consistently appearing with the window buttons: i.e. in the panel when the window is maximised, and on the title bar on non-maximised windows -- appearing when the mouse goes over the title bar. This leaves the issue of how to grab the title bar of a non-maximised window in order to move it, which I would assume to be an easier problem to design/resolve; my naive suggestions would be to either 1) to not activate menu drop downs until mouse-up (so you can grab the the menu bar/title bar without issue and drag the menu around), or 2) only make the menu appear when you mouse over the left hand half of the title bar. There could also be a grab handle in the title bar, e.g. a fourth button. I think move window fits nicely into the row of close, minimize and maximize. When clicking on this button, you wouldn't need to keep your mouse button pressed until the window is in the final position, which might help some people that have problems with drag'n'drop. For windows with short menus, clicking on the empty space beyond the right-most menu bar entry could also allow dragging around, so you'd need to use the small button only for windows with too long menus (which are relatively rare I guess). Such a titlebar button seems tedious to use (too small) . Of course it is very small, but as I said I think it will be needed only for a minority of windows. Actually there is a nice similarity to the minimize and maximize buttons here. These also handle window management, and both are very small, too. But for experienced users that want to work faster, there is a shortcut that involves mouse interaction with the title bar. The buttons are there despite the existence of a shortcut, because their are more discoverable for new users. So the same rationale that is used for the minimize and maximize buttons actually applies to a move button as well, I think. So is there a reason why we don't have a move button? Having a titlebar for moving windows is not an absolute must : it can be replaced with Alt + mouse_dragging. Right, though I think there should exist a mouse-only way to move windows. I enjoy to use this method wherever it's available because it doesn't matter where you click inside the window . In the other hand , I think that it would be interesting to consider merging the titlebar and the menu : - use the first 50 or 60 pixels of the titlebar for the window label . I think for the normal state (no current interaction) this is too short. A lot of window titles only differ at their end, and so I'd prefer to see the full title. This would work well if the menu was only displayed when the pointer was over the title bar. At other times you would see the full window label -- and then when the pointer goes over the title bar you see the menu drawn (likely over the end of long window labels). This would still leave a portion of the window title for grabbing in order to move the window. Personally I quite like this solution. Greetings, Philipp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
Matthew, I love your idea. With little twist: - unmaximized windows get a menu button that displays (drops down?) the menu when clicked. This button should be on the opposite side of the close/maximize/minimize window buttons and should be large enobaleough to present a viable click target (see e.g. Opera or Firefox menu buttons). The titlebar retains its current functionality with regards to dragging and clicking. - maximized windows embed their menus into the top panel, along with the close/max/min buttons. Pros: - retains the visual design of no text menus in regular windows (advantageous in small screens) - retains the advantage of global menus for maximized windows - allows focus-follows-mouse to keep working correctly - this design has been tested and validated by several high-profile applications (e.g. Office, AutoCAD, Firefox, Opera) - this can work in conjunction with global menus! Cons: - won't work correctly on apps that draw their own borders (e.g. Chrome) What do you think? ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Nickurak wrote on 14/06/11 19:33: On Tue, Jun 14, 2011 at 09:27, Matthew Paul Thomas m...@canonical.com ... That isn't correct. I specified how it could work with focus follows mouse in May 2010, months before Natty even had a name. https://wiki.ubuntu.com/MenuBar#focus-follows-mouse Except that's missing design work too. There's no concept of the active window anywhere. There's no visual cue of what the active window is. Until that article, the concept didn't exist. Defining things that didn't previously exist is part of the point of a feature specification. :-) It's inconsistent, because the window that you might be working with is no longer the window that has the global menu. Imagine that you have 2 windows that don't overlap, and you've focused one by mouse-over. There's now *zero* indication that the global menu isn't related to the focused window. Select a destructive action like File:Revert or Delete is now a very scary and unpredictable concept. ... Yes, that would be the price of wanting to use focus-follows-mouse in an environment that has a global menu bar: you would have to remember which is the active window for yourself. If you don't want to do that, don't use it. - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk34wBwACgkQ6PUxNfU6ecppgACgn32eYDbgTUAGUeewmDx8Jo2y I7oAn3Fd78SFjP2eYQCWFwzzRzYBiPH3 =cg8X -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On 14/06/11 22:00, Florian Diesch wrote: Matthew Paul Thomas m...@canonical.com writes: Niklas Rosenqvist wrote on 19/05/11 10:15: 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. ... That isn't correct. I specified how it could work with focus follows mouse in May 2010, months before Natty even had a name. https://wiki.ubuntu.com/MenuBar#focus-follows-mouse That's much better than what we have now but still far from being a real solution as it would give me the wrong menu for a window I focused by moving the mouse to it. And the point of using focus follows mouse is that I can select a window with the mouse *without* clicking on it. Florian What about just having the menu bar consistently appearing with the window buttons: i.e. in the panel when the window is maximised, and on the title bar on non-maximised windows -- appearing when the mouse goes over the title bar. This leaves the issue of how to grab the title bar of a non-maximised window in order to move it, which I would assume to be an easier problem to design/resolve; my naive suggestions would be to either 1) to not activate menu drop downs until mouse-up (so you can grab the the menu bar/title bar without issue and drag the menu around), or 2) only make the menu appear when you mouse over the left hand half of the title bar. Once the menu appears due to mouse over the title bar, have it persist for a certain amount of time (500ms, 1sec or something) if the mouse pointer leaves the menu bar. Or am I barking up the wrong tree (or is this a suggestion seen many times before... I tried searching the archives, but did not find this suggestion). Cheers! Matthew ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On 15/06/11 21:28, Matthew Bassett wrote: [deletia] 1) to not activate menu drop downs until mouse-up (so you can grab the the menu bar/title bar without issue and drag the menu around), or That should have been drag the WINDOW around... ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
Then, wouldn't the menu open after you finish dragging the window around? And what about people that click once on the menu, then drag down to the item they want, then release the mouse button? On Wed, Jun 15, 2011 at 14:30, Matthew Bassett li...@mbassett.net wrote: On 15/06/11 21:28, Matthew Bassett wrote: [deletia] 1) to not activate menu drop downs until mouse-up (so you can grab the the menu bar/title bar without issue and drag the menu around), or That should have been drag the WINDOW around... ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Ian Santopietro *Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html* Eala Earendel enlga beorohtast Ofer middangeard monnum sended Pa gur yv y porthaur? Public GPG key (RSA): http://keyserver.ubuntu.com:11371/pks/lookup?op=getsearch=0x412F52DB1BBF1234 ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Niklas Rosenqvist wrote on 18/05/11 09:02: ... There are also more situations where the global menu works like a crippled narwhal. E.g. when working with programs as GIMP. GIMP has one main application window and several smaller windows with tools and such and if you have one of the smaller windows active you can't reach the menu, even if they are a part of the same application. You must target the main window and then you can reach the menu. That isn't an unfixable design flaw, it's just a bug. http://launchpad.net/bugs/646029 (I realize that to users, those two situations are indistinguishable.) Niklas Rosenqvist wrote on 19/05/11 10:15: 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. ... That isn't correct. I specified how it could work with focus follows mouse in May 2010, months before Natty even had a name. https://wiki.ubuntu.com/MenuBar#focus-follows-mouse - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk33fdUACgkQ6PUxNfU6ecoZPQCffDfLAaqKPGBHpNb1rdD68bA0 cBQAnRw41XrcmhsiTBwK2pgVdCiiiQmt =OMsm -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On Tue, Jun 14, 2011 at 09:27, Matthew Paul Thomas m...@canonical.comwrote: That isn't correct. I specified how it could work with focus follows mouse in May 2010, months before Natty even had a name. https://wiki.ubuntu.com/MenuBar#focus-follows-mouse Except that's missing design work too. There's no concept of the active window anywhere. There's no visual cue of what the active window is. Until that article, the concept didn't exist. It's inconsistent, because the window that you might be working with is no longer the window that has the global menu. Imagine that you have 2 windows that don't overlap, and you've focused one by mouse-over. There's now *zero* indication that the global menu isn't related to the focused window. Select a destructive action like File:Revert or Delete is now a very scary and unpredictable concept. -- Jeremy Nickurak -= Email/XMPP: -= jer...@nickurak.ca =- ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
Matthew Paul Thomas m...@canonical.com writes: Niklas Rosenqvist wrote on 19/05/11 10:15: 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. ... That isn't correct. I specified how it could work with focus follows mouse in May 2010, months before Natty even had a name. https://wiki.ubuntu.com/MenuBar#focus-follows-mouse That's much better than what we have now but still far from being a real solution as it would give me the wrong menu for a window I focused by moving the mouse to it. And the point of using focus follows mouse is that I can select a window with the mouse *without* clicking on it. Florian -- Simple dict-like Python API for GConf: http://www.florian-diesch.de/software/easygconf/ ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On 26. mai 2011 12:47, Adrian Maier wrote: On Thu, May 26, 2011 at 05:52, Ian Santopietroisan...@gmail.com wrote: But who said the majority of Ubuntu users don't like the global menu? It may well be the case that the majority of users on this mailing list don't like it, but it's been said before that this list is a small bias of users. There *was* usability testing done on Unity with both 10.10 and 11.04. Not once in the reports is disapproval of the menu voiced, in either version. So we can't say the verdict is going either way. You are right about the lack of verdict. The fact that some people dislike it doesn't necessarily mean that the default behavior must be immediately changed. But there is a solution:make the thing configurable I was very sceptical about the global menu to begin with, but I gave it a try and now I really like it. The only problem I see with it, is when you hover the mouse pointer to focus windows. In that case, by the time you reach the global menu, you'll most likely have focused another window, causing the menus to change. This will force you to use the keyboard to access the menus. So these things are not a good combination. Other than that, I have no problems with global menus. It does take a little time to get used to, but I think the benefits are worth the effort. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
There's some oftopic in at the beginning, considerer yourself warned. You can skip to the marking. On Thu, May 26, 2011 at 6:00 AM, GonzO go...@worlord.com wrote: On Wed, May 25, 2011 at 8:49 PM, Ed Lin edlin...@gmail.com wrote: With all due respect: I do not think your cases are all that common. I never claimed the contrary. BTW I don't use Unity and probably never ever will (I'll spare you the reasons, it wouldn't be pretty). I do not know whether or not anyone Official(TM) reads this list. However, if the reasons for never ever wanting to use Unity aren't aired, it'll never get better. Better out than in, I say, but that is something best left to your discretion. :-) OK, so it basically comes down to a few factors: The first one doesn't really have to do with Unity: I don't see myself switching to a Linux based OS on the desktop anytime soon because for what I do proprietary applications deliver the better tools. Good applications take a long time to be written and maintained, this costs money (developers need to eat too) and FOSS development will always stay behind unless we can find a solution to how to fund free software on a large scale. Secondly, this is speculation on my part, but I believe Unity will generally follow in the steps of GNOME 2 in it's focus on usability for inexperienced users by default with additional options for everybody else. The default experience is unusable for me (both Unity and GNOME 2) and I have no interest in configuring my desktop more than absolutely necessary with a bunch of options that are afterthoughts and never quite work as they should. Other desktops are perfectly usable for me almost without any tweaking, I don't see the point of giving that up. Finally, I deeply care about polish, consistency, bug-free-ness and optimization. This seams to be unsexy for developers and often gets the shorter end in FOSS development. GNOME 2 has been on the market for about 9 years and never managed to reach a level that pleased my admittedly high standards. Why should Unity fare any better (and do so soon)? All I see is code monkeys doing design work (no offence intended, I said it won't be pretty :P ) (Please prove me wrong though!) --- The problem I have with this is not its implementation, but the idea itself. I don't think putting indicators into the launcher is a good idea, what-used-to-be-a-panel notwithstanding. My reasons for this: All good reasons but if the panel stays, what about the user case of Chromium with tabs on top? The browser is already the most used application and this trend is only going up. Especially on a netbook with Chrome OS soon being the main competitor (and not Windows) the browser experience should receive priority. With some patching (i.e. less than making a tab indicator for the panel) I think a wing panel could work with tabs on top (just as Chrome OS has indicators at the top as well. But regardless, the indicator area could be smaller, we don't need the shutdown button there, it could be in the dash, we don't need a mail icon there unless the user has new mail, we don't need the full user name there by default. By slimming it down we'd win both space for other controls that are more frequently accessed and reduce clutter and distraction. And this is something Unity is _already_ somewhat bad at. Trash isn't a launcher - or, it launches Nautilus, which already has a launcher. Virtual Desktops, not a launcher. Two different lenses taking up two different tiles, when the functionality of each is merely a spin-off of the Dash. They _are_ launchers, but that's two more launchers than is really necessary or desirable. And none of these are removable except the lenses, where you actually have to uninstall Unity functionality to remove them. Yes, absolutely agree. You remember https://lists.launchpad.net/ayatana/msg05788.html ? #2: Indicators that contain text, like the date/time app, are almost impossible to display sanely in a launcher square. September all by itself won't fit unless the text is so small its squint-worthy. The username indicator would be a problem in my office, where usernames are typically full first+last name. The biggest reason why I don't actually like my own idea. At least now we can say we tried... ;) #5: Indication. I'm not sure we even _can_ display a speaker icon with varying numbers of waves to indicate volume, or a link down/link up pair even if each indicator would be its own launcher tile, which wouldn't work. Things like that are certainly technically possible though. Launcher icons already can display dynamic content (like the Firefox download bar) I _could_ see a single, expandable tile functioning as a systray area on the launcher; Cairo-Dock has this already, and this is how Windows behaves if you move the taskbar to either side of the screen.
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On Thu, May 26, 2011 at 12:47 PM, Adrian Maier syra...@gmail.com wrote: You are right about the lack of verdict. The fact that some people dislike it doesn't necessarily mean that the default behavior must be immediately changed. Two things we need to discern: the concept of a global menu and the Unity global menu. The Unity global menu (visible only on hover) is objectively bad design. The main reason to switch to the global menu was speed of access (and not saving screen estate as some want to make you believe: maximized windows can do that Unity magic independently of the global menu or even a top panel). However with the hover design this advantage was lost. Especially for new users (the focus group of Unity) it is empirically (see the mail by GonzO above) worse than the alternative. The second aspect is the concept of a global menu in general. It's not so easy to dismiss it completely but it also doesn't come without drawbacks. But I think I have sufficiently demonstrated by now that it only has a single advantage (speed as per Fitts's Law) which isn't undiluted (because of multi-tasking and other issues) but on the other hand introduces _several_ new issues that didn't exist before. This isn't my personal opinion (as I said, I'm not dogfooding Unity and if I was I could patch it to do whatever I want), it's about objective and logical conclusions. The only thing missing is empirical hard data. My suggestions: First get rid of the hover behavior, by default. Then do some user testing, by some I mean extended. Unity with and without indicator-appmenu and as a bonus: Unity without a panel at the top and browser tabs on top. The user testing should include desktop and netbook resolution, how fast people operate the system, their feedback (did they feel lost, was it enjoyable to use?) and report on any problems that did arise during the testing. My question: How can we make this happen? How can we measure behavior in the millisecond range? How should the test be setup in detail, has anybody done this before? I've heard of two Unity usability tests, can we get them on board? Anything I'm missing (I bet there is)? But there is a solution: make the thing configurable . That's not a solution, that's a band aid. Once we have found the best settings which are going to be used as the default we can always add some options of course. But we are far from that stage. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On Thu, May 26, 2011 at 2:15 PM, Jo-Erlend Schinstad joerlend.schins...@gmail.com wrote: I was very sceptical about the global menu to begin with, but I gave it a try and now I really like it. ... I have no problems with global menus. It does take a little time to get used to, but I think the benefits are worth the effort. I'm always interested in opposing views. Could you share what exactly are the benefits for you, what do you like about, what do you prefer to what you had before, how do you use it, netbook, single-tasking, always maximized or desktop, multiple windows? ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On Thu, May 26, 2011 at 8:49 AM, Ed Lin edlin...@gmail.com wrote: Finally, I deeply care about polish, consistency, bug-free-ness and optimization. This seams to be unsexy for developers and often gets the shorter end in FOSS development. Preach. application and this trend is only going up. Especially on a netbook with Chrome OS soon being the main competitor (and not Windows) the browser experience should receive priority. Not to mention, other apps are starting to use tabs. With some patching (i.e. less than making a tab indicator for the panel) I think a wing panel could work with tabs on top (just as Chrome OS has indicators at the top as well. But regardless, the indicator area could be smaller, we don't need the shutdown button there, it could be in the dash, we don't need a mail icon there unless the user has new mail, we don't need the full user name there by default. By slimming it down we'd win both space for other controls that are more frequently accessed and reduce clutter and distraction. No disagreements there. I, for one, hate the little envelope icon which is actually a whole BUNCH of things. I didn't want my IM icon merged with my Email and Twitter ones. --G ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On Thu, May 26, 2011 at 7:28 PM, Jo-Erlend Schinstad joerlend.schins...@gmail.com wrote: Thank you. Yes, I'll be happy to describe that, of course. Thank you for that detailed reply! To sum it up: - you don't use menus frequently so you prefer not having them clutter your screen - you often tile windows above each other, a global menu saves vertical space This is a very interesting, it indicates that the top screen edge is often wasted for interface elements that aren't used frequently enough to warrant that spot. The top panel is misused as place to get things out of the way. The second point seems to be more of a special case, it's mostly about terminal windows I understand? Browsers have tabs, file managers have split panes, tabs and usually you never have that many opened, text editor windows usually aren't stacked above each other because you want to maximize their vertical geometry. Terminals are different because you want to keep them all visible in case any need user input, finished a task and so on. I say special case because working with multiple terminals mostly done by the so called powerusers and I'd tend to think they don't really use the terminal menu all that often (if they even use gnome-terminal and not urxvt...) Sorry if this sounds confusing but basically this setup recreates a MDI application using the WM and panel. You could just as well have a maximized window open with one set of controls and multiple shells which can be rearranged (tabbed, tiled, maximized). You probably also aren't interested in selecting a single terminal and bring that to the foreground (via window switcher, spread view or launcher icon) because the title as well as the thumbnails are quite nondescript. You always switch to the terminal application (window). One solution would be to extend the tabbing on gnome-terminal to a full MDI application... The terminal is also a special case because it has no toolbars, all its controls are in the one menu, this makes separating the menu from the window very clean and logical, on other apps with multiple rows of GUI controls, the global menu would appear more arbitrary. Here's an example based on my own testing: Open an unfamiliar app, you need a certain function, first you'll probably go through the controls available within the window, you can't find what you are looking for, ah, right the menu, search again, in a completely different place (This has also implications with Fitts's Law, if D, the distance to the target, is really small as in this typical case the in-window menu is definitely faster to access on larger monitors) I also have another solution as well, just something to think about briefly: You all know GIMP, it has main windows for content and then it has toolboxes. We could have a terminal toolbox (actually a menu box which you can put on the screen edge) and then get the same result as with the global menu. But with gedit for example you could put the menu and the toolbar both to the screen edge. I'm not promoting that as an actual idea for Unity but lets imagine our desktops would be single tasking (a single app but multiple windows) and this could actually make sense. In a multi-tasking environment it would only add to the shortcomings of the global menu. But it would improve the mentioned calmness of the interface: You could really have windows with nothing but the content, the necessary tools would fade in only and whenever you actually need them. If you want a tl;dr: Very good points but if the goal is reducing clutter and maximizing screen estate for actual content (and some Fitts's Law for good measure) why the menu? Why *just* the menu, why not something else*? Colorful Toolboxes with sometimes tasteless icons are far more noisy... And as said, the hover behavior has to go so that would weaken the first argument (it could stay as an option though). *Actually I think I know the answer: it's done before, we know it will work it's easier from a technical as well as from a design point of view Doesn't sound like the best reasons to me and I prefer not having a feature to having a broken feature any day. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On Thu, May 26, 2011 at 15:34, Niklas Rosenqvist niklas.s.rosenqv...@gmail.com wrote: GonzO have you forgotten that sometimes people require a email client if their mail server doesn't support a web interface? People in these discussion threads seem to want to rule out that people aren't using the computer in the same way as themselves. Speaking only for myself, I'm not saying anything of the sort. I'm saying that web-mail users (even if they're 100% of the user base) still should have room for indicators and things. I'm a strict webmail user that would *LOVE* to have indication of mail in the panel, and don't have it right now. -- Jeremy Nickurak -= Email/XMPP: -= jer...@nickurak.ca =- ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
2011/5/26 Jo-Erlend Schinstad joerlend.schins...@gmail.com The biggest benefit I see, is the calmness it brings to my work environment. That's funny :) It's the exact opposite for me. I like having the top of the screen free since my eyes most often scan the top part of the screen. A top panel/global menu is always there to provide information. With the default Windows taskbar I'm never distracted of it, but when a top panel is there I'm always fed with some kind of information in the periphery. It would be easier to describe the situation by picturing yourself standing in a cabin on a mountain, gazing out the window on the landscape (top panel situation). Compared to standing on the cabins balcony and only leaning on the railing and having nothing but the sky above your head. Do you understand what I mean? It feels kind off crowded. 2011/5/26 Jo-Erlend Schinstad joerlend.schins...@gmail.com On 26. mai 2011 16:19, Ed Lin wrote: On Thu, May 26, 2011 at 2:15 PM, Jo-Erlend Schinstad joerlend.schins...@gmail.com wrote: I was very sceptical about the global menu to begin with, but I gave it a try and now I really like it. ... I have no problems with global menus. It does take a little time to get used to, but I think the benefits are worth the effort. I'm always interested in opposing views. Could you share what exactly are the benefits for you, what do you like about, what do you prefer to what you had before, how do you use it, netbook, single-tasking, always maximized or desktop, multiple windows? Thank you. Yes, I'll be happy to describe that, of course. I use it on a 15 laptop, a 11 subnotebook and on my desktop which has a 24 screen running in 1920x1080. I like it for a number of reasons. The biggest benefit I see, is the calmness it brings to my work environment. I was more than a little surprised by this. I had never considered the menus to be distracting in any way, but once they were gone, then I realised they had been. Really. I think I want to compare it to the sound of my subnotebook. It really isn't noisy at all and I don't pay attention to it, but when I switch it off, then I certainly notice and appreciate the sudden silence. Most of the time, I have no use for the menus at all, so why should they bother my eyes all the time? It's like a waiter who sits down at your table waiting for you to ask for something. Sure you can ignore the waiter, but I dare say you'd still be a little distracted. Most of the time, I know exactly what I want and if I need a menu, I know where to find it and how to use it. That brings me to the next benefit. It's much less of an issue for me, but I do think it's beneficial to have the menus at the same place all the time. I came from Windows and not Mac, so for me, it was a rather significant change, but I was determined to keep an open mind and give it a real chance. And while I don't think it's a huge improvement, I definitely think it's an improvement. I press alt and look straight at them. I do, however, think that the menus should be prepended with the icon of the focused window. Menus seldom need all the space they're given in any case, so I don't think that's an issue. The icon would help create a mental connection between the menu and the focused window. The only negative side I can see about the disconnection between a window and its menu is when you let focus follow the mouse pointer. If you have tiled your windows and the focus follows the pointer, then you might focus another window on your way to the menu, causing the menu to change. However, I've never understood why anyone would want to do that. I always move the cursor _away_ from the focused window in order to avoid distraction. But it might be something to consider if this is something that many people do. Perhaps global menu and focus follows pointer should be mutually exclusive options? On my desktop, I tile my windows and use workspaces extensively. Many windows has traditionally meant many visible menus and then they become not only distracting, but annoying because they start to waste a considerable amount of space. Also, if I have many terminal windows open, then I'd also have many identical menus on my screen. It is possible to remove the menu from a gnome-terminal window, but that shouldn't be required. It should be the opposite and that might be worth considering: add a menu item to the window menu (right click titlebar) where you can choose that this application should not use the global menu. Attach/Detach menu? There might be use cases for that, although I can't think of any at the moment. By the way; do you remember what it says on the Hitchhikers Guide to the Galaxy? «DON'T PANIC!». I certainly won't miss having 8-10 help-menus staring me in the face all the time. :) Thanks. Jo-Erlend Schinstad ___ Mailing list: https://launchpad.net/~ayatana
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
There are indicators for integrating webmail (at least for gmail) into the message indicator. PS: is it just me, or are there no well designed e-mail clients for our platform? On Thu, May 26, 2011 at 4:39 PM, Jeremy Nickurak jer...@nickurak.ca wrote: On Thu, May 26, 2011 at 15:34, Niklas Rosenqvist niklas.s.rosenqv...@gmail.com wrote: GonzO have you forgotten that sometimes people require a email client if their mail server doesn't support a web interface? People in these discussion threads seem to want to rule out that people aren't using the computer in the same way as themselves. Speaking only for myself, I'm not saying anything of the sort. I'm saying that web-mail users (even if they're 100% of the user base) still should have room for indicators and things. I'm a strict webmail user that would *LOVE* to have indication of mail in the panel, and don't have it right now. -- Jeremy Nickurak -= Email/XMPP: -= jer...@nickurak.ca =- ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On Thu, May 26, 2011 at 4:34 PM, Niklas Rosenqvist niklas.s.rosenqv...@gmail.com wrote: GonzO have you forgotten that sometimes people require a email client if their mail server doesn't support a web interface? I don't think I am, no. I said that, *for me*, a fat client is nonsensical. I also said that, of all the people I know who still use a fat client, it is *also* nonsensical. Which is why I argued *for* the mail indicator. I don't understand why, but am well aware that tons of people still use mail software, and we have to factor that in. To your credit, though, that was several messages ago. --G ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On Fri, May 27, 2011 at 12:09 AM, Spike Burch spi...@gmail.com wrote: PS: is it just me, or are there no well designed e-mail clients for our platform? Are there for any platform? ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On 27. mai 2011 01:32, GonzO wrote: On Thu, May 26, 2011 at 4:34 PM, Niklas Rosenqvist niklas.s.rosenqv...@gmail.com wrote: GonzO have you forgotten that sometimes people require a email client if their mail server doesn't support a web interface? I don't think I am, no. I said that, *for me*, a fat client is nonsensical. I also said that, of all the people I know who still use a fat client, it is *also* nonsensical. One of the reasons why I prefer native apps, is that they have consistent user interfaces. I know that I can press ctrl+f to search a treeview or listview, for instance. My keybindings are global to my desktop. They are not global to the web. Jo-Erlend Schinstad ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On Fri, May 27, 2011 at 1:16 AM, Jo-Erlend Schinstad joerlend.schins...@gmail.com wrote: On 26. mai 2011 22:53, Ed Lin wrote: enough to warrant that spot. The top panel is misused as place to get Why do you say it's misused? Because it's the most valuable space anywhere on the screen to put interface elements (horizontal panels have the advantage of suiting text better, they are the larger screen eges and the top has the advantage over the bottom that it's where already most of the controls are, where people start looking for them, usually where the mouse needs to travel less far and usually it's got the better viewing angle) No. Terminal windows were only meant as examples of small windows. I often have two text editors on top of each other so that I can read from one and write with another without having to switch contexts, for instance. In some cases, using a tabbed interface is quite nice, but in others, it's much better to see everything without having to switch back and forth. You can only do that on large monitors, 25 px (or something like that) don't matter *that much*. Yes, there might be a few exceptions, which is why I proposed making it possible to choose not to use the global menu for a single application/window. But it seem very unlikely to me that you would ever have a complex application like you're describing as a small window. Apps like that tend to be maximized, at least vertically, because of those very toolbars that you mention. You made a point of that yourself earlier. That means it would almost always still be a short distance between the menu and toolbar. gedit has two bars, nautilus three, pretty much all windows have more than just the menu, except terminal. [woops] (This has also implications with Fitts's Law, if D, the distance to the target, is really small as in this typical case the in-window menu is definitely faster to access on larger monitors) Regarding the mouse travel to the menu and back, I think that's a very interesting point. Would you ever use an apps menu and use the mouse for anything else at the same time? That's unlikely. So perhaps it would be possible to teleport the mouse pointer to the menu when you press alt and back again when you're done with the menus? I've never tested anything like that, but it might be worth testing. How would you do that? With the keyboard? Then you'd just use the already available keyboard shortcuts. That's easily answered. The toolbars are filled with the most common actions. The menus contains all the other things, the much less common actions. The calculator, for instance, does indeed have a help menu. How often do _you_ use it? It has some other menus too, but I only ever use the one to change modes. And I do that from time to time, but not nearly often enough for it to warrant a toolbar. So you see, there is a big difference between hiding the menu and hiding the toolbars. Granted, some applications provide a toolbar filled with uncommon actions, just to have a toolbar. That's wrong, and certainly both annoying and distracting, but that must be fixed in each application. The toolbars should only ever contain tools you do want available at all times. The rest should be placed in menus and tucked away for when you want them. I'm not saying that nothing can be done to improve toolbars, but I think it's a very different issue. You got one thing backwards then: The most frequently used items should be put at the screen edge *Actually I think I know the answer: it's done before, we know it will work it's easier from a technical as well as from a design point of view Doesn't sound like the best reasons to me and I prefer not having a feature to having a broken feature any day. You were wrong. The fact that it has been done before, would never be my answer to anything. That would be an insane argument, having in mind all the insane things people have done in the past. Not yours, but whoever is responsible for the more stupid ideas of Unity 1.0... It is for these reasons: I'll reply with the current Unity menu in mind, not the a Mac OS like menu... * It gives the desktop a much less technical feel. an illusion * You would never need to read the title of a window and use its menus at the same time. that's not the point, the point is new users don't even know where the menu is and old users are slowed down. * It conserves space on your screen. No it absolutely doesn't - the hover thing that is, I've already explained that several times now) Apart form that it only conserves space when you tile two or more windows (of the same app) above each other. This so far is THE ONLY advantage of the menubar. * It reduces duplicate information. it also reduces non-duplicate information (apps opened side by side) * It is more aesthetically pleasing. Yes, at the cost of usability. * And (I almost forgot this one, actually): I do think it's more consistent to
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On 27. mai 2011 01:47, Ed Lin wrote: Why do you say it's misused? Because it's the most valuable space anywhere on the screen to put interface elements I think application menus are important interface elements. (horizontal panels have the advantage of suiting text better, they are the larger screen eges and the top has the advantage over the bottom that it's where already most of the controls are, where people start looking for them, usually where the mouse needs to travel less far and usually it's got the better viewing angle) Yes, I couldn't have said it better myself. Menus are text. When they're not used, other text, like the title of the application if it's maximized is displayed there instead. Currently, when the window is not maximized, then only the name of the application is displayed. I think that could be utilized better. For instance, my Thunderbird shows Thunderbird Mail/News when it's not maximized and I'm not working with menus. It has to be possible to find some more useful text than that. I think stuff like that needs to grow with time. No. Terminal windows were only meant as examples of small windows. I often have two text editors on top of each other You can only do that on large monitors, 25 px (or something like that) don't matter *that much*. That just isn't true. I do that on my 11 all the time, using 1366x768 resolution. And yes, 50 or 75px does matter. As a demonstration, I made a screenshot for you: http://ubuntuone.com/p/vqK/ This is a normal day to day setup for me. On the left side, you're right. Having the menu visible wouldn't be a big deal. It would mean reading more menus and less Python, but other than that, it would be of no importance. On the right side, though, it would mean having to remove something, because those 75px actually do matter. Yes, there might be a few exceptions, which is why I proposed making it possible to choose not to use the global menu for a single application/window. But it seem very unlikely to me that you would ever have a complex application like you're describing as a small window. Apps like that tend to be maximized, at least vertically, because of those very toolbars that you mention. You made a point of that yourself earlier. That means it would almost always still be a short distance between the menu and toolbar. gedit has two bars, nautilus three, pretty much all windows have more than just the menu, except terminal. You're absolutely right. That's why applications like Nautilus tends to be maximized vertically. I don't agree that the tab bar is a place where the users will look for application features though. I think most users are beginning to get comfortable with tabbed interfaces. But thanks for reminding me that I don't ever use the toolbar buttons in gedit and therefore was able to remove it. :) That's easily answered. The toolbars are filled with the most common actions. The menus contains all the other things, the much less common actions. The calculator, for instance, does indeed have a help menu. How often do _you_ use it? It has some other menus too, but I only ever use the one to change modes. And I do that from time to time, but not nearly often enough for it to warrant a toolbar. So you see, there is a big difference between hiding the menu and hiding the toolbars. Granted, some applications provide a toolbar filled with uncommon actions, just to have a toolbar. That's wrong, and certainly both annoying and distracting, but that must be fixed in each application. The toolbars should only ever contain tools you do want available at all times. The rest should be placed in menus and tucked away for when you want them. I'm not saying that nothing can be done to improve toolbars, but I think it's a very different issue. You got one thing backwards then: The most frequently used items should be put at the screen edge What do you mean screen edge? I mean that to be the top of the screen, and that's what I'm advocating. Do you think the menu bar should be moved back to the window, but placed below the toolbar? Or do you mean the most common actions should be placed in the menu bar? You really lost me there. Not yours, but whoever is responsible for the more stupid ideas of Unity 1.0... But if I think those ideas happen to be very clever, then by extension, I have to be stupid as well? I don't think that's productive. Stick to explanations of how they're bad instead. I'll reply with the current Unity menu in mind, not the a Mac OS like menu... Good, because I happen to use Unity and not OS X. * It gives the desktop a much less technical feel. an illusion It's an illusion that the sound of the ocean has a calming effect on peoples nerves too then? Ok. Guess some illusions are good. What's your point? * You would never need to read the title of a window and use its menus at the same time. that's not the point, the point is new users don't even know where the menu is and old users are slowed down. Old
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
So this is half serious but something for you all to think about, if the global menu is such a great idea and we weren't constraint by any toolkit legacy problems... http://i.imgur.com/xsD0v.png Would you use this (without maximizing the window)? Now think about what this would mean for multi-tasking, is this really a step forward? My opinion on this: in a primarily single tasking environment (a tablet or even netbook maybe) I think _something_ like this actually is the way forward for the desktop paradigm: less chrome, full focus on the content, the interface is exactly where it makes the most sense ergonomically (with a mouse driven interface on the screen edge, on a tablet maybe left and right where your thumbs are, not the best demo: http://www.youtube.com/watch?v=UBxaxk9SKQc) The browser is also a better example than it might appear at first glance. Remember the browser is the new OS, people use it for everything, work, games, music, videos, communication. Tabs with only one webapp visible doesn't cut it. Back in the netscape days when I discovered tabbed browsing I switched to one browser window for everything. These days I often keep several opened, tiled, side by side, some minimized.. But what would that design mean on the larger widescreen monitor (naturally fit to accommodate two pages side by side like an opened book)? From what I've seen most people do one or two things at a time, in the office environment people often have a word processor in the one half and a file explorer in the other, or mail and browser, or you know, facebook and business app... The most important issue of the menubar (besides discoverability which was already covered in actual user testing so arguing against that really makes no sense at this point) is multi-tasking. The only reason that isn't glaringly obvious to anyone is: people who multi-task a lot know their applications well, they usually know the keyboard shortcuts and other controls and don't rely so much on the menu. Full circle back: why can anyone insist that the global menu is better because it's faster to access when it isn't necessary to often access it fast, an argument which doesn't even apply to Unity because of the hover design? Interim result: two points go to the global menu, cleanness of the interface (which is very problematic as the user testing showed, the actual solution here is to write better, cleaner applications) and the mentioned tiling windows on top of each other. On the other side we have a few thousand words written against it, there are so many arguments I really lost track of them. At this point I'd really like to get an official response from someone @ubuntu.com You can just say No and I'll stop spamming the list with this important but still single issue. God knows there are many more to solve... ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
[Ayatana] Global menu in Oneiric Ocelot (11.10)
On Tue, May 24, 2011 at 6:30 PM, Ed Lin edlin...@gmail.com wrote: With all due respect: I do not think your cases are all that common. It doesn't for me, the only thing I use is clock. The rest is irrelevant for my me most of the time. Wlan and battery? Not on a desktop. Desktops are becoming less and less popular, being replaced by Laptops and Netbooks... in which the battery, LAN, WLAN, BT thing are important and need to be twaddled with regularly. Email and IM? My browser is all I need. I think it is more than fair to say that, for some reason, using locally installed mail and IM clients is still what most people do. (I still use Pidgin, though long ago gave up localized mail). Global menu? I use keyboard shortcuts. I sincerely doubt that this is a common scenario. Even if I'm being generous, I can only believe that 50% of the users, maximum, even know that there *are* KB shortcuts for menus, much less what those shortcuts actually *are*. But thanks for making my tabs harder to access. Not all applications have tabs. So we'd be changing the structure to cater to the small handful of apps that do (even though, yes, the browser is a Real Important App(TM). On Tue, May 24, 2011 at 3:24 PM, Ed Lin edlin...@gmail.com wrote: A very rough sketch based on your image and parts scraped from google images... http://i.imgur.com/WMLYk.png Again, with all due respect: I do not think this is a good solution. It is making the launcher... no longer a launcher, and too much functionality has already been shoehorned into this thing. Not to mention, on a netbook resolution, *four* icon slots is way too much - that's practically half the launcher! I like indicators being on the screen edge - that's pretty much the only way they're useful - but shoving them in the launcher, and taking so much of the launcher's estate to do it, is just not a functional idea. --G ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On Wed, May 25, 2011 at 12:15, GonzO go...@worlord.com wrote: On Tue, May 24, 2011 at 6:30 PM, Ed Lin edlin...@gmail.com wrote: With all due respect: I do not think your cases are all that common. It doesn't for me, the only thing I use is clock. The rest is irrelevant for my me most of the time. Wlan and battery? Not on a desktop. Desktops are becoming less and less popular, being replaced by Laptops and Netbooks... in which the battery, LAN, WLAN, BT thing are important and need to be twaddled with regularly. Certainly wifi is really popular on the desktop these days too. Email and IM? My browser is all I need. I think it is more than fair to say that, for some reason, using locally installed mail and IM clients is still what most people do. (I still use Pidgin, though long ago gave up localized mail). I'd expect most people use web mail. That said, we still need a good place for *indicating* new web mail (regardless of whether we do it well now, which we don't). -- Jeremy Nickurak -= Email/XMPP: -= jer...@nickurak.ca =- ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On Wed, May 25, 2011 at 1:57 PM, Jeremy Nickurak jer...@nickurak.ca wrote: I'd expect most people use web mail. You would _not believe_ how popular email clients still are, even among the technically savvy. I admit, I have TBird installed just to have a backup archive of my Gmail account. But I don't actually *use it*. An alarming number of people I know, who work as IT professionals, just *will not give it up*. That said, we still need a good place for *indicating* new web mail (regardless of whether we do it well now, which we don't). ...oh, wow. That's a good idea. Although I get so much mail that it would always be on (five or six accounts route to one). --G ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
Am Mittwoch, den 25.05.2011, 16:53 -0500 schrieb GonzO: On Wed, May 25, 2011 at 1:57 PM, Jeremy Nickurak jer...@nickurak.ca wrote: I'd expect most people use web mail. You would _not believe_ how popular email clients still are, even among the technically savvy. Why should one give up a local E-mail client? Together with IMAP, that is a very fast and flexible solution: Only the mail content is loaded, not some useless website overhead. (My primary mail address is on gmail which has a pretty good webinterface, still I use evolution.) Also, my mail client marks quotes with the character which makes them easier to identify then your strange gap-marking... ;-) ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
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
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
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
Re: [Ayatana] 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.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
Re: [Ayatana] 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 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 :
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On 05/19/2011 10:31 AM, Ian Santopietro wrote: Mouse travel distance *is* irrelevant since mouse acceleration allows for great travel distances from short, twitchy movements. As long as the pointer acceleration does its job well. But only in one direction, to the menu, where the hitting the screen edge helps, not so much back from the menu to the content area. This again should only make a noticeable difference for windows that have their top in noteworthy distance from the top panel. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On Thu, 2011-05-19 at 13:08 -0400, anthropornis wrote: Does making an application Unity compatible involve more than making the menu entries exportable over the DBus system? Relative to other programming issues, is that more difficult, less difficult, or the same difficulty as other common programming tasks? Unity compatible has a range of values. For most applications there is nothing they need to do to make the menus exported. They can also choose to add things to their launchers or put data in the messaging menu. Not all applications have reasons to use those, but they're available for applications that choose to use them. We've tried hard to make the APIs straight forward for doing those tasks, so I'd like to believe it's an easy programming task. But that is most likely dependent on your experience, tastes, etc. --Ted signature.asc Description: This is a digitally signed message part ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
[Ayatana] Global menu in Oneiric Ocelot (11.10)
Hi! I as many have questioned the global menu bar which Unity features. I believe there are several issues with it as it is today and I will air my thoughts here. Many has complained on that it is incredibly frustrating to be working with on larger monitors. If the active window is in the bottom right corner and you have the menu at the top (which isn't even visible until you hover it) it makes no sense what so ever to look for it up there and it's really ineffective. Consider the following: 2011/5/18 Ralph Green sira...@gmail.com The global menu bar is another matter. It must die. If there is one feature that will drive me away from Unity, this is it. Again, there is no benefit, except on really small screens. And, now, I don't even see the menu until I move the mouse to the upper left hand corner of the screen. That is often a long way from where my program is. This really take a lot longer to operate. I don't understand how anyone could like it. I am not saying they are wrong to like it. I just don't understand how such a crazy thing was adopted. You know this feature was put on the Macs because they had such tiny screens at the time(512 by 384 pixels). I have seen Mac people discuss why it is a bad idea in the days of large screens and it only stays because of inertia. And Steve Jobs obsession with simplicity over usability., to be sure. Though I think that there has been proposed a really good solution to this: On Mon, May 9, 2011 at 7:10 PM, GonzO Rodrigue worlord...@gmail.com wrote: [...] B) only appeared in the panel space when the app is maximized. Leaving it in the window space makes more sense when not maximized [...] This way the menu wouldn't be taking up space when the application is maximized and it would still leave the menu implementation up the developers to design freely as they want. With this design firefox 4 could have it's menu button instead of splitting it into a menu to work with the global menu bar and developers doesn't have to make their programs compatible with the global menu since it would just melt together the program's title bar with the panel. This makes much more sense than today's implementation and it would offer more effective work flow when you don't have to move across the entire screen. There are also more situations where the global menu works like a crippled narwhal. E.g. when working with programs as GIMP. GIMP has one main application window and several smaller windows with tools and such and if you have one of the smaller windows active you can't reach the menu, even if they are a part of the same application. You must target the main window and then you can reach the menu. So what are your thoughts? If anyone already knows how it will be implemented in 11.10 (maybe from a discussion at UDS) please share your knowledge! ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
I've been begging for this particular change too. It makes more sense since vertical space is only an issue when you want it (ie. when you maximize windows), so un-maximized windows have no use for the global menu since, if they're un-maximized, they don't need the extra vertical space to render properly. Also, I think it's a bit of a stretch to expect application-devs to make their applications global-menu compatible. I can see how maximized windows getting stripped of their titlebar is relatively easy to implement in Unity without requiring dev's to change their apps (if maximized, then...), but making the standalone windows behave in this way must require some change in the application itself. 2011/5/18 Niklas Rosenqvist niklas.s.rosenqv...@gmail.com Hi! I as many have questioned the global menu bar which Unity features. I believe there are several issues with it as it is today and I will air my thoughts here. Many has complained on that it is incredibly frustrating to be working with on larger monitors. If the active window is in the bottom right corner and you have the menu at the top (which isn't even visible until you hover it) it makes no sense what so ever to look for it up there and it's really ineffective. Consider the following: 2011/5/18 Ralph Green sira...@gmail.com The global menu bar is another matter. It must die. If there is one feature that will drive me away from Unity, this is it. Again, there is no benefit, except on really small screens. And, now, I don't even see the menu until I move the mouse to the upper left hand corner of the screen. That is often a long way from where my program is. This really take a lot longer to operate. I don't understand how anyone could like it. I am not saying they are wrong to like it. I just don't understand how such a crazy thing was adopted. You know this feature was put on the Macs because they had such tiny screens at the time(512 by 384 pixels). I have seen Mac people discuss why it is a bad idea in the days of large screens and it only stays because of inertia. And Steve Jobs obsession with simplicity over usability., to be sure. Though I think that there has been proposed a really good solution to this: On Mon, May 9, 2011 at 7:10 PM, GonzO Rodrigue worlord...@gmail.com wrote: [...] B) only appeared in the panel space when the app is maximized. Leaving it in the window space makes more sense when not maximized [...] This way the menu wouldn't be taking up space when the application is maximized and it would still leave the menu implementation up the developers to design freely as they want. With this design firefox 4 could have it's menu button instead of splitting it into a menu to work with the global menu bar and developers doesn't have to make their programs compatible with the global menu since it would just melt together the program's title bar with the panel. This makes much more sense than today's implementation and it would offer more effective work flow when you don't have to move across the entire screen. There are also more situations where the global menu works like a crippled narwhal. E.g. when working with programs as GIMP. GIMP has one main application window and several smaller windows with tools and such and if you have one of the smaller windows active you can't reach the menu, even if they are a part of the same application. You must target the main window and then you can reach the menu. So what are your thoughts? If anyone already knows how it will be implemented in 11.10 (maybe from a discussion at UDS) please share your knowledge! ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
2011/5/18 Henrik Peytz henrik.pe...@gmail.com Also, I think it's a bit of a stretch to expect application-devs to make their applications global-menu compatible. I can see how maximized windows getting stripped of their titlebar is relatively easy to implement in Unity without requiring dev's to change their apps (if maximized, then...), but making the standalone windows behave in this way must require some change in the application itself. I don't know exactly what must be done but I know it's something since all applications does not utilize the global menu, only the ones supported. E.g. if you download the latest version of PlayOnLinux you'll see that it uses the traditional menu - not global menu. 2011/5/18 Henrik Peytz henrik.pe...@gmail.com I've been begging for this particular change too. It makes more sense since vertical space is only an issue when you want it (ie. when you maximize windows), so un-maximized windows have no use for the global menu since, if they're un-maximized, they don't need the extra vertical space to render properly. Also, I think it's a bit of a stretch to expect application-devs to make their applications global-menu compatible. I can see how maximized windows getting stripped of their titlebar is relatively easy to implement in Unity without requiring dev's to change their apps (if maximized, then...), but making the standalone windows behave in this way must require some change in the application itself. 2011/5/18 Niklas Rosenqvist niklas.s.rosenqv...@gmail.com Hi! I as many have questioned the global menu bar which Unity features. I believe there are several issues with it as it is today and I will air my thoughts here. Many has complained on that it is incredibly frustrating to be working with on larger monitors. If the active window is in the bottom right corner and you have the menu at the top (which isn't even visible until you hover it) it makes no sense what so ever to look for it up there and it's really ineffective. Consider the following: 2011/5/18 Ralph Green sira...@gmail.com The global menu bar is another matter. It must die. If there is one feature that will drive me away from Unity, this is it. Again, there is no benefit, except on really small screens. And, now, I don't even see the menu until I move the mouse to the upper left hand corner of the screen. That is often a long way from where my program is. This really take a lot longer to operate. I don't understand how anyone could like it. I am not saying they are wrong to like it. I just don't understand how such a crazy thing was adopted. You know this feature was put on the Macs because they had such tiny screens at the time(512 by 384 pixels). I have seen Mac people discuss why it is a bad idea in the days of large screens and it only stays because of inertia. And Steve Jobs obsession with simplicity over usability., to be sure. Though I think that there has been proposed a really good solution to this: On Mon, May 9, 2011 at 7:10 PM, GonzO Rodrigue worlord...@gmail.com wrote: [...] B) only appeared in the panel space when the app is maximized. Leaving it in the window space makes more sense when not maximized [...] This way the menu wouldn't be taking up space when the application is maximized and it would still leave the menu implementation up the developers to design freely as they want. With this design firefox 4 could have it's menu button instead of splitting it into a menu to work with the global menu bar and developers doesn't have to make their programs compatible with the global menu since it would just melt together the program's title bar with the panel. This makes much more sense than today's implementation and it would offer more effective work flow when you don't have to move across the entire screen. There are also more situations where the global menu works like a crippled narwhal. E.g. when working with programs as GIMP. GIMP has one main application window and several smaller windows with tools and such and if you have one of the smaller windows active you can't reach the menu, even if they are a part of the same application. You must target the main window and then you can reach the menu. So what are your thoughts? If anyone already knows how it will be implemented in 11.10 (maybe from a discussion at UDS) please share your knowledge! ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list:
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
On 05/18/2011 11:58 AM, Henrik Peytz wrote: It makes more sense since vertical space is only an issue when you want it (ie. when you maximize windows), so un-maximized windows have no use for the global menu since, if they're un-maximized, they don't need the extra vertical space to render properly. It seems you didn't really think of cases where you have several windows next to each other, all fully exposed. Actually it's the several non-maximized windows case where a global menu shines regarding space efficiency, as you don't save only one menu bar area, but several. It would be an interesting _experiment_ to render non-maximized windows sans menus, and have the menu slide in inside a window, once it gets and for as long as it has focus. Or to avoid movement, switch between titles and menus in the titlebars. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
Or have a menu-toggle-button next to the other window-controls (close, maximize etc.) so the user can decide on a per-window-basis whether he wants the menus visible or not. I think auto-hiding menus would be bad since it's possible for a user to want to retain an overview of available menus, even if that particular application is not in focus. This is particularly true when learning a new application and the user doesn't remember all the options available to him. Moving the menu to the titlebar is also a solution, though people will probably complain a about the clutter, and dragging the window will be problematic if the menus span the entirety of the window due to menu-overflow or resizing the window too small. 2011/5/18 Thorsten Wilms t...@freenet.de Actually it's the several non-maximized windows case where a global menu shines regarding space efficiency, as you don't save only one menu bar area, but several. It would be an interesting _experiment_ to render non-maximized windows sans menus, and have the menu slide in inside a window, once it gets and for as long as it has focus. Or to avoid movement, switch between titles and menus in the titlebars. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
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
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
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
Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)
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
