Re: Submenu navigation

[Nils Barth <nils_barth post harvard edu>]

Thus spake Johan Hanson:
> Nils Barth wrote:
> > Thus spake David Santiago:
> > 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.
> 
> No, there is no triangular area overlaying Macintosh's menus.
> If there were, then there would be a noticable delay when moving the cursor
> downwards over the items in the parent menu, and there is no such delay.
> 
> The "triangle" is only relative to the cursor's previous position, i.e.
> for as long as the mouse motion is towards the submenu and the timeout
> has not expired the submenu will remain open.

Right! The ``triangle'' area is dynamically created.
Kim has been working rather privately on submenu navigation at:
http://www.kimmccall.com/navigation/

Basically, Macs navigate submenus as in Figure 7 on the above page.
Well, kinda.
That is, when a mouse leaves the menuitem, the keepup region is
created, as in figure 7.

Note that this is not as in figure 1, so if the mouse just moves
straight down, the submenu collapses (i.e., there is no static
overlay a la fig 1).

The keepup region then stays fixed until it either times out (with a
rather long delay) or the mouse exits the region/enters the submenu.

Thus, Macs have a very simple mechanism, which seems to work fine and
is pretty light on resources.
It could be improved by resizing the keepup region so the mouse had to
keep moving towards the submenu (no move towards submenu, then move
back), though this is pretty subtle/rare. Still, it's prolly a good
idea.

> > 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).
> 
> Or, you could call "gdk_pointer_grab()" for the menu item's window and
> only the menu item will recieve events until you call "gdk_pointer_ungrab()".

Oh, that's so much better!
Alright, I'll see if I can fix this tonight.


> While we are at it discussing improvements to GTK's menus, I have a couple
> of other suggestions:
> 
> * Scrolling when the menu becomes too large.
>   Macintosh has arrows at the tops and/or bottoms of large menus, indicating
> that
>   there is more to see. However, Macintosh's menus don't show how many items
> there are.

also a TODO item. Good point about how many items there are -- you can
get lost in a big menu.
Maybe something like the number of menuitems remaining in each
direction should be drawn next to the arrows?
Or little percentages?

One other problem with the Mac:
the menu size doesn't change, nor do the size of the arrows, so if you
scroll over a separator (or other weird sized menuitem), the menu gets
messed up and at the ends you get half-exposed menu items.
This is kinda ugly.
I suggest scrolling by one menuitem at a time (instead of the expect
HEIGHT of a menuitem, a la mac), and then resizing the arrow (or
menuitem containing the arrow) at the OTHER end of the scrolling.

Errr...was that unclear? Would a picture help?

>   Motif (or is it just Netscape?) has the worst solution to this problem: the
> last menu
>   item is a submenu item with the title "More ...".

I think it's all Motif apps.
Yes, this is the most hideous UI design I've seen (save maybe for
overlong menus in Win9x's start menu).

>   Maybe we would like something like a GtkCombo, i.e. a menu with a scrollbar
> inside it.

Hmmm...that seems a bit heavy -- if a menu's longer than twice the
screen, it should probably be restructured into submenus.
Also, if you have fast enough scrolling (like on mac popup menus),
that should be good enough.

(Minor gripe: Macs have different scrolling behaviour on dropdown
menus vs. popup menus. The former have two speeds, slow and medium,
where you scroll slowly if you're slightly inside the arrow, and
medium speed if you're far into the arrow. In popup menus, by
contrast, you have only one scroll speed: FAST.
I like the idea of two-level speed, but I think the fast speed should
be FAST like the popup menus.)

> * Move tear-off menus up a notch in the default position function:

This is fixed (kinda) in my most recent patch -- the position function
now depends on:
/* SUBMENU_OFFSET specifies by what percent of a menuitem height
 * a submenu is vertically offset. Should vary between 0 and 1.0.
 * (I guess -1.0 to 0 range is okay).
 * GTK currently defaults to 0.25 -- other windowing systems default
 * to 0.
 */
#define GTK_SUBMENU_OFFSET 0.25

Currently GTK sets it to 0.25 (I don't change that), but everyone else
uses 0, and I could imagine one setting it slightly negative if you
want.
If we apply the patch (or similar) and then someone hacks gtkrc so
that it can be set in .gtkrc, then this could be user-settable and no
longer an issue.

Of course, maybe this is bad behaviour that no-one wants and we should
just have it set to 0 like the rest of the world. (kill 2 lines of code).

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

PGP signature