[Kde-bindings] playground/bindings/kimono

[Richard Dale]

On Monday 19 February 2007, Arno Rehn wrote:
> * Implemented adding Q_PROPERTY's to the QMetaObject. Next step is
>   adding classes like InvokeSlot for properties in qyoto.cpp.
Yes, this looks good. I've been experimenting with the complexpingpong 
example. It has these flags in the moc generated moc_complexpong.cpp:

 // properties: name, type, flags
     133,  125, 0x0a095103,

       0        // eod
};

static const char qt_meta_stringdata_Pong[] = {
    "Pong\0com.trolltech.QtDBus.ComplexPong.Pong\0"
    "D-Bus Interface\0\0aboutToQuit()\0"
    "QDBusVariant\0query\0query(QString)\0"
    "Q_NOREPLY\0quit()\0QString\0value\0"
};
...

So I changed the or'd flags in QyotoMetaData.cs to give the same result:

				if (entry.pi.CanRead && entry.pi.CanWrite) {
flags = PropertyFlags.Readable | PropertyFlags.Writable 
| PropertyFlags.StdCppSet  
| PropertyFlags.Scriptable  | PropertyFlags.Designable | PropertyFlags.Stored 
| PropertyFlags.ResolveEditable | (PropertyFlags) (10 << 24) ;

 // properties: name, type, flags
      109,   115,   0x0a095103

       0        // eod

qt_meta_stringdata:
    "Pong\0D-Bus Interface\0com.trolltech.QtDBus.ComplexPong.Pong\0"
    "aboutToQuit()\0\0quit()\0query(QString)\0QDBusVariant\0"
    "value\0QString\0"

So I'm not sure if we need all those. The (PropertyFlags) (10 << 24) is for a 
QString type, where 10 is the QVariant Type value for a QString.

    [Q_PROPERTY("QString", "value")]
    public string value {
        get {
            return m_value;
        }
        set {
            m_value = value;
        }
    }

We can use QVariant.NameToType() to look up the value:

		public static QVariant.TypeOf NameToType(string name) {
			return StaticQVariant().NameToType(name);
		}

Then shift it 24 bits. If the type is invalid, then Property.EnumOrFlag is 
or'd instead.

Q_PROPERTY could use the same C# type to C++ type method as for slots and 
signals to make the type and name args optional.

I added some debugging in qt_metacall:

int qt_metacall(void* obj, int _c, int _id, void* _o) {
	// get obj metaobject with a virtual call
printf("qt_metacall: %d\n", _c);

And when I queried the complexpong via complexping, it printed out this:

qt_metacall: 1
qt_metacall: 2
qt_metacall: 1
qt_metacall: 2

Which are the values of QMetaObject::Call for reading and writing properties. 
So it should be a matter of doing something similar to InvokeSlot in 
qt_metacall() and it will work across dbus. Woo hoo!

> * When retrieving slot signatures, also include the slots of the
> superclass, if it isn't a native C++ class. Same has to be done for
> signals. 
Yes, we need one QMetaObject for each subclass. This isn't done quite right in 
QtRuby either.

> * Did some code cleanup: 
>         * Moved QyotoMetaData class into a seperate file, QyotoMetaData.cs
>         * Made code in QyotoMetaData better readable
Yes, that's easier to follow in its own source file. Maybe QyotoMetaObject.cs 
is better, but I don't think it matters much.

-- Richard