[Kde-bindings] KDE/kdebindings/csharp/qyoto

[Arno Rehn]

On Wednesday 18 February 2009 14:50:41 Richard Dale wrote:
> On Tuesday 17 February 2009 22:07:08 Arno Rehn wrote:
> > On Tuesday 17 February 2009 22:22:32 Arno Rehn wrote:
> > > SVN commit 927583 by arnorehn:
> > >
> > > * Add support for C# events. They're called Signal<signalName> and if
> > > they're overloaded, additionally have their arguments attached to their
> > > name. This should be considered highly experimental and can change at
> > > any time.
> >
> > As there was some discussion about this on IRC, now here's what I think:
> > We should provide some alternative to the traditional Connect() method of
> > Qt to connect signals to slots; something that feels more C#ish, or
> > better, .NET- ish. The most obvious possibility to do this is C# events
> > and that's what I recently checked in. With it you can connect a
> > delegate, i.e. anonymous function, lambda function or simply a method to
> > a signal, like this:
> >
> > 	MyButton.SignalClicked += delegate(bool clicked) { /* do stuff */ };
>
> I think this one looks good - it is very similar to connect a Ruby block to
> a signal in QtRuby. But I'm not sure a the different names needed in
> addition to the Signal functions in the interfaces we already have. At the
> moment we have a property 'Emit' in the QObject classes that is a
> transparent proxy that you make calls on to emit signals.
>
> Maybe is it possible to do something similiar for connect time. If
> 'Connector' was a property:
>
> MyButton.Connector.Clicked() += delegate(bool clicked) { /* do stuff */ };
>
> The above would work if the various signal methods returned something to
> connect to. But what if the signal had arguments? Then it doesn't work very
> well.
I also though about something like this. But I'm afraid we can't reuse the 
existing signals interface for that. Some signals are even supposed to return 
something and thus can't return a "Connector" or something alike.
But to have a property in the class which holds the events for signals sounds 
good, so we can get rid of the "Signals" prefix or any other workaround to 
prevent name clashes.

> [snip]
>
> > Regarding the first "sender" parameter: we can
> > access that through QObject.Sender() so it's not really needed here
> > either. As Richard said, we should create something that's better than
> > GTK#. And I think it's better to keep it the 'Qt'-way and pass every
> > signal parameter directly. This also eases writing short anonymous/lambda
> > functions if you have all the parameters that you need readily at hand.
> > And as we are at it: A better way to handle Qt signals would be to add
> > methods like AddClickedHandler() which take a delegate, similar to an
> > event. But you can overload methods and that would get rid of the need
> > for ugly event names. Plus I dislike the += and -= syntax, so imho it'd
> > be optically nicer as well
>
> Thats sounds more long winded than using the standard Connect() to connect
> slots and signals to me.
It would be similar to the event stuff above:

MyButton.AddClickedHandler( delegate(bool clicked) {
	/* do stuff */
});

> > :).
> >
> > Maybe I commited my changes to early, sorry about that. But it's just one
> > commit and it can be reverted easily I guess - in case there's a need for
> > it.
>
> Well I think we should release a Qt 4.5 Qyoto as soon as possible and if we
> do that we are commiting to a change you've described as 'experimental'.
Yep, maybe we can also put together a binary package for Windows and OS X.

-- 
Arno Rehn
arno at arnorehn.de