Re: Submenu navigation

[Nils Barth <nils_barth post harvard edu>]

Thus spake David Santiago:
> On Wed, 24 May 2000, Nils Barth wrote:
> > There are actually two separate UI issues, and MacKido confuses them a
> > little:
> > (1) Pause before menus are drawn (so less flicker when navigating)
> > (2) Easy selection of submenu items.
> > 
> > (1) shouldn't be too hard, and I haven't been working on it.
> > Basically, have a customizable timeout such that the submenu is only
> > painted/realized after the menuitem has been active for a short while.
> 
> Actually, this is already in. Look for the #define SELECT_TIMEOUT. It's
> just extremely short right now (75 milliseconds). 

Ooh...WOW that's short...that would be good to have user-customizable.

> > Your work seems to be in this direction, and I'd love it if you could
> > make a patch to that effect.
> 
> Actually, no, I was working on what you're working on. The first step to
> that is making it so that once the mouse leaves a menu item with an open
> submenu, the submenu isn't taken off the screen immediately. That's what I
> have done. I am unlikely to find time in the next month or so to keep
> working on this, though, so it's really rather useless. 

> > Fiddling with the Mac, I figured that the behaviour was actually as I
> > described. Here's some examples of what I did:
> > Go towards a menu item, then back up, wait around.
> > So long as you stay within the triangle, it doesn't die until the
> > timeout.
> > I originally imagined doing something with motion callbacks to see
> > that you were ``moving in the right direction'', but this is baroque,
> > and the Mac does it in a much simpler, equivalent way.
> > I think what I call the triangle, he calls the V-shaped buffer zone.
> 
> I'm not quite sure what you're saying, but it sounds like you mean that a
> submenu that has had it's parent menu item recently deactivated will stay
> on the screen a moment before disappearing. I don't see how this is
> different from what I'm saying. In any case, it's not important, because
> it appears to me that we are saying the same thing, and so I don't see
> what the argument is about. 

Oops -- I think I didn't explain properly; also, this should answer
the question as to how to 'cut the corner'.

On the Mac, when you leave a menuitem that has an active submenu, the
UI draws an invisible right triangle given by:
p0 = (x0, y0) - the point you left the menuitem
p1 = (x1, y1) - the lower left corner of the submenu
p2 = (x1, y0) - the corner where the menuitem runs into the submenu
(see attached picture -- I've also drawn the case where you exit the
top of the menuitem, in which case p1 is the upper left corner)

Now so long as the mouse stays inside the triangle, the submenu stays
up, until there's a timeout.

Phrased differently, the submenu stays up until the timeout, so long
as you are inside this triangle.

As I see it, we've been approaching in different orders: you
emphasizing the timeout first, then the cut-the-corner, I emphasizing
the cut-the-corner, then the timeout.

Hope the above is semi-coherent.

-------------------------------------------------------------------------

Implementation notes:
I was thinking of implementing that behaviour thus:
when mouse leaves menuitem, popup a rectangular window/region/widget
with corners p0, p1.
This window would be invisible, inactive, and would only serve to stop
mouse events from going through to different menuitems (so the
menuitem with the submenu would stay active).
The window would then die if:
the mouse left it, the timeout was reached, or the center diagonal was
crossed (i.e., the navigational triangle was exited).
Does this sound like a reasonable approach?
I have time to do this (a week or two -- exams are over!), but I'm not
familiar with how GTK does windows -- would you be able to help/offer
suggestions?

> > > Also, another thing. The TODO list states the item as "Improve submenu
> > > navigation", so another thing that frustrates me greatly in navigating
> > > submenus currently, and maybe someone else agrees with me: currently, you
> > > have to thread the mouse cursor through that little area between the
> > > right(or left) edge of the menu item with the submenu in order to hit the
> > > menu (David Every has a good diagram of this on his site). Well, GTK+
> > > currently makes the submenu jog down a few pixels from the top of the menu
> > > item it is born from. This makes the area even smaller. Both the
> > > Macintosh and Windows line up the submenu flush with the menu item that 
> > > is it's parent. I'm sure the argument could be made that once the submenu
> > > hysteresis is in place, this problem will go away, but still, I like all
> > > the help I can get. (Besides, it just doesn't look right to me). 
> > 
> > This should be user customizable, clearly.
> > I'll find out where this is set, move the magic number up to the top,
> > and leave a FIXME and TODO note for the people working on gtk
> > customization.
> 
> Yeah, I've already got this working the way I want in my local version of
> GTK+ (And some changes to the spacing of items in a menu bar, and a few
> other things...), I was just asking because I know it's unlikely to happen
> unless other people feel similarly. I suppose I could always patch up GTK+
> before I install it, but I wouldn't have asked if I didn't feel it was
> something other people might want. 

Agreed -- it's kinda cute, but many people (read: everyone who's used
a different GUI) will find it jarring and it's somewhat less usable,
especially now.
I've made a mini-patch that makes a variable/macro which specifies
by how much one wishes submenus to be offset, so the gtkrc gurus can
make it customizable.

-- 
  -nils
Public key: http://www.fas.harvard.edu/~nbarth/pub-key.txt

submenu2.png