[PyKDE] Opinions on pyuic Custom Widget Support

2002-12-14 Thread Phil Thompson
I've been prompted to look at improving pyuic's support for custom widgets. At the moment, if you use a custom widget, pyuic will generate the following at the start of the module... from modname import widgetname ...where widgetname is the class name of the custom widget - no problem there.

Re: [PyKDE] Opinions on pyuic Custom Widget Support

2002-12-14 Thread Kaleb Pederson
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't have a better suggestion at the time. The way it currently works is very intuitive. Without looking through the documentation, I assumed that it would work that way and when I added custom widgets to my programs everything just worked. I

Re: [PyKDE] Opinions on pyuic Custom Widget Support

2002-12-14 Thread Ricardo Javier Cardenes Medina
On Sat, Dec 14, 2002 at 11:10:18AM +, Phil Thompson wrote: I propose to remove this behaviour. A more generic, think about it for 2 minutes, solution is to allow Python code to be embedded in the Comment field of the Form Settings dialog. Any line beginning with Python: will be

Re: [PyKDE] Opinions on pyuic Custom Widget Support

2002-12-14 Thread Phil Thompson
On Saturday 14 December 2002 4:04 pm, Ricardo Javier Cardenes Medina wrote: On Sat, Dec 14, 2002 at 11:10:18AM +, Phil Thompson wrote: I propose to remove this behaviour. A more generic, think about it for 2 minutes, solution is to allow Python code to be embedded in the Comment field

RE: [PyKDE] Opinions on pyuic Custom Widget Support

2002-12-14 Thread Jim Bublitz
On 14-Dec-02 Phil Thompson wrote: A more generic, think about it for 2 minutes, solution is to allow Python code to be embedded in the Comment field of the Form Settings dialog. Any line beginning with Python: will be copied to the generated module. This is then completely flexible.

Re: [PyKDE] Opinions on pyuic Custom Widget Support

2002-12-14 Thread Hans-Peter Jansen
On Saturday 14 December 2002 18:34, Phil Thompson wrote: On Saturday 14 December 2002 4:04 pm, Ricardo Javier Cardenes Medina wrote: At first glance, I don't see a better way to do this, but I think you should preserve the current behaviour when no Python: has been provided (for backwards