Re: [gtk-list] new signal GtkWidget::user_signal?

[Owen Taylor <owt1 cornell edu>]

Tim Janik <Tim.Janik@Hamburg.Netsurf.DE> writes:

> hello everybody,
> 
> i'd like to have an additional signal supported by the GtkWidget base class.
> 
> GtkWidget:user_signal
> 
> this signal will be invoked by the application programmer and not inside the
> toolkit.

I must admit that my initial reaction to this was "ugh".

There does seem to be a need (or at least a perceived need) for
this type of functionality.

- people want to build "pseudo-widgets" without going through
  all the trouble of building a real widget, and add new signals
  to them.

- writers of language bindings want to be able to derive
  new widget types and add signals without having to extend
  the class structure.

Your facility to some extent does meet these requirements, but
not very gracefully, since the resulting signal will be quite
non-standard, from the users point of view.

I'm not terribly sympathetic to using this facility within
a single application. A function call would be more appropriate
/efficient in almost any circumstance. 

Perhaps we should instead look at how to enable the user
to add new signals without modifying the widget.

gint
gtk_signal_new (const gchar         *name,
		GtkSignalRunType     run_type,
		gint                 object_type,
		gint                 function_offset,
		GtkSignalMarshaller  marshaller,
		GtkType              return_val,
		gint                 nparams,
		...)

The problem here, is function_offset. But since this
can never be zero, why not make function_offset = 0 =>
no default handler.

What if you do want a default handler? In that case
we'd to provide an alternative interface. But this only would
come up when defining new widget types, since the default
handler is per widget class, not per widget.

Doing this provides a more complicated interface to the person
definining the new signals, but a easier interface to the
person using them. (And allows them to be used in multi-language
environments, where your proposal won't work because of the
gpointer argument)

But I'd like to here more about what you want to use this 
facility for. And what do other people think about this
proposal?


A few comments on the original proposal:

> it can be invoked with a call to
> 
> void	gtk_widget_emit_user_signal (GtkWidget *widget,
> 				     gint       user_type,
> 				     gpointer   signal_data);

Why not simply:

gtk_widget_emit_by_name (widget, "user_data", user_type, signal_data)

OK, it isn't type safe, but neither is anything else about
the existing signal system.

[...]

> one can connect to the signal as usual via
> 
> gtk_signal_connect (GTK_OBJECT (MyButton),
> 		    "user_signal",
> 		    GTK_SIGNAL_FUNC (MySignalFunc),
> 		    my_func_data);
> 
> or via
> gtk_widget_set (MyButton,
> 		"GtkWidget::user_signal", MySignalFunc, my_func_data,
> 		NULL);
> 
> 
> user_type is meant to distinguish different signal emissions by passing
> a.g. an enumeration value that MySignalFunc() could switch() on.

There is the typical "namespace registration" problem here -
if two different entities use the same value for the same widget
there will be problems.

If you defined a new signal type (or specified user signal types
by string - which might be preferable), then this would be
less of a problem.

Regards,
                                        Owen