RFC: general event filters for GDK

[Owen Taylor <owt1 cornell edu>]

Comments?

Proposal: General event filters for GDK
---------------------------------------

Several recent extensions to GDK have involved adding
extra processesing for events on some, but not all windows.
In particular, the XInput and DND code come to mind.
Partly because of this, the function gdk_event_translate()
is now over 1000 lines long.

What I'd like to propose is adding a something like:

 gint gdk_window_add_filter (GdkWindow *window, 
                             GdkFilterFunc *func, 
	                     gpointer data)

 gint gdk_window_remove_filter (GdkWindow *window, gint tag);

and probably the corresponding _interp function.

With the definitions:

  typedef void GdkXEvent;   /* Can be cast to XEvent */

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

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

Before doing standard event processesing the filters for the
window would be executed in sequence, until one of them returned
something other than GDK_FILTER_CONTINUE. If the return
value is GDK_FILTER_TRANSLATE, the filter has stored the
translated event in 'event', and it should be returned to the
application program. If the return value is GDK_FILTER_REMOVE,
the event is discarded.

In some cases it is desirable to do something for events on all
windows. (For instance, the XInput code needs to look for
events with Window = None). This could be specified by calling
gdk_window_add_filter with window == NULL.

It might be also nice to have a function:

  gdk_window_add_filter_after (GdkWindow *window, GdkFilterFunc *func, gpointer data)

It's a slight performance win to not have to check the type of
common events. There might also be cases where the semantics would
be desirable.

Having _interp() functions would be mostly for consistency, since
to write filters in a different language, that language would
have to have a way of dealing with XEvents. 

Although I see this primarily an internal gdk interface, it is
also very useful for clients that want to deal with XEvents 
directly, bypassing GDK. I think it could replace the current
GdkEventOther scheme, which is considerably less flexible.


Disadvantages of this scheme:

It might encourage people to do low-level things directly instead
of adding higher-level functionality to GDK. (We probably should
stick to the rule of no X functions and no X events in GTK)

It adds another type of callbacks which are not signals. (Pretty
much a non-issue I think - since the whole point is having
access to events below the level of GTK.)

Each event has to go through all filters. It would be possible
to set things up so that filters could be specified for specific
event types, but I'm not sure there would be that much 
performance advantage, if the filters are written carefully.