[Kde-bindings] Suggestions for Qyoto
rdale at foton.es
Tue Jan 23 17:01:24 UTC 2007
On Tuesday 23 January 2007 16:21, Arno Rehn wrote:
> 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.
More information about the Kde-bindings