[python-win32] Does Python need a native Windows GUI toolkit?

[Stef Mientki]

Don't most people nowadays wants, and maybe even needs, OS-independant 
applications ?

cheers (from a happy wxPython user, formely a happy Delphi user ;-)
 
Stef Mientki

Thomas Heller wrote:
> Does Python need a native, pure Python, Windows GUI toolkit, one that uses
> win32 api calls directly to use native windows controls?
>
> Or would that development be a waste of resources, in these days of
> of Python.NET, Windows forms, IronPython, (and last, not least, wxPython
> and all these other toolkits)?  Or are desktop applications too rare now?
>
>
> Several years ago I started using wxPython (it is probably a lot more
> mature now) to write some simple programs and was not really pleased.
> It looked too much like MFC to me.  I know that there are now several
> wrappers over wxPython (althogh I have not used them) like Pythoncard
> or newer ones like dabo (from what I hear). There have also been other
> attempts to make nicer interfaces for wxPython which have vanished nowadays.
> Somehow I have the impression that the approach to put layer over layer over layer
> is wrong (wxWindows C++ layer, wxPython SWIG layer, Pythoncard/Dabo/whatever
> python layer).
>
> So, I started writing my own framework, also several years ago.  I used
> ctypes (early versions) to call the win32 api directly, and it was fun
> and it worked out great.
> I have my own form editor, I can also construct windows, dialogs,
> menus, and so on with simple high level code. But also it is possible
> even at the 'highest level' to directly reach out to the win32 api, or
> to handle WM_xxx messages directly if the need arises.
>
> However, this framework is showing its age because during all this time
> I developed some new approaches to make the work easier (for example first
> I wrote the win32 plumbing code manually, now I have tools that automatically
> generate the code to access constants, define structure definitions, or generate
> function prototypes from the windows header files.  Also the framework too much
> relies on manual conversions between byte and unicode strings.
>
> So, the question is:  Are there people that share these ideas?
> Are they willing to join a coordinated effort to develop a framework
> like this, using the current and future Python versions, and all the fancy
> new features of Python?
>
> No promises, but I'm curious for the thoughts on this.
>
>