[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
>> Wendler<ubuntu@xxxxxxxxxxxxxxxxx>  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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp