From: earlybird at mop.no (Alexander Staubo)
Date: Mon, 24 May 1999 06:17:04 +0200
Subject: Defining VCL-like framework for Python
References: <1284777593-1647219@hypernet.com> <7i9nn5$a9m$1@cronkite.cc.uga.edu> <3748B569.3973A8E4@palladion.com>
Message-ID: <MPG.11b2f1272831bc55989688@148.122.208.74>
Content-Length: 1645
X-UID: 1906                                                 

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




