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

[Todd Dukes <tjdukes flash net>]

This will not cause me any great problem at this time, but 
it will later. So my vote is to go ahead and do the change.

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--. 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. Can this issue be addressed at this time also.
A simple convention of renaming the member functions when there 
is a collision should be sufficient. I think renaming the signals
would be difficult at best.

Todd


Tero Pulkkinen wrote:
> 
> This message is a forward warning to everyone who is making
> applications with gtk--. There's quite large change planned to gtk--'s
> signal system that will break every gtk-- application. If the change
> will be made, it'll be in next release of gtk-- and you should reserve
> some time before upgrading to next gtk-- version.
> 
> The problem:
> We've had 3 different connect() function formats available depending on
> if you're using connect() to static functions, member functions or
> function objects. The format of the different connect() calls have been
> different and this has caused constant confusion.
> The 3 connects were in the following format:
>   connect(signal, &function); // for static or file-scope functions
>   connect(signal, functionobject);    // for function objects (notice, no &)
>   connect(signal, obj, &fooclass::method);
>                               // for methods
> 
> These different formats of overloaded connect() functions cause the compiler
> give odd looking error messages and are constant source of confusion in
> use of the connect() functions. Also there's worse problems with adding
> extra arguments to connect calls as they're ambiguous with other types
> of connect() calls:
>    connect(signal, functionobject, extra_arg)
>    connect(signal, obj, &fooclass:method)
> The compiler cannot identify with some types of functionobjects between
> choosing functionobject version + extra argument or choosing connecting
> to a method.
> 
> The sollution:
> The change is to make it explicit which type of connect() function we're
> using. Thus the previous examples will become:
>   connect_to_function(signal, &function);
>   connect_to_signal(signal, functionobject);
>   connect_to_method(signal, obj, &fooclass::method);
> 
> This change will hopefully make it easier for people and for the compiler
> to handle these different types of connect() functions.
> 
> For practical reasons I dont want to leave the old connect() calls inside
> gtk--, as then people will use them still and we'll have more code in our
> hands that must eventually be changed.
> 
> So, I'm asking your opinions, if this change should be made and how
> much problems it'll cause to the users of gtk--. Naming issue is not
> absolutely clear yet either, especially with connect_to_signal() vs
> connect_to_functionobject().
> 
> Any opinions are welcome.
> 
> --
> -- Tero Pulkkinen -- terop@modeemi.cs.tut.fi --
> 
> --
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null

-- 
-----------------------------------------
Todd & Lisa Dukes
tjdukes@flash.net