On Wed, 25 Jul 2001, Jim Knoble wrote:
> Circa 2001-Jul-25 13:24:48 -0400 dixit Jeff Raven:
>
> : On Wed, Jul 25, 2001 at 12:52:42PM -0400, Gregory J. Barlow wrote:
> : > I am unclear on where the marker would go, on the torn menu
> : > itself, or on the menu a level up, showing it was torn. I see no
> : > reason to specially label the torn menu itself or to put a close
> : > button on it.
>
> I do; i've already explained why. Not putting a close button on the
> torn-off menu's titlebar is like not putting a handle on a glass door:
> it's virtually impossible to tell it apart from a large window.
> Putting the handle on it shows two things: (1) it's not a window, and
> (2) how to open it. It's good design.
Putting a close button on a menu titlebar is not a consistent way to close
the menu; window menus do not have titlebars. Right clicking on a menu to
close it can also be done at any stage, whether the menu is torn or not.
> : > Labeling that a menu has been torn off and is hence not accessible
> : > would be useful.
>
> No, it wouldn't. Why should a torn-off menu not be accessible from its
> parent menu? What if i forgot that i tore that menu off? When you
> make the menu inaccessible, even though i usually access it from its
> parent menu, that's called "excise", and it's bad design.
If you bothered to look, torn off menus _are_ inaccessible from parent
menus. I would prefer that they be accessible, but my point was centered
around the current state of affairs. By the way, you seem to have a
fairly definitive idea of good/bad design. You need to realize that you
do not define the merit of a design for the rest of us.
> : > In addition, it might be nice if one could unpin a menu by
> : > clicking on its currently nonfunctional entry one level up in the
> : > menu system. That way, if a menu has been torn off and one wants
> : > to access it, one doesnt need to locate the menu on the screen.
> : > This also provides a way to remove menus which have strayed off
> : > the screen by the method described a few weeks ago on this list.
>
> That's actually a good idea (except that the menu entry ought still be
> functional). Better to make a modified click do that, e.g.:
Adding keybinding modifiers to the window manager is problematic, as we
already know. I don't know the right answer here, though I would prefer
the simplicity of a left click simply closing all open copies of a submenu
and opening a new one.
> (On Submenu)
>
> [LeftClick] -> open the submenu
> [Enter]
>
> [Control+LeftClick] -> close any torn off copies of this submenu
> [Control+Enter]
>
> You get the idea. The root window maybe ought to do the same for
> pinned top-level menus.
I prefer the current behavior on the root window, in which a left click
will clear all open top level menus.
> : Hmm. Interesting thought.
> :
> : One problem is that clicking on a menu item which has a submenu
> : can already have a meaning... The workspace menu, for instance,
> : uses it as a signal to move to the appropriate workspace. But
> : if you tear off that workspace's submenu, and then click on the
> : workspace's name in the workspace menu, what is the reasonable
> : behavior? Move to the workspace? Show the torn menu?
>
> There's not really any reason not to open another copy of a torn-off
> menu when its item is chosen in the parent menu. This could be
> particularly important for keyboard navigation of menus.
See previous messages re: "this will only add a few kb to blackbox"
> : Ugh. So many wrinkles to deal with. This is going to take a lot
> : more thought on my part...
>
> Good user interfaces require a lot of forethought. I'm sure we're all
> glad to see you forethinking, Jeff, and to help you when you need it.
I tend to prefer simplicity. Blackbox is one of the few window managers
where one can really get that. I just hope that is kept in mind.
--
Gregory J. Barlow [EMAIL PROTECTED]
336.558.7231 http://barlow.ncssm.net
