[Texmacs-dev] dispatching of mouse events in menus

[david]

On Mon, Feb 10, 2003 at 12:56:33PM -0500, Dan Martens wrote:
> 
> When a menu button is pressed, what method is called to map a
> item/position to the scheme call which handles it?
>
> I am having a strange problem and that is when a menu item is
> clicked, it works if the actions requires it to generate a submenu.
> But if the item is a leaf node of the menu tree, then nothing
> happens.

I am not sure I will give you the answer you expect, but since Joris
asked me to answer your question quickly I will do what I can.

Menu item gadgets are of several kinds. You can see how menu are built
in progs/boot/menu.scm. Submenus are built using
'widget-pulldown-button-lazy' and 'widget-pullright-button-lazy',
which are factory functions for popup_button_rep (in popup_button.cc)
leaf menu items are created by 'widget-command-button-3' or
'widget-command-button-1' which are factory functions for
command_button_rep (in button_widget.cc).

Mouse events are dispatched by basic_widget_rep::handle(event) by
calling the virtual method handle_mouse(mouse_event). Note that
popup_widget_rep overloads handle(event) and explicitely delegates
mouse events to basic_widget_rep::handle(event) while in
command_button_rep, the handle(event) method from basic_widget_rep is
called by the inherited method attribute_widget_rep::handle(event).

  Note: popup_button_rep could probably use some cleanup there... but
  "if it ain't broken, don't fix it".

Now that we are sure that part is the plumbing is okay (it could have
worked up to now for some wrong reason), let us see how the
dispatching is done by basic_widget_rep::handle(event).

    void
    basic_widget_rep::handle_mouse (mouse_event ev) {
      string type= ev->type;
      SI     x= ev->x, y= ev->y;
      int    focus;

This sets focus to the index of the child 'widget' which contains the
point (x, y), or sets focus to -1 if none is found. The actual
computation is done in basic_widget_rep::handle_find_child.

      this << emit_find_child (x, y, focus);

This part is about sending synthetic "enter" and "leave" mouse events
when required. That ensures a widget will get a mouse event only if it
has received a "enter" mouse event and no "leave" mouse event since
then.

      if (type == "leave") focus=-1;
      if (focus != ptr_focus) {
        if ((ptr_focus >= 0) && (ptr_focus < N(a)))
          a[ptr_focus] << emit_mouse (ev, "leave");
        ptr_focus= focus;
        if ((ptr_focus >= 0) && (ptr_focus < N(a)))
          a[ptr_focus] << emit_mouse (ev, "enter");
        if ((type == "move") || (type == "enter")
            || (type == "leave")) return;
      }

Finally transmit the mouse event to the appropriate child. As long as
we stay in the realm of usual composite widgets (not editor widget,
that is) that should resolve to recursive calls of
basic_widget_rep::handle_mouse until the first child widget which
override handle_mouse(mouse_event).
    
      if ((ptr_focus >= 0) && (ptr_focus < N(a)))
        a[ptr_focus] << emit_mouse (ev);
    }

I encourage you to add some tracing statements in the handle_mouse
methods of basic_widget_rep, command_button_rep and popup_buttons_rep
to see how your mouse events travel in the plumbing and at which point
they get lost (if they do...).

Hope this helps...

-- 
David Allouche         | GNU TeXmacs -- Writing is a pleasure
Free software engineer |    http://www.texmacs.org
   http://ddaa.net     |    http://alqua.com/tmresources
   address@hidden  |    address@hidden
TeXmacs is NOT a LaTeX front-end and is unrelated to emacs.