Re: Xwindow as GTK Widget
- From: Owen Taylor <otaylor gtk org>
- To: gtk-list redhat com
- Subject: Re: Xwindow as GTK Widget
- Date: 20 Jun 1998 19:16:39 -0400
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]