[PyKDE] Re: newest Version

[David Boddie]

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.

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
    Designer.

> Would you mind if we move this discussion to the mailing list. The French I
> talked about is not one person about a working group at ESRF. They are very
> intrested in this and would also like to help. If we don't move this to the
> mailinglist I would like to ask to add them also to the CC list.

Here's hoping for a more fruitful discussion with a larger audience.

All the best,

David