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

[Richard Dale]

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.

>
> or
> 	MyButton.SignalClicked += SlotMethod;
>
> Disconnecting happens with the -= operator. This approach currently has
> some downsides, like you can't overload events and need to give them ugly
> names because of that. Also we'd need to decide whether we want to use the
> .NET pattern for the delegates, which would basically result in a special
> delegate for each signal in the form of
>
> void Delegate(object sender, Arguments objectContainingTheArguments)
>
> Personally I think the .NET pattern is crap. Why have a special class for
> each signal that contains all the arguments of the signal? It kinda
> eliminates the purpose of method parameters if you have to store them in
> another object anyway. 
Yes, I agree it is horrible.

> 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.

>
> :).
>
> 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'.

-- Richard