Re: [gtk-list] Re: Large change to gtk-- signal system!
- From: Guillaume Laurent <glaurent worldnet fr>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Re: Large change to gtk-- signal system!
- Date: 26 Apr 1998 08:48:31 +0200
Todd Dukes <email@example.com> writes:
> However, there is another issue. With the naming convention you have
> choosen for the signal names and function names there is the
> capability for name collisions between gtk+ and gtk--.
No, there isn't. I did the same confusion when adding bindings for
Gtk_CList, and even bothered Jay about it :-).
When a signal and its related function have the same prototype, you
can use the signal in place of the function.
See Gtk_Widget for instance. GtkWidget has a "show" signal, and there
is gtk_widget_show(). But there is only a show() signal in Gtk_Widget,
which you can not only connect() to, but also call directly like any
The problem with Gtk_CList was the same at first (ie no real problem,
just me being stupid, only the signal was needed), but this has
changed since the "select_row" signal and gtk_clist_select_row() don't
share the same prototype anymore. Therefore Tero added a
> An example I am aware of is with Gtk_Tree. There are member
> functions select_child() and unselect_child() to allow the
> programmer to select or unselect items. There should also be signals
> select_child and unselect_child to inform the programmer when the
> user has selected or unselected a child. These are not present. I
> assume this is because they cause a name collision.
In this particular example, no, it's not. The problem is not a name
clash, the problem is that gtk-- "C" signals can't have gtk-- classes
For instance, GtkTree's "select_child" signal takes a GtkWidget* as
argument. Therefore, the select_child() signal in Gtk_Widget should
take a Gtk_Widget*. This we can't do (yet, I'm working on it).
You have the same problem with the "add" signal in GtkContainer, and
in a couple of other places.
P.S. Please trim your quotes a little, thanks :-)
] [Thread Prev