Defining VCL-like framework for Python

[Alexander Staubo]

In article <3748B569.3973A8E4 at palladion.com>, tseaver at palladion.com says...
> Graham Matthews wrote:
[snip]
> > So how does a framework differ from a GUI toolkit with several abstraction
> > layers?
> 
> A toolkit is like a box of Legos:  you snap the supplied pieces together as you
> see fit, supplying all the "structure" of you app de novo;  a frameword IS that
> structure, prebuilt, with pre-defined "hotspots" at which you can plug in
> specializations of a set of interfaces defined by the framework.  If the
> framework's internal model of the problem domain is appropriate to your
> application, you write maybe 10% or less of the code required to implement the
> same app using the toolkit;  this is the classic "programming by difference." 
> Mismatches between the framework's paradigm and your needs are VERY hard to work
> around, however (you can't add unforeseen hotspots to a framework without
> hacking into it).

Actually, the Delphi VCL is pretty good at avoiding this problem, as it is 
extremely open-ended and doesn't exclusively subscribe to the "black box" 
philosophy of (eg.) Visual Basic. Otoh, it _can_ be viewed as a black box, an 
intensional side-effect of its strict component/publishing design.

Incidentally, the VCL does not preclude mixing frameworks. It's possible to 
write programs that utilize the Win32 API, and then have one deeply implemented 
function bring up a Delphi form. Delphi's VCL structure does not force the 
framework on you.

Imho a good Python GUI framework should not limit your application to using 
only that one framework.

-- 
Alexander Staubo     http://www.mop.no/~alex