Defining VCL-like framework for Python

[Alexander Staubo]

In article <374286A0.77374B26 at infercor.no>, paulb at infercor.no says...
[snip]
> > Imho, Python needs a better windowing toolkit than is provided by
> > Tcl/Tkinter today. That's just me. Furthermore, Python does not have (at
> > least afaik) a component-based system for building applications. Python
> > provides many facilities that the VCL defines -- such as persistence and
> > RTTI-like mechanisms -- but afaik there is no well-defined protocol for
> > creating cross-module components.
> 
> Could you clarify what you mean by "cross-module components"? As for the Tkinter
> issue, surely there are now more than ever some real alternatives to Tkinter for
> developing graphical user interfaces. I note that wxWindows is now at version 2
> and gaining some momentum - wxPython is even promoted on the wxWindows home
> page.

By cross-module components I mean a defined protocol for publishing 
component-like objects. Think "like JavaBeans" and we're getting closer.

> [Description of goals cut]
> 
> > One definite guideline here is not to rely on third-party windowing
> > system support: in other words, the project will not use wxPython,
> > Tkinter or any other library, although not precluding the ability to
> > write controls that use such libraries internally.
> 
> Could you explain this decision a bit more? It would seem to me that taking
> advantage of one of the more established toolkits would save a lot of extra work
> and allow you to concentrate on the "higher level" aspects of such a project.

Indeed, although I don't agree that the project should be written around 
a specific toolkit. Certainly, the base controls could be written using 
Tkinter/GTK/QT/wxPython/whatever on one platform (eg., UNIX); on another 
platform, such as Windows, it would probably be more efficient _and_ 
cleaner to have the controls write "directly to the metal".

Most windowing toolkits introduce their specific paradigm for creating 
visual "widgets", and they keep you enclosed within the limits of this 
paradigm. I'd like a system where I could write a part of my 
application with Windows-specific code, or X-specific code, or both (eg., 
"if windows:"), with the aim to milk a platform's GUI support for 
everything it's worth. For example, OLE-based drag and drop support is 
unlikely to exist for UNIX: But I might want that in. Or perhaps I'd like 
to trap specific control messages that do not exist on the Mac.

Afaik, things like Tkinter are "widget libraries". I'm aiming for both a 
higher level of abstraction, and a more complete approach -- cover more 
bases, so to speak.

[snip]
> Arguably, Tkinter doesn't even "suck". Yes, people do wonder about the Tcl
> dependence from time to time, but this is only really a consideration where
> installation issues (restrictions, managing versions of lots of different
> packages) are more important than usual.

Different strokes for different folks, I guess. A big beef with Tkinter 
is that it requires 1.4MB worth of runtime DLLs to be bundled with any 
application.
 
> > Note that the project I have delineated here is not about "reproducing
> > Delphi in Python". At least not yet. :) I want mainly to steal a few good
> > ideas, improve others, and create something that makes Python more
> > valuable to those "visual" programmers out there -- one of whom I don't
> > necessarily count myself, although I sure miss a good windowing toolkit
> > in Python; it deserves one.
> 
> It would indeed be good to create such a tool, but I do question the need to
> write an entirely new toolkit to achieve this.

Actually I did expect the Spanish Inquisition when I wrote my proposal, 
but I'm still surprised by the response.

-- 
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