[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?
If no custom slots or signals have been defined in a subclass of QMainWindow, 
then we probably shouldn't construct a QMetaObject, but return the one for 
QMainWindow, and return 'false' from QyotoSmokeBinding::callMethod(). It is 
ok to set properties and enums to zero in C#or Ruby metaobjects, and that 
doesn't mean the MetaObject is not 'correct'. I think we may need to add 
properties for DBus support though.

-- Richard