[Kde-bindings] Qyoto: Delegates vs signals

[Arno Rehn]

On Wednesday 02 September 2009 16:09:43 you wrote:
> Hi Arno Rehn
>
> I'm the one who made the following bug:
> https://bugs.kde.org/show_bug.cgi?id=205311
>
> I would really like to (or at least try to) dive a bit into the problem and
> try to see if I can find something usable, but I'm not sure where to begin.
> First off I'm a bit curious on why exactly do you actually need the ability
> to overload signals?
For the same reason you overload normal methods. And qt actually does overload 
signals in some of the classes. For example you have

QComboBox::activated(int)
QComboBox::activated(QString)

How should we deal with that?
We can only create one event with one specific name, so we either only 
implement activated(int) or activated(QString) as an event.

A solution to this would be to append the parameter type names to the event 
name if it would be ambigious otherwise, but this would result in something 
like

combo.Activated_Int += /* ... */
combo.Activated_String += /* ... */

which is really ugly.

Another approach would be to create methods like AddActivatedHandler() which 
take a delegate. Methods can be overloaded, so we can have 
AddActivatedHandler(int) and AddActivatedHandler(string).

I recently got the idea of doing something like

delegate SignalFunc<T>(T arg1);

bool Connect<T>(SignalFunc<T> signal, SlotFunc<T> slot) {
	string signature = /* get signature of 'signal' */
	return Connect<T>(signal.Target.QObjectInstance, signature, slot);
}

Connect<int>(Signals.Activated, this.Foo);

where 'Signals' is a property which returns an instance of some special class 
exposing signals. That instance also has a reference to the QObject instance 
of which it exposes the signals.
 Each signal would then be a method with an empty body. It has an attribute 
with the C++ method signature. With the Delegate.Target property we can get 
the sender of the signal and with the attribute the signature.
That would work, but it somehow breaks with the current design (where we have 
a special 'Emit' property to access and emit signals).

If we implement it in a way like this, I'd completely revamp the whole signal 
stuff in Qyoto and maybe get rid of 'Emit' completely (in favour of something 
like Signals.Activated.Emit(5) and Signals.Activated.Connect(myDelegate)). 

> Some on #kde-bindings said that I might be more interested in the layer
> between smoke and C#, could that be true?
I doesn't have that much to do with the bindings ('the layer between smoke and 
C#') itself, as connecting a signal to a delegate is already possible. It's 
more about design of the C# classes.

> I also saw the note with
> "Auto-generated by kalyptus. DO NOT EDIT.", but where/how should I edit
> then? Wouldn't it be ok to experiment in the files anyway, as long as it's
> only to see if something works, so I might be able to get an idea and send
> it back?
Of course you can edit the C# source files directly for testing purposes. But 
the classes are auto-generated and so your changes would be lost if we 
regenerate the sources on the next API change.
The tool for generating the sources is called 'kalyptus', but will hopefully 
be replaced by a generator plugin for the new smokegenerator in the near 
future. Hacking kalyptus is quite a pain because it's all perl, but the 
smokegenerator-based stuff should be more easy to read & hack.

If you have an idea how to improve the Qyoto API, just send it to kde-
bindings at kde.org - we'll happily take it up and discuss it.

Also CC'ing this to the kde-bindings list.

-- 
Arno Rehn
arno at arnorehn.de