[PyKDE] Re: newest Version
phil at riverbankcomputing.co.uk
Thu Oct 30 01:56:01 GMT 2003
On Wednesday 29 October 2003 8:38 pm, David Boddie wrote:
> Apologies to confused readers: this discussion started off-list but now
> seems an appropriate point to bring it on-list. I hope Roland doesn't mind
> me using one of his messages as a device to do this.
> On Wednesday 29 October 2003 07:42, Roland Schulz wrote:
> Background for new readers: Roland has written a library which allows
> Python QObject-derived widgets to be used in Qt Designer. We were
> discussing how the meta objects for widgets are used to help integrate
> them into the Designer framework, why the lack of a QMetaObject class
> for PyQt means that Designer can't preview them with other widgets and,
> finally, what methods are available to us to work around this problem.
> We could try these methods:
> 1. Wrap QMetaObject using sip and enable the QObject.metaObject method.
> 2. Do nasty hacking of pointers to modify the QMetaObject generated for
> the class at the C++ level.
> 3. Intercept the QMetaObject generation by customising the generation
> of the meta object when a class is instantiated.
> You join us at the point where we were talking about option 3. I shall now
> leave the narrator's chair and get back into character.
> > I don't see how moc should help here. I don't think it should be put in
> > moc_pyqwidgetplugin.cpp because it is automatically generated from
> > pyqwidgetplugin.h and is for class PyQWidgetPlugin. Others moc_* file
> > don't exist and you can't create other moc files from *.py files. Or are
> > you thinking about creating a pymoc command?
> I've thought some more about this and I'm coming round to the idea that we
> could derive a class from QWidget, in much the same way that Jim derived
> PyKPanelApplet from KPanelApplet, and get it to set up a customised meta
> object for each Python class by examining the relevant class definitions in
> Python scripts. In fact, looking at moc_pykpanelapplet.cpp in the
> PyKDE-3.8rc2 sources, it seems that we have a good template to start from.
This is the proxy I was suggesting - synthesise C++ metadata from
introspecting the Python objects.
> The disadvantages of this approach are:
> 1. Lack of a general method for defining signals and slots.
> 2. The introduction of a purpose-specific class which isn't required, or
> possibly even wanted, when an application is deployed. This might make
> it necessary for subtly different code to be used inside and outside
I see 2) as an advantage. I'm happy to put things in SIP and/or PyQt if they
are generally useful, but not if they are specific to a particular purpose.
But I'm happy to include in PyQt a separate library containing some sort of
proxy that manages the interface with Designer.
More information about the PyQt