Some windows mare exceedingly small (Empathy) or have a very large number of menus (GIMP). Just because this is true for most windows doesn't mean we should leave them out.
As for moving the window, it's difficult for a new user to know that, and it requires a few seconds before you can move the window, which could decrease productivity. Also, some user click and hold through the menus, and that would create confusion when a user tries to drag their mouse through the menus and the window moves instead. On Sat, Apr 16, 2011 at 10:31, Toki Tahmid <oxw...@gmail.com> wrote: > @Mitja, you're misunderstanding, he recommends that menu appears besides > title button not inside. > > @Ian, why can we not allow long mouse button press to drag windows on title > bar real estate? Accessing menus or anything on the title bar would not > require long presses, but simple clicks. So after one or two seconds, if the > mouse hasn't moved to menu options, the cursor can handle dragging the > window. > > Menus do not usually number more than five or six, so on typical windows, > widening them slightly would go a long way. I'm against fading in of menus > then disappearing because it will escape the view of any inattentive user, > Menus can be slightly faded in the title bar as I suggested before, while > appearing fully coloured on mouse over. > > > On 16 April 2011 20:07, Ian Santopietro <isan...@gmail.com> wrote: > >> > Integrate the menu in the titlebar and have it smoothly fade in when the >> mouse moves near to it. >> >> What if I want to move a window? On a multitouch device I can use >> three-finger drag or the MT Grab Handles, but on an old fashioned mouse and >> keyboard, I can't do it at all since the title bar is now not used for >> dragging the windows around. And it doesn't solve many of the problems >> associated with menus right now; What happens when menus are too long for >> windows is a big one. Problems like these are what the global menu are >> really trying to solve, not saving vertical screen space. We have the >> titlebar integration for that one. >> >> >> > I think someone had suggested that when the application first starts, >> the window title is displayed for a few seconds before fading to the menu. >> If a window is idle for a while the title fades in. >> >> I think that may have been me (if not, I apologize), and it was slightly >> different. But this is a good solution to use with the global menu and the >> clutter issue. I initially suggested showing the menu for a second or two >> before switching to the title completely, but the one you described would >> work too. My only concern is that the title would occasionally be flashing >> in and out and alternating with the menus. This could be a distraction. I >> recommend simply displaying the title for a few seconds when the window >> opens, then fading to the menu and staying there permanently. >> >> On Sat, Apr 16, 2011 at 04:36, Christian Mackintosh < >> christian.mackint...@gmail.com> wrote: >> >>> The points you described are valid, but with the increasing of screen >>>> sizes and the use of laptops, it's very annoying to move the mouse all the >>>> way over to the panel using the touchpad. On the other hand, users are >>>> already accustomed to have the menu bars in the window, so I don't see any >>>> valid reason to move the menu bar of all the applications to the panel. >>>> Having many small windows opened at a given moment will only increase the >>>> frustration - go to panel do something, again drag mouse to next window, >>>> drag it back up, do something, and it goes on and on... >>>> >>> >>> I could not agree more! >>> >>> >>>> >>>> In any case, I am in agreement with your solutions, and the only think I >>>> want to add is to change the complete hidden nature of the current menu >>>> bars. Users new to Unity would be totally clueless as to where the menu bar >>>> is, regardless of it's position on the panel or title bar. If the menus are >>>> slightly faded out and fades in on mouse over would look good on top of >>>> being functional. >>>> >>> >>> This is a real problem. I think fading in (like a reverse notification >>> bubble, as some have suggested) would really help things, but even if the >>> menus remain hidden I think users are far more likely to find them if >>> they're integrated in the window titlebar rather than the panel, because if >>> they're looking for a menu they're going to be mousing around the window >>> they're in, not the top of the screen. >>> >>> Nonetheless, wherever the menus end up, currently we *are* just relying >>> on users to accidentally stumble upon the menus, which seems utterly bizarre >>> to me. I know this has been discussed on the mailing list before, but >>> something really needs to be done about it. >>> >>> Personally I would take your suggestion, Toki. Integrate the menu in the >>> titlebar and have it smoothly fade in when the mouse moves near to it. >>> Failing that (I understand that it's difficult to implement fading on >>> proximity) I think someone had suggested that when the application first >>> starts, the window title is displayed for a few seconds before fading to the >>> menu. If a window is idle for a while the title fades in. IMHO this would >>> also be a neat solution. >>> >>> Christian >>> >>> >>>> >>>> >>>> On 16 April 2011 14:12, Christian Mackintosh < >>>> christian.mackint...@gmail.com> wrote: >>>> >>>>> Toki, >>>>> >>>>> What Greg was saying, I think, was that throwing the mouse up to the >>>>> top edge of the screen is a very easy thing to do, in that you don't have >>>>> to >>>>> aim for any target. The way menu bars normally are, and the way both he >>>>> and >>>>> I, amongst others, have proposed, means that you are aiming for a smaller >>>>> target in the middle of the screen, which may be slightly slower. >>>>> However, I >>>>> don't actually think that that is really a valid concern because currently >>>>> when I try to use the global menu it often works like this: >>>>> >>>>> 1) Throw mouse to top of screen >>>>> 2) Notice that this is the wrong menu (if I'm lucky! A few times I've >>>>> started searching in vain through a menu, only to realise after a few >>>>> seconds that it's not the one I want) >>>>> 3) Move mouse to application, click to focus >>>>> 4) Move mouse back to top of screen >>>>> 5) Use menu >>>>> >>>>> Whereas if the menubars were integrated into the restored window's >>>>> titlebar, the process would be thus: >>>>> >>>>> 1) Move mouse to application >>>>> 2) Use menu, even if the window wasn't focused. >>>>> >>>>> Furthermore, as I said earlier, at the very least it won't be any >>>>> slower than the previous behaviour of having separate menu bars. >>>>> >>>>> Christian >>>>> >>>>> P.S. I think(?) you forgot to CC this message to ayatana, so it just >>>>> went to me. >>>>> >>>>> >>>>> On Sat, Apr 16, 2011 at 1:46 PM, Toki Tahmid <oxw...@gmail.com> wrote: >>>>> >>>>>> I think the masses has already the sense to find the titlebar in the >>>>>> window they're interacting in, so that doesn't count... >>>>>> >>>>>> >>>>>> On 16 April 2011 13:37, Christian Mackintosh < >>>>>> christian.mackint...@gmail.com> wrote: >>>>>> >>>>>>> Greg, >>>>>>> >>>>>>> You are absolutely right IMHO. Nothing more to add, just lending my >>>>>>> support! >>>>>>> >>>>>>> >>>>>>> On Sat, Apr 16, 2011 at 1:29 PM, Greg K Nicholson <g...@gkn.me.uk>wrote: >>>>>>> >>>>>>>> > However, Greg, is the downside you are describing for the current >>>>>>>> layout >>>>>>>> > with menu bar indiscriminately in title bar or the layout you're >>>>>>>> describing? >>>>>>>> >>>>>>>> The disadvantage I described was for the layout I described. >>>>>>>> >>>>>>>> Having the menu always in the panel makes it quicker to acquire and >>>>>>>> click, which is good, but it appears connected to the wrong window. >>>>>>>> In >>>>>>>> my view, having the menu appear to be connected to the right window >>>>>>>> is >>>>>>>> more important than speed. >>>>>>>> >>>>>>>> Put another way, the problem with the current layout is this: even >>>>>>>> though the menu is in a consistent place all the time, it doesn't >>>>>>>> *feel* consistent, and that's confusing. >>>>>>>> -- >>>>>>>> ☮♥☯ >>>>>>>> Greg K Nicholson >>>>>>>> http://gkn.me.uk >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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: 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 >>> >>> >> >> >> -- >> Ian Santopietro >> >> "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=get&search=0x412F52DB1BBF1234 >> >> > -- Ian Santopietro "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=get&search=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
