[Kde-bindings] Suggestions for Qyoto

[Richard Dale]

On Tuesday 23 January 2007 19:13, Arno Rehn wrote:
> 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.
One option would be to have a particular Q_CLASSINFO type of info to 
mean 'expose all methods as slots in this class'. I think we should try out 
the QDBusAbstractAdaptor class and see what seems to be useful for working 
with that.

> > > 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"); };
Yes, that looks very nice. I've been googling a bit for C# closures, and I'd 
forgotten that they are actually delegates. But it looks like we should be 
able to do interesting things with them, and the way QtRuby works with slots 
as blocks might work to implement the above code.

> 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.
I think we should make every work with underlying QMetaObjects because it 
means that C# code for slots can be seen from a C++ or Ruby world and it will 
interoperate. So we should stick with QObjects and the QMetaObject system 
even if the surface syntax looks different.

> > 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?
Ah yes, I meant those - whatever setter and getters are called in 
C#, 'properties' and not 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.
>
> 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?
We could generate C# interfaces from the dbus definitions, and then use them 
to create a transparent proxy. The interfaces could be C# source code 
compiled in the normal way. Or I wondered about having the build process for 
a QDBus call doing dbus introspection and creating something (an assembly) 
dynamically if that was possible. In QtRuby you can call dbus methods 
directly on the QDBusInterface proxy just like a local method call, and so 
transparent proxies could do the same thing in C# as long as you have 
something to compile against.

Or something more simple - In C#QDBusAbstractInterface.Call() takes a variable 
number of QVariants. In C++ when you invoke that method, it automatically 
converts the args to QVariants. I think we can do the same in Qyoto, but the 
reply type would still be a QDBusMessage though in C#. I've recently added a 
generically typed QVariant.FromValue() method, which might work if we can get 
the type of an object via reflection to pass to it.

-- Richard