[Kde-bindings] playground/bindings/kimono

[Phil Thompson]

On Sunday 25 February 2007 11:26 am, Richard Dale wrote:
> On Sunday 25 February 2007, Richard Dale wrote:
> > 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.
>
> I've found out what the problem was. The new method depends on using
> staticMetaObject, and the isn't one in the Smoke library for QObject. In
> QtRuby I had to special case for that. So in make_metaObject() it tries to
> find staticMetaObject for QObject, fails and returns 0, which causes a
> crash. In complexping the Ping class is a direct subclass of QObject, and
> so that's why it crashes.
>
>         if (isSmokeClass) {
>                 Smoke::Index classId = qt_Smoke->idClass(className);
>                 Smoke::Index nameId =
> qt_Smoke->idMethodName("staticMetaObject");
>                 Smoke::Index meth = qt_Smoke->findMethod(classId, nameId);
>                 if (meth <= 0) {
>                         // Should never happen..
>                         return 0;
>                 }
>
> I'll do a patch of how I think this should work, but not check it in - just
> post it on this list for discussion. The old way is wrong, and so is the
> new one. We also need to make qt_metacall work when there is more than one
> subclass of a Smoke Class.

Note that staticMetaObject is private in some Qt classes (specifically the 
ActiveQt stuff). metaObject() always seems to be safe.

Phil