PLS get Dermot's input on this before changing it.
He is hacking on a glade module for gtk2-perl and
might get seriously hit by a change like this.
Personally I don't care as long as it is documented,
Old gnome-perl used the same argument order as we do now
(as opposed to C code).
/göran
On Mon, Nov 18, 2002 at 10:57:22AM +0100, Guillaume Cottenceau wrote:
> Hi,
>
> I'm not too sure anymore if it's so good to change the argument
> orders of callbacks as we did... I think there is no rationale
> anymore now since we have the same number of arguments than the
> gtk call, but with the user_data in 2nd arg instead of last arg.
>
> To sum up, in the current situation, we have:
>
> Signals with one argument:
> Gtk: user_function(GtkObject* o, ParamForSignal1 arg1, gpointer
> user_data)
> Gtk2-perl: user_function(GtkObject* o, gpointer user_data, ParamForSignal1
> arg1)
>
> Signals with two arguments:
> Gtk: user_function(GtkObject* o, ParamForSignal1 arg1, ParamForSignal1
> arg2, gpointer user_data)
> Gtk2-perl: user_function(GtkObject* o, gpointer user_data, ParamForSignal1
> arg1, ParamForSignal1 arg2)
>
> Events:
> Gtk: user_function(GtkObject* o, EventType evt, gpointer user_data)
> Gtk2-perl: user_function(GtkObject* o, gpointer user_data, EventType evt)
>
> I think this is not so logical, and confusing. What do you think
> of changing that to restore a more-like-gtk behaviour?
>
> The rationale of Dermot in
> http://mail.gnome.org/archives/gtk-perl-list/2002-October/msg00104.html
> was "[delivering the user_data always as second arg makes it]
> possible to write generic handlers that do not need to know
> whether the handler is connected to a signal or an event in order
> to work".
>
> While I can understand that, I think that this is examining the
> problem the wrong way round, because not all signals have one or
> zero argument: some have more. And anyway the callback do have to
> know for which signal it's running if it wants to correctly
> interpret the first arg (the object type) and the arguments
> (which event type? which type of parameter for signal?), and
> moreover, what to do! :) Basically, this is just gonna cause more
> problems for our users that it solves, in my opinion.
>
|
