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

[Werner F. Bruhin]

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?

I would consider it a waste of resources.

I use wxPython and if I would change today to something else it would 
probably be a web/html based tool kit.  Why, the only issue I have found 
with wxPython is that it is too large for devices such as 
Palm/iPhone/WinMobile.  Unless one invests in some professional tools (I 
am only aware of WinDev, but there must be others) one can not develop 
one app which runs on these mobile devices and on desktops.
> 
> 
> 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).
I think that wxPython is doing a very good job for desktop apps, while I 
see your argument about too many layers I do not think this is that big 
an issue today.  It is much more important to be productive - i.e. to be 
able to generate a good looking GUI as quickly and easily as possible.

Dabo might be a contender for a desktop app, also I have the impression 
that they are trying to do everything themselves instead of re-using 
available tools (db layer instead of e.g. sqlalchemy, report designer 
instead of e.g. Report Manager, logging instead of Python logging, 
screen designer instead of e.g. XRCed).
> 
> 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?
I hope you will find something which will be fun for you and which will 
improve an existing project.

Anyhow, thank you for all the things you have already done for the 
community like ctypes, py2exe and probably other things I am not aware off!

Werner