[Gtk-sharp-list] "format-value" signal in Gtk.Scale

[Mike Kestner]

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.

</HistoryLesson>

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 <mkestner@speakeasy.net>