Re: Submenu navigation status?

[Mrcooger <mrcooger cyberverse com>]

On 1 Sep 2000, Owen Taylor wrote:

>   
> Well, mostly on the side of code cleanliness, I definitely see
> a reason - the navigation region is basically state for a
> particular menu. Motion events in other menus should not
> be interpreted with respect to the navigation region.
> 
> To 'prove' that the current approach leads to problems, I've
> identified at least 2 bugs prominent with it:
> 
>  - If another menu is popped up before the navigation region
>    is removed in the timeout, then the navigation region
>    will be leaked. (OK, this has nothing much to do with
>    the location of the navigatio region...)
> 
>  - if the menu that currently has the navigation region is 
>    destroyed before the navigation region is removed, your
>    code will segfault. The easiest way to solve this is 
>    to put the timeout ID in the GtkMenu structure, and once
>    you do that, you might as well put the reion in there
>    as well.
>  
> Anyways, to save you the task of rewriting it in such a 
> repugnant way ;-), I've done so myself. My revised version
> of the patch follows.

Well, when you state it like that, it does make more sense to make it part
of the GtkMenu structure. Also, never ran into that segfault problem,
good thing you found that. :)

> Doing this turned up some oddities in the event handling
> for menus that made it a little less straightforward than
> one might expect. But the comments I've added should help
> people understand what is going on in the future.
> 
> > There was some discussion (between David and Nils Philippsen) about
> > making the hysteresis timeout be user-definable, which could be
> > done in an ad-hoc way (patches welcome, I'm sure), but...I agree with
> > David that it's better to work on a general gtk config system, rather
> > than causing API bloat with 200 functions of the form:
> > gtk_..._[get,set]_minor_feature
> 
> As you say, this should be done (if at all) as part of a
> general customization framework.
> 
> I'm not completley sure that the current timeout approach
> is perfect - if I move slowly on the diagonal, sometimes
> the timeout will trigger when it shouldn't. It might
> be good to use a slightly shorter timeout and then 
> reset it on motion events in a way such that it is dependent
> on the speed of (vertical?) motion.

I disagree here, though. I played around with that when I was first
working on it, and I think the current approach is very good. The
idea is to allow users to be a little sloppy when they head down to a
submenu, especially when they are going fast. I think when this is working
right, most users won't even realize that this is happening, in their
minds the menu item under the mouse is always selected, and they're
"hotshots" with getting into submenus. It's too easy to get into
situations where the mouse is subtly moving diagonally, but though the
user doesn't intend to head into a submenu, the menu items aren't
switching (Especially with very tall submenus).  
 
> ====
> +  send_event.crossing.window = gdk_window_at_pointer (NULL, NULL);
> +  send_event.crossing.type = GDK_ENTER_NOTIFY;
> +  send_event.crossing.time = GDK_CURRENT_TIME;
> +  send_event.crossing.send_event = TRUE;
> +
> +  gtk_widget_event (GTK_WIDGET (user_data), &send_event);
> ====
> 
> I don't think this was working at all - the widget that 
> needs to receive the enter event is the menu that is the
> parent of the menu item (user_data), and gtk_widget_event()
> doesn't do event propagation up the widget heirarchy.
> 
> I didn't spend a lot of time tracing this down since I did
> things a bit differently, but I think that this just appeared
> to work because gtk_menu_motion_notify() was (because of
> an old bug) continually sending enter events.

Hm. Well, I specifically remember the timeout not selecting the menu-item
under the cursor after the time expired (unless you moved the mouse
yourself) until I added that code (and it was only that code that I
added). No matter, your version is better anyhow; I simply copied that
code more or less from gtk_menu_motion_notify(), and it started working.
:) 
 
Yay! 

David