[Kde-bindings] Qyoto: Movable QDockWidgets

[Richard Dale]

On Sunday 22 October 2006 16:29, Arno Rehn wrote:
> Am Sonntag, 22. Oktober 2006 16:56 schrieb Richard Dale:
> > On Sunday 22 October 2006 15:05, Arno Rehn wrote:
> > > Am Sonntag, 22. Oktober 2006 12:21 schrieb Richard Dale:
> > > > On Sunday 22 October 2006 09:59, Arno Rehn wrote:
> > > > > Am Samstag, 21. Oktober 2006 23:10 schrieb Richard Dale:
> > > > > > On Wednesday 18 October 2006 22:47, Arno Rehn wrote:
> > > > > > > > I had a look at which virtual methods were being overriden,
> > > > > > > > and it was only ever QObject::metaObject(). I checked that
> > > > > > > > the QDockWidget features were correct and they were set to
> > > > > > > > '7', which should mean the widget is movable ok. So I can't
> > > > > > > > think of what it can be at the moment, or how to find out.
> > > > > > >
> > > > > > > I implemented my ugly hack and it works for now. It's
> > > > > > > definitely not a good solution and if someone has a better one,
> > > > > > > please check it in! But I think at the moment we should focus
> > > > > > > on other things like D-BUS. I haven't tested yet if it works
> > > > > > > with my last commits, so this will be my next task.
> > > > > >
> > > > > > I've found if I disable virtual method overrides in
> > > > > > QyotoSmokeBinding::callMethod() it works fine. And it looked like
> > > > > > the only method being overriden was QObject::metaObject(), and so
> > > > > > there must be something wrong with the QMetaObject returned I
> > > > > > suppose.
> > > > >
> > > > > For me it doesn't work either. I commented out my hack and the part
> > > > > in QyotoSmokeBinding where qt_metacall is overridden. The dock
> > > > > widget isn't movable. What parts did you disable in
> > > > > QyotoSmokeBinding::callMethod() ?
> > > >
> > > > I added an unconditional 'return false':
> > > >
> > > > [CODE]
> > >
> > > The metaObject is created correctly, it's a problem of the return value
> > > of QyotoSmokeBinding::callMethod().
> > > Just change the last part:
> > > 		VirtualMethodCall c(smoke, method, args, obj, overridenMethod);
> > > 		c.next();
> > > 		return true;
> > > to
> > > 		VirtualMethodCall c(smoke, method, args, obj, overridenMethod);
> > > 		c.next();
> > > 		return false;
> > > and it will work. I think there is a problem that we return nearly
> > > always 'true', even if the method isn't overridden.
> >
> > I'm not sure if that's right, we should return true if the method has
> > been overriden. Here is the code in the Smoke library for the
> > QObject::metaObject() callback:
> >
> >     virtual const QMetaObject* metaObject() const {
> >         Smoke::StackItem x[1];
> >         if(qt_Smoke->binding->callMethod(8894, (void*)this, x)) return
> > (const QMetaObject*)x[0].s_class;
> >         return this->QMimeData::metaObject();
> >     }
> >
> > If 'false' is returned it will mean that the original method is called as
> > well as the C# method that should override it.
>
> Hmm, but I think this is a special case. When we look at how we create the
> MetaObject:
> 				ArrayList tmp = new ArrayList(new uint[] {
> 					1,                                  // revision
> 					handler[className],                 // classname
> 					(uint)classinfos.Count, classinfos.Count > 0 ? (uint)10 : (uint)0,  //
> classinfo
> 					(uint)(signals.Count + slots.Count),
> 					(uint)(10 + (2 * classinfos.Count)),        // methods
> 					0, 0,                               // properties
> 					0, 0
> 				});
> We always set 'properties' and 'enums' to zero. That means, the MetaObject
> created by our own is often not 'correct'. How does qtruby handle this?
> From what I can see in qtruby is the creation of MetaObjects exactly the
> same. data = [1, 								# revision
> 					string_table.call(classname), 	# classname
> 					classinfos.length, classinfos.length > 0 ? 10 : 0, 	# classinfo
> 					signals.length + slots.length,
> 					10 + (2*classinfos.length), 	# methods
> 					0, 0, 							# properties
> 					0, 0]							# enums/sets
> Is it correct to return _this_ MetaObject every time metaObject() is
> called, even internal?
I still looking at this bug in the QMainWindow dock app. Here is what I've 
found so far. This is wrong because a QMetaObject for custom slots and 
signals will never be retrieved:

		void * overridenMethod = (*OverridenMethod)(obj, (const char *) signature);
		if (overridenMethod == 0 || signature == "metaObject() const") {
			return false;
		}

It should still be:

		void * overridenMethod = (*OverridenMethod)(obj, (const char *) signature);
		if (overridenMethod == 0) {
			return false;
		}

In Qyoto.cs, GetSlotSignatures(), BindingFlags.DeclaredOnly needs to be added:

			MethodInfo[] mis = t.GetMethods(BindingFlags.Instance | 
BindingFlags.Static | BindingFlags.Public | BindingFlags.NonPublic| 
BindingFlags.DeclaredOnly);

Otherwise it looks at all the superclasses for slot methods instead of just 
the current class. I think that Q_SLOT attributes should be generated for the 
Qt classes, like the Q_SIGNAL ones are.

In the docking example, I needed to add this, otherwise the Window class 
QMetaObject included the signals for QMainWindow:

make_metaObject() superdata: 0xb6e69650
stringdata: Window\0iconSizeChanged(const 
QSize&)\0\0void\0toolButtonStyleChanged(Qt::ToolButtonStyle)\0
data: 1, 0, 0, 0, 2, 10, 0, 0, 0, 0, 7, 37, 38, 37, 5, 43, 37, 38, 37, 5, 0,

	protected new IWindowSignals Emit() {
		return (IWindowSignals) Q_EMIT;
	}

	public interface IWindowSignals : IQMainWindowSignals {
	}

After adding the code above, the QMetaObject for Window looks like this:

make_metaObject() superdata: 0xb6ec4650
stringdata: Window\0
data: 1, 0, 0, 0, 0, 10, 0, 0, 0, 0, 0,

However, even when the metaobject for the Window class correctly doesn't have 
any slots and signals, the dock example still doesn't work, and so I'm still 
not sure what's wrong.

-- Richard