[Kde-bindings] Qyoto: SIGNALS/SLOTS

[Richard Dale]

On Friday 09 December 2005 19:42, Arno Rehn wrote:
> Looks good, but do you want to connect a C++-signal to a C++-slot? The
> C++-slots are methods in C#, so we don't really need C++ type signatures,
> do we?
> If you want to connect C++ to C++ the signatures should be there of course.
The QMetaObjects are constructed with C++ types signatures, so you need a way 
of deriving the C++ type from the C# type to build them. The problem arises 
when that conversion could be ambiguous, such as when C++ 'char *', 
'QCString' and 'QString'  would all map onto the same C# 'string' type. 

QtJava and Qt# didn't need C++ type signatures because they didn't construct 
QMetaObjects on the fly, but instead had 'proxy slots' which diverted a call 
to the final java or C# slot. You need to have a C++ proxy slot classes with 
all possible combinations of argument types for slots to do that. The the Qt 
runtime actually connects to the proxy slots, but you need to intervene for 
every method call which can specify a slot, and look up a proxy one. The 
QtJava runtime is able to sort out any ambiguities such as for slots with C++ 
string types at runtime. It has some advantages and some disadvantages over 
the way QtRuby and PerlQt do it.

Sometimes you need to specify the exact C++ type that you want the outside 
world to see (maybe for a KDE DCOP slot for instance), and being able to 
specify the exact C++ type allows you to do that.

-- Richard