On Thu, 26 Jul 2001, Jim Knoble wrote:
> : and the universal way to close any menu is the same at present,
> : unlike under your proposed system.
>
> Actually, the way things are currently (blackbox-0.61.1) is a bit
> inconsistent and produces unnecessary excise in several cases:
>
> Applications menu:
> Open: [RightClick] on root window
> Close: [RightClick] on menu or menu titlebar
>
> Workspaces menu:
> Open: [MiddleClick] on root window
> Close: [RightClick] on menu or menu titlebar
>
> Window-titlebar menu:
> Open: [RightClick] on window titlebar
> Close: [RightClick] on window titlebar
>
> Submenu (attached to parent):
> Open: [LeftClick] on parent menu item
> Close: operation not available. [RightClick] on submenu or submenu
> titlebar closes both the submenu and its parent, while
> [LeftClick] on the parent menu item has no effect.
>
> Submenu (torn off from parent):
> Open: operation not available (already open)
> Close: [RightClick] on menu or menu titlebar
The common way to close any menu is to right click on the menu. I
personally feel that left clicking on the parent (the root window
being the parent for the workspace menu and the root menu) should also
close the menu, but this is not consistent (submenus, toolbar). I am
working on some patches to improve the consistency.
> From the perspective of some users, there's no reason that
> [MiddleClick] on the Workspaces menu ought not to make the menu go
> away, since both the Applications menu and the Titlebar menu behave
> that way (i.e., the same mouse button that opens the menu closes it).
> Yet middle-clicking appears to do nothing.
The workspace menu is a remnant from when you generated it by pressing a
button on the toolbar. When I first wrote the patch that changed this, a
middle click simply opened this menu in a different spot. Because you can
access the workspace menu from the root menu also, keeping all close
behaviors the same is the best path.
> In the same vein, one might expect that [LeftClick] on a submenu's
> parent item would close it. Nope. It remains open. How do i close
> it?
The submenu is still connected to the parent. To get rid of the submenu,
select something else on the parent.
> From a different perspective, one would expect that that [RightClick]
> on a submenu would make the submenu go away; yet it makes the whole
> menu tree go away. This excise turns into user-interface agony when i
> pin the Applications menu and then accidently sweep my mouse over it: a
> submenu opens up, and i have no obvious way to close the submenu
> without either (a) also closing the whole Applications menu (and having
> to re-open the menu and pin it again), or (b) first tearing off the
> submenu, then closing it.
>
> Obviously, putting close buttons on pinned (torn off) menus' titlebars
> won't solve these problems. I merely point them out to show that
> things that may look consistent often aren't. Careful design of menu
> behavior can solve these problems.
Thats my point, close buttons dont really solve any problems with
consistency, and they dont provide complete redundancy for closing menus.
> Circa 2001-Jul-25 22:45:21 -0400 dixit Gregory J. Barlow:
>
> : That the menu is visible suggests that its torn off. My point is
> : far from moot.
>
> Nope. That the menu is visible suggests that it's open. Not all
> visible menus are torn off (viz. the titlebar menu, which can't be torn
> off at all).
The only way a submenu can exist on its own is to be torn off.
> : Consistency is pretty important, and adding a close button is not
> : only inconsistent, its just redundant.
>
> Then a close button is redundant on a regular window as well, since
> there's a perfectly good "Close" item on the titlebar menu. Likewise,
> the resize handles, since [Meta+RightClick] can resize a window.
Thats right. But a close button does not give complete redundancy, the
other two almost universally do (unless the window doesnt want them).
> : However, when I first commented on this, I was speaking about
> : the status quo.
>
> Ah. The discussion i believed that i was taking part in was about how
> to improve the behavior of torn-off menus, partially in the context of
> keyboard navigation. I wasn't aware you were taking part in a
> different discussion. Perhaps that's the source of our
> misunderstanding.
Now I am speaking about making changes, but in the beginning I was
speaking only about the status quo.
> Then please give some references to back up your opinions.
See the rest of this discussion.
--
Gregory J. Barlow [EMAIL PROTECTED]
336.558.7231 http://barlow.ncssm.net
