[Gtk-sharp-list] "format-value" signal in Gtk.Scale
11 Mar 2003 23:53:54 -0600
On Tue, 2003-03-11 at 11:05, Miguel de Icaza wrote:
> Is the reason for the EventHandler subclasses to propagate the RetVal?
> I like the fact that I have the event data available on the EventHandler
> as a set of properties, but if the only reason for doing so is RetVal, I
> think I would be more pleased with method signatures.
The reason for doing so is that irregardless of whether it is allowed to
have non-void delegate events, the fact is that the class libs follow
the void FooEventHandler (object o, FooEventArgs args) convention,
exclusively as far as I can tell. I wanted to make the events look like
.Net events. I also figured they were that way for a reason, but if
there is no technical reason for having all void delegates on events, I
guess I just read to much into the practice.
The main use case for return values in Gtk+ signals is to stop emission
via a true return from a bool callback. The way S.W.F handles similar
tasks (like canceling an action from an event delegate) is by using
properties in EventArgs subclasses. So I chose the RetVal approach to
follow this S.W.F practice of sticking to void delegates and using the
args to feed back info to the caller.
The vast majority of signals that have non-void returns in gtk are bool
returns, which we already default to false if the user doesn't set it.
We throw an exception if RetVal is not set for a non-void, non-boolean
return value. This actually *saves* code, since otherwise every single
GdkEvent callback would have to have a return statement.
This discussion sprang from the review of a silly signal in a rarely
used class. :) I appreciate the feedback and don't want to discourage
people from looking for ways to improve the binding. If there were
hundreds of these in high runner signals, I might be more motivated to
do something about it, even though as I described above I think the
current way is more .net-ish.
If somebody feels strongly enough that RetVal is the most evil thing
ever, I encourage them to rewrite the signalhandler generation code to
produce non-void delegates and get rid of RetVal, and I'll gladly review
the patch for inclusion if for no other reason than to never have this
discussion again. :)
> Another thing to keep in mind is that in Glib there is a notion of
> "stopping" an emission
As gonzalo pointed out, this wouldn't be difficult. Feel free to open a
bug to make sure it doesn't fall through the cracks.
Mike Kestner <email@example.com>