[PyKDE] Re: newest Version

[Phil Thompson]

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

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.

Phil