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 _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde