RE: [Pythoncard-users] Is PythonCard goal to replace wxPython

[Kevin A. <al...@se...>]

> 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