Defining VCL-like framework for Python

[Tres Seaver]

Minor correction to an excellent summary of the VCL:

Evan Simpson wrote:
> 
> Let's return to the Delphi VCL as an example of a framework, and see if that
> makes things clearer.
> 
> Delphi's visual toolkit is (sort of) MFC.  All controls are ultimately based
> on standard Windows calls, but they wrap the MFC interface in objects with
                                               ^^^ s.b. "SDK"

The VCL wraps the C-level SDK API, not the ever-so-slightly-wrapped-in-sugar
MFC, which is halfway to a framework itself (all the rigidity, with none of the
benefits).

> methods and properties, so you don't have to deal with Handles, pointers,
> etc.  So far, we're still talking a couple of layers of abstraction and a
> few (ha!) interface definitions.
> 
> The moment you select File/New Application in the IDE, you're slapped with
> the framework.  Delphi creates a "main program" file (*.dpr), a default
> resource file (*.res), a "main form" unit (*.pas) and resource file (*.dfm),
> all copied from stock templates.  The main program creates an instance of
> class TApplication, which has all sorts of mechanisms to keep track of and
> manipulate TForm objects.  The main form subclasses TForm, which, as a
> TComponent, has machinery for tracking and managing other TComponents, and
> as a TWinControl keeps track of child TWinControls.  There's a global
> variable in the form unit, into which the main program by default puts an
> instance of the form class at startup.  Then it makes the form visible and
> calls a method of TApplication which does the main event loop.
> 
> None of this is necessary; it's all framework.  It adds a great deal of
> bookkeepping, and capabilities which don't exist at the toolkit level.  The
> closer the fit beteeen the way you want your program to work and the
> framework, the easier your life is.  If you want, you can chuck the
> framework and just write Object Pascal.  You can even use many of the
> high-level GUI parts without too much trouble.  Try to work *almost* within
> the framework, but not quite, and it can really be a pain in the ass.
> 
> {bitch'n'moan}Thanks to the VCL's overuse of private data members, and OP's
> single-inheritance, you have to cut-and-paste the entire definition of a
> class (and every damn subclass) to make low-level behavioral changes *far*
> more than I'd like.  Versions 3 and 4 add ref-counted interfaces, which woul
> d fix a lot of this, except that nobody's re-written the VCL to take
> advantage of them.{/bitch'n'moan}
> 
> To sum up: a framework is a codification of a single style of app creation,
> with a great heap of support objects and pre-written code snippets which
> support that style.  Heck, you could almost think of Python as a framework
> for C.
> 
> it's-also-another-200+KB-before-you've-written-a-line-ly y'rs
> Evan Simpson

To be fair, that amortizes out pretty nicely (your code compiles down amazingly
far, and there is very little overhead for adding additional forms, with
gillions of controls each, because the VCL is already compiled in).

Oracular'ly,

-- 
=========================================================
Tres Seaver         tseaver at palladion.com    713-523-6582
Palladion Software  http://www.palladion.com