[Kde-bindings] playground/bindings/kimono

[Richard Dale]

On Saturday 24 February 2007, Arno Rehn wrote:
> Am Samstag, 24. Februar 2007 schrieb Richard Dale:
> > Hi Arno
> >
> > On Saturday 24 February 2007, Richard Dale wrote:
> > > On Saturday 24 February 2007, Arno Rehn wrote:
> > > > * Added ReadProperty and WriteProperty classes. Now custom properties
> > > > can be accessed via Property() and SetProperty() (and dbus?). However
> > > > there seems to be a problem with marshalling, see FIXMEs in the code.
> > > > The workaround should work as well as with marshalling, though.
> > >
> > > OK, I've just had a look at the code - I'm not sure you need to involve
> > > QVariants. I'll try doing it with the normal marshalling and see if I
> > > can get it to work.
> > >
> > > > * Autogeneration of Q_PROPERTY signatures and types now works
> > > > properly. * Flags of properties should now be set correctly.
> > >
> > > Excellent! One more important feature to tick off on the TODO list.
> >
> > The good news is that properties can be set and got over dbus. The bad
> > news is that I had to revert the recent changes to the way QMetaObjects
> > are created to get it to work.
>
> Uhm, for me it works the way it is at the moment...
>
> > I'm not sure that I understand what bug you were
> > fixing as I'd never noticed duplicate slot entries being created. In
> > QObject.cs there is this condition:
> >
> >                 [SmokeMethod("metaObject", "()", "")]
> >                 public virtual QMetaObject MetaObject() {
> >                         if (Qyoto.IsSmokeClass(GetType())) {
> >                                 return ProxyQObject().MetaObject();
> >                         } else {
> >                                 return Qyoto.GetMetaObject(this);
> >                         }
> >                 }
> >
> > Which should have catered for the problem of QMetaObjects being created
> > twice for Smoke classes, rather than subclasses of Smoke classes, I would
> > have thought.
>
> Ah yes, didn't see that. It would be OK if you access it via MetaObject().
> But consider the following: You have a class inheritance hierachy like
> QWidget
>    I- MainWidget
>         I- SubWidget
>
> Now you call 'SubWidget.SuperClass().SuperClass()' - it should return the
> MetaObject of QWidget. I checked that
> with 'SubWidget.SuperClass().SuperClass().ClassName()', which should
> therefore be 'QWidget', instead it was 'Qyoto.QWidget'. That confused me a
> bit, so I
> called 'SubWidget.SuperClass().SuperClass().SuperClass().ClassName()'. That
> returned just 'QWidget'. With some extra debugging output I found out that
> there is an extra MetaObject created for the Qyoto.QWidget class which in
> turn inherits from the original C++ QWidget MetaObject. Hence the duplicate
> signal/slot/property/whatever entries in the MetaObject.
Yes, that sounds wrong, but I would be surprised if the slots/signal entries
were duplicated. The code certainly didn't work correctly when it created
QMetaObjects for classes that were subclassed more than once from a Smoke
class like your heirachy above.

> This problem was created by my own implementation of correct MetaObject
> inheritance with more than one subclass, but the way it's done now is the
> easiest way, I think.
It is certainly tricky to get right - I'll have a look at your changes and
think about it more.

> As I said before, for me everything works perfectly,
> could you discribe your problem any further?
Yes, the complexpingpong example didn't work with the new QMetaObject code,
although tutorial t14 did.

For some reason the background of t14.exe is now being painted correctly as
off-white and that didn't use to work.

-- Richard