Defining VCL-like framework for Python

[Alexander Staubo]

In article <37437C55.3E49 at cosc.canterbury.ac.nz>, 
greg at cosc.canterbury.ac.nz says...
> Alexander, I'd like to put in a vote of support
> for your Python VCL project. I hope you won't be
> put off too much by all the negative comments it
> seems to have elicited.

I am, but your vote of support does help. I'm against reinventing wheels, 
but I don't mind improving on an invention, the wheel included.

> I, for one, agree that there is a need for a
> cross-platform GUI *framework* for Python (as
> opposed to a toolkit). 

Rightyouare. And hopefully not just a GUI framework, but a generic 
component framework, too; happily Python promotes componentization and 
supports run-time discovery and persistence, so a lot is already there.

Unfortunately, as I pointed out earlier, cyclic references make 
parent/child relationship hard to implement cleanly. The best workaround 
I've found is to have classes implement a common "pre-destructor" that 
must clean up any external references to prepare it for destruction.

>I even started a project
> of that sort myself a while ago, and so did
> a couple of other people. There was even a SIG
> started on the topic, although the mailing list
> is currently inactive due to lack of use.
>
> If you want to see what I came up with, check out:
> 
> http://www.cosc.canterbury.ac.nz/~greg/python_gui/
> 
> The current version is based on the Python X/Motif
> module. I'm (slowly) working on another version based
> on a direct SWIG interface to Xlib, and I may start
> on a Mac version at some future date.
> 
> I'll be interested to see what you come up with!

Interesting -- I'm going to look at your stuff. Are you aware of the link 
rot on your page (broken links, that is)?

I note that your proposal is mainly focused on _visual_ components, and 
as far as I can see does not take into consideration _nonvisual_ 
components. For example, a database-aware editing control might need a 
database connection, which could be implemented as a nonvisual component.

For event handling, I prefer using a cross between local event management 
and event sink: As in Delphi you would either assign an event handler to 
some On* attribute (eg., OnMouseDown), or register an event sink, which 
is basically an object with a corresponding set of On* attributes.

I have lots of ideas -- and even some beginnings of the actual code -- if 
you're interested in a brain meld.

-- 
Alexander Staubo             http://www.mop.no/~alex/
"Give me an underground laboratory, half a dozen atom smashers and a beautiful 
girl in a diaphanous veil waiting to be turned into a chimpanzee, and I care 
not who writes the nation's laws." --S. J. Perelman