Re: [gtk-list] Re: Large change to gtk-- signal system!

[Guillaume Laurent <glaurent worldnet fr>]

Todd Dukes <tjdukes@flash.net> 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
other method.

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
cause_select_row() method.

> 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
as arguments.

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 :-)

-- 
					Guillaume.
					http://www.worldnet.fr/~glaurent