|
From: Kevin A. <al...@se...> - 2004-01-23 23:37:10
|
> From: Nicolas Fleury > > After few weeks working with wxPython, I must say that's a wonderful > library and my first choice for GUI programming. However, there's few > things inherited from the C++ API that could be more python-friendly. > > Before deciding to post a msg on wxPython newsgroup about possibilities > of enhancing the API, I made some searches to find the existence of > PythonCard. Still, I'm not sure if PythonCard goal is only to provide a > VB-like tool, or also a next-gen API for wxPython (I understand > PythonCard is at the moment a layer over wxPython)? In short, PythonCard will not replace wxPython, it will continue to sit on top of wxPython. It would be nice to simplify all the complex aspects of wxPython, but it is difficult to do that without reducing the number of things you can do at the same time. So far the solution has been to allow "raw" wxPython code to be mixed into PythonCard apps. This doesn't extend to nested panels, notebooks, etc. in the resourceEditor. > By the way, there's two things I haven't seen in the TODO list (I may > have miss something), but basically: > > Make register of some events easier: > wx.Button(parent, callback=self.onButtonPress) I'm not sure what you're looking for here since PythonCard auto-binds events for the components it supports. > Support python iterations: > for child in myTreeItem.children: ... If you want something specifically for the tree control, then you're welcome to enhance they minimalistic Tree component wrapper. self.components does support iteration since it subclasses UserDict. Some tools and samples such as "widgets" use iteration over components. You can play around with it in the shell, just open up any sample with the -s command-line option and type something like... >>> for c in self.components.itervalues(): ... print c.name ... > Also, I'm not a VB-like user since I like to use things like sizers, but > if you want to simplify the use of sizers, on solution could be to > reduce the number of possible sizers by providing something a > FlexGridSizer with capabilities for multi-cells widgets. This is done > in html tables, and I guess there's a lot of html editors that can be > checked for ideas on interface. This kind of sizer eliminates the need > of BoxSizer, GridSizer, etc. I think Java has one named GridBagLayout > or something like that. I'm considering this for a future version and expect to look into it more once wxPython 2.5 is stable. Borland had the FlexGridSizer ported to C++ so it is supposedly much faster and the API was also enhanced. Again, feel free to post your own experiments. Sean McKay was looking into modifications to the framework and resourceEditor to support splitters and notebooks last fall, but since he didn't get much if any feedback from the list or myself (bad Kevin, no banana) I'm not sure if he gave up on PythonCard and just moved on. > Regards, > > Nicolas ka |