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

[Hendrik van Rooyen]

Thomas Heller <theller at ctypes.org> 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?
>

My own work is only peripherally involved with windows stuff.
However, in the last few weeks, I got involved in a maintenance
job where the original author had used the Boa Constructor IDE.

My reaction, as I got into using the thing, has been positive - it
enables someone like me, who's GUI experience has been limited
to tkinter stuff, to actually use wxPython , which has a vastly
greater learning curve.

I expected something a little rinky dink, but I was pleasantly
surprised - everything that one needs seems to be there, and
it all seems solid - the logical bits all work, and even the editor
is almost tolerable, although the interactive interpreter could use
some enhancing as far as using the history is concerned.

So when I read your post, my reaction is: Why would he want
to do that? - His time would be better spent polishing Boa up a bit,
as it really needs very little to make it a worthy Delphi competitor...

8< --------------------------------------------------------------------

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

As a broken down assembler programmer, I have a lot of sympathy with
this view - the stuff is already all too horribly complicated, and a lot of
code does not actually do anything other than call other code that calls other
code that calls other code...

That said, however, I don't really have a solution, as something like
wx-widgets represents what looks like man years of effort, which
would be folly to attempt to duplicate, just for the benefit of cutting
out a few calls at run time - it is a lot cheaper nowadays to just
buy more processing power and memory.

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

So here is the makings of another Delphi, with by now a heck of a lot
of man hours in it.  It must be kind of hard to hear me say, sight unseen,
that you should throw it away and use or enhance Boa.  Nobody likes
to hear that kind of thing, as all of us run mainly on ego - hell if you do
not have an ego the size of a small country, you will never make it as a
programmer...

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

If you had asked this Question a month or so ago, I would have been
more in favour of it than what I am today - and all because I have
in the intervening time, been forced into a nodding acquaintance with
Boa.

Maybe you should look at Boa and see if you can tinker with it a little-
somebody with your level of skill could probably make it a lot slicker
than what it already is - I am conjecturing, but it may be possible,
if you know the platform is windows, to cut out some of the repetitive
calling type stuff referred to above, and go directly to the OS.

- Hendrik