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

[Miguel de Icaza]

Hello,

> > > Any event that wraps a signal with a non-void return type in the
> > > "native" api should be documented to indicate how RetVal should be set.
> > 
> > I think the whole API would be nicer and more obvious if return values
> > were, well, returned.
> 
> Except that if you scan the entire ms class library documentation you
> will not find a single event delegate that returns a value.  This is, I
> believe, because of the unpredictable nature of the order of invocation
> of multicast delegates.  I recall reading somewhere that delegates used
> as events should always have a void return value.

Events in .NET are allowed to have a return value in their underlying
delegate.  The return value is just the return value of the last
invocation.

Returning values through RetVal or as a function return have the same
problem: the last delegate invoked is the one whose return value is
preserved.  RetVal actually does not work around this.

> > Is the 'RetVal' way of doing things a constraint forced by the
> > underlying Gtk+ system in some way?
> 
> No, it's a .net-ism.  Many gtk hackers have bitched about the use of
> EventHandler subclasses for events in Gtk#, instead of specific signal
> prototypes. Gtk# actually has to do work to map the args.RetVal onto a
> signalhelper delegate's return value.

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 whole notion of having to set a return value when the return type of
> > the delegate is actually 'void' seems likely to really confuse newcomers
> > to Gtk#...
> 
> Well, if anyone can convince me with documentation that non-void
> delegates as events are being used safely and effectively elsewhere in
> .net, I'd consider changing this.  I think the current method will be
> least confusing to people familiar with .net paradigms, and I'm also not
> convinced that using non-void delegates for events is correct.

The construct is allowed in .NET, it does have the same semantics than
the current RetVal approach in the presence of multiple signals.

Another thing to keep in mind is that in Glib there is a notion of
"stopping" an emission, to address issues like this.  Mathieu's Lacage
document on GLib object and signals is interesting:

	http://www.gnome.org/~mathieu/gobject/main.html

Gtk has a few ways of dealing with multiple-return values:

	* Accumulators

	* If no accumulators are present, the result is the result of
	  the last signal invoked.

I am not sure if we could even think about doing something like this
with the delegate/event infrastructure in .NET.  We can *stop* an
emision from GLib/Gtk, but we could not stop the signal from being
propagated to other delegates on the MulticastDelegate event chain.

Miguel