[Kde-bindings] playground/bindings/kimono

[Arno Rehn]

Am Sonntag, 25. Februar 2007 schrieb 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.
Yes, that's what I found out last night, too. But why is staticMetaObject for 
QObject missing? A bug in Smoke?

> >         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.
That already works (in my example it does at least). The code is not very nice 
in qt_metacall and could certainly be improved, e.g. make use of the 'real' 
metaobject and call qt_metacall of the parent class first and then process 
the custom signals/slots and stuff...

> Note that staticMetaObject is private in some Qt classes (specifically the
> ActiveQt stuff). metaObject() always seems to be safe.
The reason for me using staticMetaObject was that I wanted the code to create 
metaobjects to be free of object references. If we use metaObject(), we 
always need a reference of the object, but if we just want to have the parent 
metaobject, we would have to create an instance of the parent class just to 
be able to access metaObject(). That would slow down the whole thing a lot, I 
think.

-- 
Arno Rehn
arno at arnorehn.de