[Kde-bindings] Qyoto: SIGNALS/SLOTS
Richard_Dale at tipitina.demon.co.uk
Mon Dec 12 16:43:22 UTC 2005
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.
More information about the Kde-bindings