Re: Submenu navigation

[David Santiago <mrcooger cyberverse com>]

On Wed, 24 May 2000, Nils Barth wrote:
> Agreed.
> Indeed, do you know if anyone is working on a GNOME UI guidelines
> document?
> Similarly, is there a UI behaviour document that describes how
> GTK/GNOME widgets/apps work? A little non-technical thing that
> included stuff like what different buttons do to spin-buttons?

No, I don't. It's really pretty universal stuff, I think though. Different
GUIs aren't as different as everyone likes to think, and you could learn a
lot about designing better interfaces for any platform for reading that. 
 
> 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). 
 
> 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. 

> > Another idea would be to dig up the Mozilla source code. You may have
> > noticed that their submenus have this behavior implemented very nicely. I
> > haven't looked into this at all, though. 
> 
> Haven't thought too much about it -- the Mac design seems to be
> correct, though the Mozilla code might give implementation ideas --
> thanks!

Yes, I was speaking only about the implementation ideas. 
 
> So actually, your patch seems to act more like the Windows behaviour,
> which is 1/2 right.
> However, if you made the delay instead come at the beginning, before
> the menu comes up (so pause the appearance, not the disappearance), we
> would have mac-like submenu drawing, which would be lovely.

Well, as I said, it's not done, so of course it doesn't have the right
behavior. I was merely saying, I have the first step. As I said, there
already is a delay in the appearance. What is more complex is moving from
one menu item to the next, which means you must leave the submenu up on
the screen for a brief period before popping up the next one, so the user 
can "cut the corner" as he goes to the submenu items. What are the
criteria for actually popping up the next submenu, or cancelling the
whole thing altogether and letting him stay on the original item, I have
not done any work for. 

> > As you can see, I'm very much looking forward to this feature. 
> > 
> > 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. 

Then again, I could be wrong
  - David