[Pythoncard-users] components framework

Components are another big issue that was brought up in the app framework
threads on wxPython-user. Windows COM is the most widely used form of
components, but there are also other forms of components like JavaBeans.
When Rowland and I started work on the very first pieces of PythonCard back
in July a friend of ours pointed out that the only way we could create a
framework with long-lasting appeal was by supporting a component model.

There are a number of problems with trying to do components while trying to
do something that works with multiple computer languages, across multiple
operating systems, and multiple GUI toolkits, that makes a component model
an almost impossible problem to solve.

If you limit your solution space to a single language such as Python and a
single GUI toolkit such as wxPython that already works across platforms then
the problem space is limited enough that it appears to be doable, yet still
powerful.

Jeff Turner's message and code having to do with modularizing the
organization of widgets rather than spreading out the class definitions,
specs, and event bindings brought this issue back to the top of the
framework issues. Rather than just modularizing the widgets, why not go
ahead and turn them into components?

Rowland is working on a component base that will let us treat the existing
widgets as components and make it possible to build compound components and
subclass standard components in the framework. This should also address the
issue of an app having its own custom components.

ka