[PyKDE] Re: newest Version
mail at r2s2.de
Thu Oct 30 09:36:01 GMT 2003
-----BEGIN PGP SIGNED MESSAGE-----
On Thursday 30 October 2003 06:29, you wrote:
> On Wednesday October 29 2003 17:46, David Boddie wrote:
> > On Wednesday 29 October 2003 22:40, Jim Bublitz wrote:
> > > If you get
> > > QWidget::metaObject(), will you get the QFrame and QLineEdit
> > > meta data too?
> > I would have thought that the meta object will still contain
> > all the information that was stored in it regardless of the
> > class used to call metaObject.
> Yeah - I didn't think this through very clearly. For any QObject
> descendent, there's only one instance of QMetaObject , so the
> derived class's meta data has to be attached to that. So in the
> example (PyWidget) above, even if you have a QWidget *w,
> w->metaObject() has to include the meta data added by QFrame and
> QLineEdit (and you should be able to add PyWidget's meta data as
> well). You may need to set things like "className".
Like I wrote in the mail before, we can't change the QMetaObject, because we
would also change it for the C++ objets. And if we overwrite the metaObject
method we can return a new QMetaObject everythime we need to.
> If that weren't true it'd be a lot harder for TT to write
> QtDesigner in the first place - the type casting would be a real
> Cases like:
> class A (QWidget)
> class B (A)
> will need some special handling (by the user) to set the Python
> meta data correctly.
I don't think so. If we have overwritten the metaObect method call so it
returns the apropriate new created for the Python subclasses, we get the
correct QMetaObject also for a Python superclass and can pass this to the
QMetaObject constructor, so it adds all those informations too.
>  The exception might be if the class inherits multiple QObject
> or QWidget derived classes, but that can't be done directly in
> Python/PyQt. Don't know if a Qt class like that exists.
We probably have to test this. I have no clue what happens than ;-)
> This is Roland's project, so it's up to him to give orders on how
> to proceed. If what I'm suggesting isn't clear (and I've
> certainly been muddling through this), I can write up an example
> to test out creating a Python widget, adding the meta data, and
> testing calls for virtual methods. It should be possible to code
> the plugin from that. That of course assumes you want to try
> going that route.
Like I wrote I think it's not possible. But of course I can be completly
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the PyQt