[Pythoncard-users] transitions

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

PythonCard is going through a number of transitions starting with
PythonCardPrototype release 0.5.3. I want to make sure that all the changes
are out in the open so anyone that wants to participate or comment can do
so. I'll try and provide a brief roadmap as well.

wxPython 2.3.1 and 2.3.2 and later
Release 0.5.3 added the wxTE_RICH text style to the TextArea widget, so
release 0.5.3 requires wxPython 2.3.1 or later. I'm already using wxPython
2.3.2b7 and once wxPython 2.3.2 final is released, I will be incorporating
some additional 2.3.2-specific features to the framework. 2.3.2 fixes
numerous bugs present in 2.3.1, including the menu accelerator bug which
prevents menu shortcuts from working.


wxPython as the only GUI toolkit
The original intent of the project was to wrap all the underlying GUI
toolkit API calls and events so that any number of toolkits might be used
later. The number of developers on the project simply won't support that
initial goal. In order to reduce the amount of code and overall complexity
of the framework I decided to reduce the supported GUI toolkits to just
wxPython and remove or refactor parts of the framework that simply duplicate
wxPython functionality with little or no added benefits. I've already
checked in one modification to the event dispatch mechanism so that the
actual event object passed to an event handler is the native wxPython event
object. The change is described in the following post:

http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/932492


Directly subclassing wxPython controls (widgets)
The biggest change that the user code (samples) are likely to see is if we
move the existing widgets from using wxPython classes as delegates (HAS A
relationship) to making widgets direct subclasses of wxPython classes (IS
A). Rowland is experimenting with this right now and we'll be discussing
this on the list more since it dramatically reduces the amount of code
necessary for a given widget class. PythonCard currently uses a naming
convention of lowercasing the first letter of a method, and many methods
such as the TextField getSelection method will no longer be needed:

    def getSelection( self ) :
        return self._delegate.GetSelection()

User code would just use GetSelection() if TextField was a subclass
wxTextCtrl.

Using the native wxPython class methods means that it will be easier to
refer to the existing wxPython documentation or auto-generate a variation of
the documentation specific to PythonCard.

We will continue to support dot notation for standard attributes, so in some
cases there will be overlap between wxPython methods and wrapper methods or
variables we provide to support dot notation.


Modular Widgets
In the last two weeks, we've talked about modularizing the widget.py file
and supporting user-defined widgets. Jeff Turner submitted some changes to
the framework to support modular widgets, but it hasn't been checked into
cvs. I'm currently working on splitting widget.py and incorporating some of
Jeff's code and ideas to support modular widgets and I'll discuss and check
these changes into cvs in the next week or so. Splitting up widget.py,
spec.py, and wxPython_binding.py shouldn't have any impact on user code such
as the samples.


Components
The discussion of modular widgets quickly switched to the idea of full-blown
components. Rowland has been working on a separate framework to support
components, but it is different enough that I'm recommending that it have
its own cvs tree and we develop in parallel in the short term. We can
incorporate pieces of the new framework into the existing one as it is
solidified or simply wait until Rowland's new code is up to at least the
level of the current framework before calling it the first real alpha
release of PythonCard.

ka