[Kde-bindings] playground/bindings/kimono

Arno Rehn arno at arnorehn.de
Sat Feb 24 23:59:40 UTC 2007


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.
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. As I said before, for me everything works perfectly, 
could you discribe your problem any further?

-- 
Arno Rehn
arno at arnorehn.de



More information about the Kde-bindings mailing list