unity-design team mailing list archive

[Ian Santopietro <isantop@xxxxxxxxx>]

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 <oxwivi@xxxxxxxxx> 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 <isantop@xxxxxxxxx> 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.mackintosh@xxxxxxxxx> 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.mackintosh@xxxxxxxxx> 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 <oxwivi@xxxxxxxxx> 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.mackintosh@xxxxxxxxx> 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 <greg@xxxxxxxxx>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@xxxxxxxxxxxxxxxxxxx
>>>>>>>> Unsubscribe : https://launchpad.net/~ayatana
>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Mailing list: https://launchpad.net/~ayatana
>>>>>>> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~ayatana
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~ayatana
>>>> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~ayatana
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~ayatana
>>> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
>>> 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