Re: Put g_signal_connect() back!



Owen Taylor <otaylor redhat com> writes:

> Tim Janik <timj gtk org> writes:
> 
> > On 8 Mar 2001, Havoc Pennington wrote:
> 
> > > The problem with this is the same problem with gtk_box_pack_start();
> > > boolean args are very unreadable.
> > > 
> > > i.e. if I have this code:
> > > 
> > >  g_signal_connect (instance, "foo", callback, data, TRUE);
> > > 
> > > it's much harder to see that data/instance will get swapped, because I
> > > have to have memorized the function prototype, it's much easier in
> > > this case:
> > >  
> > >  g_signal_connect_swapped (instance, "foo", callback, data);
> > > 
> > > enums or flags are also better than the boolean:
> > > 
> > >  g_signal_connect (instance, "foo", callback, data, G_SIGNAL_SWAPPED);
> > > 
> > > things are worse for connect_data:
> > > 
> > >  g_signal_connect_data (instance, "foo", callback, data, dnotify, TRUE, FALSE);
> > > 
> > > since you not only have to remember what the bools mean, you also have
> > > to remember what order they are in, and I constantly forget this for
> > > box_pack_start() even after 2+ years of GTK programming.
> > 
> > we can have an enum for both functions.
> 
> I think changing g_signal_connect_data to a flags field would
> be a good idea - would make it a lot easier to use. (Though I
> still don't really understand the name "data"...)
> 
> But, with that being easier to use, I'd like to keep g_signal_connect()
> even easier to use and avoid having a magic 0 at the end of 90%
> of calls to it.

Is there any objection to this? Do you mind if we go ahead and 
implement this?
                                        Owen




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]