Re: [gtk-list] Re: Patches for gtkwidget.[ch]
- From: Kent Schumacher <kent structural-wood com>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Re: Patches for gtkwidget.[ch]
- Date: Thu, 02 Mar 2000 07:54:16 -0600
Tim Janik wrote:
> On Wed, 1 Mar 2000, Kent Schumacher wrote:
>
> > Hi,
> >
> >
> > The signal simply allows triggering a widget signal handler and passing data
> > through it. In other words, an application would connect a signal handler
> > for to a widget for the "user_action" signal.
> >
> > The user_action handler has the signature
> >
> > void handler(GtkWidget *w, gpointer emitter_data, gpointer data)
> >
> > The signal handler can be triggered anywhere in the application by
> > using the function.
> >
> > gtk_widget_user_action (GtkWidget *widget, gpointer emitter_data)
> >
> > This allows the emitter to trigger a widget with arbitrary data.
> > I feel this is needed this for easily triggering widgets via menu-item,
> > toolbar-button, and keypress. Currently doing this is simply too
> > unwieldy.
>
> i don't think this is a good idea for gtk proper, for one this signal
> is impossible to wrap by language bindings (due to the generic pointer),
> and then some users may want varying signals, e.g. one with a return
> value etc...
OK, I can see this. For my application sending a gint would be adequate.
>
> second, we don't need to integrate this into gtk proper, just create
> your signal with gtk_object_class_user_signal_new() (omitting the
> default hanlder portion) without modifying gtkwidget internals, to get
> the same effect.
I'm not sure I understand how gtk_object_class_user_signal_new() works.
My guess is that an object needs to be created (i.e. gtk_button_new())
before a gtk_object_class_user_signal_new() can be used. If this is the
case, I feel this is too unwieldy. My application has several hundred
..._new() calls for focusable widget. The only commonality is that they
all inherit from GtkWidget.
I know it is possible for me to go and chase down every ..._new() call and
add the signal, but I have a hard time understanding how this is more
desirable than adding an additional
Note that I feel there needs to be some necessary glue in gtk to make
it easy to ubiquitously trigger events on a widget regardless of whether
the source is menu-item, toolbar-button, keypress, voice-activation,
bar-code reader, dart-gun, whatever.
Thanks for the quick response,
Kent
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]