Re: [gtk-list] Signal and event management.

[Tim Janik <timj gtk org>]

On Wed, 2 Dec 1998, Enric J. wrote:

> Hi all,
> 
> I'm new in this list, this is my first post, and I do it because I have
> some doubts that need expert advice.
> 
> A group of friends an me, are working on yet another OO wrapper for Gtk, it
> is being designed for Object Pascal, our final idea is to make a clone of
> Delphi (or something similar), well, the doubt I have, is that I want to
> receive a notification of every single event sended to any GtkWidget, that
> way, I can re-direct it to our own hierarchy of widgets, I've readed the
> Gtk sources (1.0.6 version), and the ways I find to do it, are,
> 
> 1.) asking a connection for the event "event" for every widget I create,
> this is right, and I get them, but I receive raw events, not Gtk signals,
> if I use this, I must to "translate" every received event to a GtkSignal
> and dispatch it to our widgets. I don't like it because there are other
> signals that I can not receive capturing the event "event", i.e. the
> TICTACTOE signal in the tictactoe.c example.
> 
> 2.) hooking my signal dispatcher to the gtk class default signal handlers,
> this works, but I don't know if this is a correct way to do it.
> 
> What I don't want is to ask gtk for 50 or more signal_connect with every
> gtk widget created, I prefer to have a global handler for all signal and I
> will decide what signal to send or ask for the default processing.
> 
> There is an elegant way to do it ?, if so, Please could anyone explain me
> how to do it.
> There is any contra-indication in doing it the way I say ?
> 
> I've readed the sources and all documentation I have, but I can not find
> any more knowledgeable answer, I don't want to bother but I really don't
> know where I must loof for answers.
> 
> If you have any questions or want some aclarations, Please ask me.
> 
> Thanks for any info about this matters.

i guess, what you want is gtk_signal_set_funcs(), with that you do all
of your signal connections with a function pointer of NULL.
you have to setup the data you pass into the signals to contain the
function pointer and the data you'd normally pass, e.g.

typedef struct { gpointer f; gpointer d; } SD;
static void marshal (GtkObject      *object,
                     gpointer        data,
                     guint           nparams,
                     GtkArg         *args,
                     GtkType        *arg_types,
                     GtkType         return_type)
{
  SD *d = data;

  /* use some kind of own marshaller here, most signals take special arguments */
  d->f (object, d->d);
}
static void destroy (gpointer data)
{
  SD *d = data;
  g_free (d);
}


SD *d;
guint h_id;

gtk_signal_set_funcs (marshal, destroy);
d = g_new (SD, 1);
SD->d = data;
SD->f = func;
h_id = gtk_signal_connect_object (object, "some-signal", NULL, d);

then, when you
gtk_signal_emit_by_name (object, "some-signal");
marshal() gets called. destroy() gets called upon destruction of the
object or if you disconnect h_id.

the signal connections Gtk+ uses internally do all pass a valid function
pointer upon connect, so you will only trap those signals that you really
want to. this mechanism of course only cares about handler connections,
to override the real class functions, there's no way around altering the
class pointers.
if you just need the possibility to connect pascal or c-wrapper handlers
to the widgets so your third-party code gets called, the global marshaller
approach is probably good enough.

i don't know what exactly you need to achive on the widgets, for GLE (a
layout engine for gtk on GNOME cvs), i pretty much get away with connecting
to special signals only, i.e. draw or size-allocate, since any parameters
that are applied to widgets and take visual effects have to go through
these signals at some point.
if you, for some reason really need to trap all signals on a widget, there's
only the possibility of signal emission hooks left, which can be used to
connect hook functions (with certain restrictions) to a signal of a 
specific widget type. the function will then be called for all widgets
that emit this signal at some point. though, the emission hooks are still
under development, and do not have a committing API yet (that'll probably
be the case after the next weekend or so).

that's basically all there is about trapping gtk signals, after you got
an idea on what possibilities are provided, i hope you can find out
which one fits your needs best, or what's still missing from Gtk+'s 
signal system in your opinion.

> 
> Enric.
> 

---
ciaoTJ