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

[Andrew MacIntyre]

I've used Venster for my Windows apps, but admit to not really using all
of its capabilities and to using archaic versions of Python and
ctypes...  Pity that it appears to have been abandoned by its original
author, as it has worked wonderfully for me.

-------------------------> "These thoughts are mine alone!" <---------
Andrew MacIntyre           National Licensing and Allocations Branch
tel:   +61 2 6219 5356     Inputs to Industry Division
fax:   +61 2 6253 3277     Australian Communications & Media Authority
email: andrew.macintyre at acma.gov.au 

> -----Original Message-----
> From: 
> python-win32-bounces+andrew.macintyre=acma.gov.au at python.org
> [mailto:python-win32-bounces+andrew.macintyre=acma.gov.au at pyth
on.org] On Behalf Of Thomas Heller
> Sent: Saturday, 29 November 2008 7:46 AM
> To: python-win32 at python.org
> Subject: [python-win32] Does Python need a native Windows GUI toolkit?
> 
> 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.
> 
> --
> Thanks,
> Thomas
> 
> _______________________________________________
> python-win32 mailing list
> python-win32 at python.org
> http://mail.python.org/mailman/listinfo/python-win32
> 

If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents.
 
Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA.