Recompile GTK/GDK and GDK message pump

[Tor Lillqvist <tml iki fi>]

Urbansound writes:
> 1) Is there a tutorial on recompiling all of or segments of win32gtk/gdk 

There are some. For instance this:
http://groups.yahoo.com/group/gimpwin-users/message/16330 . It isn't a
step-by-step recipe to follow blindly, you need to apply common sense
and understand what parts you can (and are expected to) adapt as
needed, and do so. On the other hand, you also need to understand what
adaptations will likely just cause confusion you...

> 2) The API/wrapper requires access back into the Glade/Gtk application 
> for callbacks which appears as having to hook into GDK's 
> \gtk+-2.6.8\gdk\win32\gdkevents-win32.c file.  Are there any examples or 
> schemes that might demonstrate shared access to GTK's message pump, such 
> that one can reliably exchange messages?

You could always try to manage with the built-in GTK+ filter
mechanism. You can install global filters or per-window filters. The
filters have this API (excerpt from gdkevents.h):

typedef void GdkXEvent;   /* Can be cast to window system specific
                           * even type, XEvent on X11, MSG on Win32.
                           */

typedef enum {
  GDK_FILTER_CONTINUE,    /* Event not handled, continue processesing */
  GDK_FILTER_TRANSLATE,   /* Native event translated into a GDK event and
                             stored in the "event" structure that was
                             passed in */
  GDK_FILTER_REMOVE       /* Terminate processing, removing event */
} GdkFilterReturn;

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

As it says, GdkXEvent on Win32 means MSG, and the GdkEvent is a
pre-allocated GDK event that you need not do anything with if your
filter func returns GDK_FILTER_CONTINUE or GDK_FILTER_REMOVE. The
filter function is free to do whatever it likes, for instance send
window messages.

filters are added and removed with this API:

/**
 * gdk_window_add_filter:
 * @window: a #GdkWindow
 * @function: filter callback
 * @data: data to pass to filter callback
 *
 * Adds an event filter to @window, allowing you to intercept events
 * before they reach GDK. This is a low-level operation and makes it
 * easy to break GDK and/or GTK+, so you have to know what you're
 * doing. Pass %NULL for @window to get all events for all windows,
 * instead of events for a specific window.
 * 
 **/
void          gdk_window_add_filter            (GdkWindow     *window,
                                                GdkFilterFunc  function,
                                                gpointer       data);
void          gdk_window_remove_filter         (GdkWindow     *window,
                                                GdkFilterFunc  function,
                                                gpointer       data);

> 3) Else, is there a doc file, that explains the threading approch or 
> interfacing with gdkevents-win32 method?

(What threading? There is no threading involved in gdk/win32.) 

Not really, the source is the documentation ;-)

> A .c based example of the callback configuration is provided below, 

>  SendMessage(listbox, LB_ADDSTRING, 0, (LPARAM)"L1 Callback");
>  SendMessage(listbox, LB_ADDSTRING, 0, (LPARAM)Get_secsym(quote));

Hmm, does this mean that you are overriding the default behaviour of
some Windows Common Controls (is that still the correct term to use
for the "native" widget set?) listbox? If you want to customize a GTK
equivalent to a listbox (don't recall off-hand what widget type that
is), using GDK filters sure sounds like a wrong approach. But just
adding strings to a GTK+ "listbox" surely is covered by its normal
API, no need for anything fancy.

--tml