[Kde-bindings] Suggestions for Qyoto

[Richard Dale]

On Tuesday 23 January 2007 16:21, Arno Rehn wrote:
> Hi,
>
> I have a few improvement suggestions for Qyoto:
> 1. How about making every C# method a slot, instead of using the Q_SLOT
> attribute? It would speed up developing an application, in my opionion and
> would help suggestion #2. Q_SLOTs kann still be used to modify the
> signature of a slot by hand.
Yes, we could do that. In the QtJava bindings for Qt3 every void method could 
be called as a slot (qt3 slots weren't supposed to have return values). On 
the other hand in C++ every method isn't made into a slot when they could be, 
and only those in the 'slots:' section of the header are slots. So I assume 
the reason is efficiency, and not cluttering up the QMetaObjects with too 
many methods. And if you need to mark some of the methods with Q_SLOT to 
specify their C++ type signature, it seems inconsistent not to have to do it 
for all of them.

> 2. Use delegates. It would be a lot more C#-ish if we would use delegates
> in addition. I don't know if it's possible to catch the call of a signal,
> even if it doesn't have a slot connected to it. From what I've tried, it
> only works if there is a slot connected. But it's still possible with
> delegates, we just need to autoconnect the slots when adding a delegate to
> an event. I've already tried this, it's not a problem. But I think it would
> significantly increase the size of the code if we'd add the delegate stuff
> for each class with signals.
> My idea of implementation would be to make every class a partial class and
> then add the delegates stuff in an extra file, like QClassNameEvents.cs
Yes, I think we should do something with delegates like you suggest, and layer 
them on top of Qt event handling and/or slots and signals. 

I would like to be able to connect a closure as a slot, and I don't know how 
that would interact with delegates. I haven't got round to trying C# ones out 
yet. In QtRuby you can connect a block (ie closure) as a slot, and that is 
quite a nice feature.

> 3. Make every method in the signals interface a signal, without use of
> Q_SIGNAL (you can still use the attribute to set the signature by hand).
Yes, Q_SIGNAL is a bit redundant. But for the same reasons as for slots, I 
don't like having to mark some methods in an interface as signals because the 
C++ type signature in needed, but not other methods.

> Just a few suggestions from my side.
Yes, I think we should carry on discussing how to do slots/signals, but not be 
in a hurry to commit to anything as it's the sort of thing that would be very 
difficult to change once we've actually got users. I think we have the 
minimum to get going, and maybe we should do a first release and get some 
feedback about what people think.

Another thing that would be nice is to autogenerate code from Q_PROPERTYs and 
make them C# attributes. 

For QDBus it would be nice not to have to convert every arg into a QVariant, 
and it might be possible to do something with transparent proxies to make 
calling a DBus method look tidier.

But I think now we have generic list types, it has made the api look nicer. I 
added some Dictionary<,> types too although there a still some of those 
missing. I need to go through the methods marked 'NOT CONVERTED' to see what 
is still missing.

-- Richard