[Kde-bindings] Suggestions for Qyoto

[Arno Rehn]

Am Dienstag, 23. Januar 2007 18:01 schrieb 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.
Yes, you're probably right here. Then let's keep it as it is.

> > 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.
Hmmm, my idea would be to generate an event for each signal. This event I 
would connect to a signal via the 'normal' Connect(). Events have accessors 
like properties, add() and remove(). In the add() accessor we check if the 
event is already connected to a signal and if not we do that here. So no 
cluttering with connections. With the new anonymous methods in C# we can then 
write these code blocks for signals, which look like
pushbutton.Clicked += new delegate() { Console.WriteLine("foobar"); };

The only problem is that we can't create full interopability between normal 
connections and delegates because for the normal conenction the class needs 
to be a subclass of QObject, for delegates this is not the case. So in the 
end the programmer would have to decide whether to use normal connect() or 
delegates.

> Another thing that would be nice is to autogenerate code from Q_PROPERTYs
> and make them C# attributes.
Wouldn't map Q_PROPERTYs on a normal C# property?

> 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.
Uhm, how can we do it another way? I think they don't return a defined value 
type every time, so the QVariants are right, aren't they?

-- 
Arno Rehn
arno at arnorehn.de