[PyKDE] Opinions on pyuic Custom Widget Support
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. "modname" is the value entered in the Headerfile field of the Edit Custom Widgets dialog with the .h extension removed. While this works, I'm told it isn't particularly useful. It also makes dubious assumptions about how custom widgets have been packaged into modules and make it less easy to satisfy both uic and pyuic. 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 copied to the generated module. This is then completely flexible. Before I go ahead and implement this, does anybody have any better suggestions? Or additional things that could be done for common cases (like support for PyKDE widgets). Phil ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Opinions on pyuic Custom Widget Support
-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 haven't recently played with uic so I don't remember what it does nor how the two compare. I like the idea of the new way providing more flexibility, however, as I have been considering changing some of my naming conventions. If the change is made, as long as it is well documented, it shouldn't be a problem. - --Kaleb On Saturday 14 December 2002 03:10 am, Phil Thompson wrote: > 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. "modname" is the value entered in the Headerfile field of the Edit > Custom Widgets dialog with the .h extension removed. While this works, I'm > told it isn't particularly useful. It also makes dubious assumptions about > how custom widgets have been packaged into modules and make it less easy to > satisfy both uic and pyuic. > > 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 copied to the generated module. This > is then completely flexible. > > Before I go ahead and implement this, does anybody have any better > suggestions? Or additional things that could be done for common cases (like > support for PyKDE widgets). > > Phil > > ___ > PyKDE mailing list[EMAIL PROTECTED] > http://mats.gmd.de/mailman/listinfo/pykde -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9+0l/eAVt8Tl/2kURAkdwAKCyqPrCRb9tuV+QVoL7pjZ3Nr/XDACfS5h5 hVyT74apeyPge4plPgq8VBs= =zHEQ -END PGP SIGNATURE- ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Opinions on pyuic Custom Widget Support
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 copied to the generated module. This is then > completely flexible. > > Before I go ahead and implement this, does anybody have any better > suggestions? Or additional things that could be done for common cases (like > support for PyKDE widgets). 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 compatibility). You could even provide a "Python: @defaults@", or something like that, allowing people to include the current generated imports, along with the other Python: clauses. ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Opinions on pyuic Custom Widget Support
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 of the Form Settings dialog. Any > > line beginning with "Python:" will be copied to the generated module. > > This is then completely flexible. > > > > Before I go ahead and implement this, does anybody have any better > > suggestions? Or additional things that could be done for common cases > > (like support for PyKDE widgets). > > 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 compatibility). You could even provide a > "Python: @defaults@", or something like that, allowing people to include > the current generated imports, along with the other Python: clauses. I want to drop the current method because it is likely to be broken when you want to use both uic and pyuic, ie. when you are using PyQt as a rapid prototyping tool for C++ development. Phil ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] Opinions on pyuic Custom Widget Support
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. > Before I go ahead and implement this, does anybody have any > better suggestions? Or additional things that could be done for > common cases (like support for PyKDE widgets). I believe everything PyKDE needs can be done that way except the change from QApplication to KApplication, which is a pretty simple edit. It sounds like a good solution to me (having thought about it for 2 minutes also). Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Opinions on pyuic Custom Widget Support
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 compatibility). You could even provide a > > "Python: @defaults@", or something like that, allowing people to include > > the current generated imports, along with the other Python: clauses. > > I want to drop the current method because it is likely to be broken when > you want to use both uic and pyuic, ie. when you are using PyQt as a rapid > prototyping tool for C++ development. Please go ahead, Phil. Better supporting another sexy development strategy by far outweighs some minor hassle with backward compatibility in this respect. [Some cursory christmas thoughts/wishes, weather is asking for it:)] Since I joined this project on mid of july, I'm pleased to realize the speed of development without big talk. In fact, I would love to see a bit more cummunication on these advances<33% wink>. The biggest gift seems to be Phils effort in order to wrap Scintilla, which made it possible for Detlev to enhance eric to a very promising IDE in just adding 372 KB Python Source. It has grown to a size of 760 KB of sane an (mostly) easy to understand and i18ned code. I cannot imagine a better demonstration of the raw power from a develop environment. Simply incredible, guys! Phil, I would love to see you tackling some entries from the sip TODO. When browsing through sip's code last time, me badly realizes my knowledge holes on the flex/yacc front, but OTOH, the strong feeling, it would be worth the hassle to fill them. This may reduce the call for that somewhat crazy idea of coupling several c++ wrapper libs for one toolkit in one project. If only we could combine these efforts in order to make out world a bit more pythonic tomorrow ;-) This is by no means intended as an offence against the Boost.People. Please beware! Although PyQt is carried by a comparably small cummunity, it is a very nice place to be. Thanks, guys! [Asking myself: any xx chromosome coded human listening?] > Phil I wish you all a nice christmas, Hans-Peter ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde