Re: Status of my GTK efforts.

[Jan D.]

>     But Emacs sometimes want to handle the XEvent first before passing it to 
>     the toolkit.  So in order for this to happen, our filter function would 
>     return GDK_FILTER_REMOVE.
> 
> Sorry, you have lost me.  What is a filter function?  Whatis
> GDK_FILTER_REMOVE?  I don't know any details about GDK except
> what I can see in your messages.


GDK lets you insert a filter function for the windows you create by
calling gdk_window_add_filter(GdkWindow window,
                              GdkFilterFunc func,
                              gpointer data).

Then func will be called when the next XEvent is to be converted to a
GdkEvent.  It is called before GDK has done any conversion.

The GdkFilterFunc looks like this:

  GdkFilterReturn (*GdkFilterFunc)(GdkXEvent *xevent,
                                   GdkEvent *event,
                                   gpointer data);

The GdkXEvent* is the XEvent (why the name change I don't know),
GdkEvent* is the place where the GdkEvent will be stored,
data is what one passed in gdk_window_add_filter.

GdkFilterReturn is one of:
typedef enum {
  GDK_FILTER_CONTINUE,    /* Event not handled, continue processesing */
  GDK_FILTER_TRANSLATE,   /* Translated event stored */
  GDK_FILTER_REMOVE       /* Terminate processing, removing event */
} GdkFilterReturn;

GDK_FILTER_CONTINUE means that GDK should continue its normal processing.
GDK_FILTER_TRANSLATE means that the filter function has done all 
translation of the XEvent to the GdkEvent and that the GdkEvent can
be sent on to widgets.

GDK_FILTER_REMOVE means that GDK should skip processing of this event.  It is
currently the only way to tell GDK not to pass events to widgets.
It is also currently the only way to get hold of the XEvent when using
the GTK event loop.

So if Emacs needs to handle the XEvent before passing it to widgets,
it needs to install a filter function for all windows.

> 
>     Sa we basically need ether a gdk_xevent_to_gdkevent translation 
>     function, or even better, an gtk_act_on_xevent function, that 
>     corresponds to XtAppProcessEvent.
> 
> I think I understand that.  A gtk_act_on_xevent function sounds
> like the right solution.
> 
> If you could write a self-contained description of this issue,
> I can send it to the GTK developers.

How about this:

Currently in GTK it is very hard to write your own event loop.  This makes
it hard to integrate into code that uses X events and/or its own event
loop.

There is not an easy way to get the next event and later tell GTK to act
upon that event.  For instance, Emacs needs to handle menu events before
passing it to the toolkit that implemets the menu.  Emacs executes lisp
code before the toolkit gets to react to the event.  Other reasons for
having your own event loop is handling other input sources, signals handling,
e.t.c.  It seems a bit much that this would have to be changed also, just
because one wants to use GTK widgets.

GTK uses GdkEvents, so one would think this would work:

      while (gdk_events_pending())
        {
          GdkEvent* ev = gdk_event_get();
          if (ev)
            {
              gtk_main_do_event(ev);
              gdk_event_free(ev);
            }
        }

This, however, fails to pass the events to GTK widgets.

A solution that does pass events to GTK widgets is to override the GTK event
handler by calling gdk_event_handler_set with a function that copies
the event.  Then one can later pass the event to gtk_main_do_event.

But in order to be able to reuse old code, one really want the XEvent, not
the GdkEvent.  The only way to get the XEvent seems to call
gdk_window_add_filter for all windows created (I can imagine some GTK
widgets creating several windows, so just doing this is hard).
Then the XEvent is available for the filter function.

To prevent GDK from passing this event further on, the filter function
needs to return GDK_FILTER_REMOVE. In that case one have the XEvent, but
no GdkEvent to pass to gtk_main_do_event later on.

The solution would be if GTK/GDK could supply a function that takes
an XEvent and acts upon it, gdk_act_on_xevent for example.  It would
be the equivalent to the XtAppProcessEvent function in Xt.

A function like gdk_act_on_xevent would make it much easier to integrate
GTK into existing code.

        Jan D.