Re: Xwindow as GTK Widget




Jay Painter <jpaint@serv.net> writes:

> Just a personal opinion here, but it would be useful to add some hooks
> into GDK to help support plug-in graphics libraries like this.  This could
> be done by:
> 
> 1) if a flag is set for a widget, have an additional callback with the X
> event; this would be just a void pointer to GTK so the abstraction level
> isn't broken.

It's basically there:

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

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

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

 void	      gdk_window_add_filter	(GdkWindow     *window,
					 GdkFilterFunc	function,
					 gpointer	data);

It's on a per-window not per-widget basis, but I think this is
probably OK for circumstances where you want the capability.

> 2) make gdk aware of the "create child window" events in X, and
> automagicly associate those X windows with the widget's window they were
> created on top of so X events get propagated to the correct widget.

This sounds too complicated to be an automatic feature for all
windows. This is basically how GtkSocket works, but it doesn't
select for arbitrary events on the child window.

(If events for a window that is not a GTK window get sent on
 to GTK, GTK tends to get quite confused. Imagine what happens
 when it receives a DestroyNotify event for the child window,
 and it thinks it occured for the widget. This stuff probably
 can be fixed up, but I'm not so sure it is worth it)

Regards,
                                        Owen



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]