[Kde-bindings] Qyoto: Movable QDockWidgets

[Arno Rehn]

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?

-- 
Arno Rehn
arno at arnorehn.de