WORKAROUND & the Python GUI-lib situation ...

[robert]

Chris Mellon wrote:

> 
> win32gui and wxPython use *exactly* the same controls in almost all

(win32ui or win32gui? the later is almost only a better ctypes replacement )

> cases. If you're seeing something "donald duck" then you're either
> doing something wrong, or you're using a custom control. wx is also in
> a far better position for most non-trivial UIs, becuase it has
> infrastructure that win32 (pretty much alone among modern UI toolkits)
> lacks, like layout algorithms and i18ln support.

Yes, wx is of course fat.
But I guess things like a layout algorithm ? is done very quickly in a 
clean Python only lib. I can just imagine ...

>>Testing the latest wx and Boa last week (for py2.3) it hit the
>>high-score: All other old win32api/ui apps - just by starting them -
>>press magically buttons themslef, raise this and that. Never saw such
>>behaviour. wx modified something in the libraries. There were new
>>Windows ctrl-libs in the main Python folder after wx-install (which I
>>never requested/allowed). But even removing them did not heal the
>>ghostly behavor of normal win32 apps not having anything to do with wx.
>>Only after uninstalling wx & boa win32 was stable again...
>>
> 
> 
> I dont know where you get your wx libs from, or what "press magically
> buttons themself" means, but the official wx installer doesn't do any
> of this. Whatever you saw had nothing to do with wx.

that last test was with py2.3.5 / pywin32 205 / 
wxPython2.6-win32-ansi-2.6.2.1-py23.exe

then run a few dialog examples of win32 and the dance begins.


>>There are some other (open) things like PyFltk and worse ...
>>
>>In my opinion the overall situation of Python GUI's (platform
>>independent) is not in line with and not up to the level of the
>>wonderful language itself and to its stability.
>>There is always a fragile TCL or XY-C++ or MFC or this and that in the
>>middle - and I can't believe, that it is necessary. Python is a best OO
>>language for GUI programming also and it should glue soon to OS-libs
>>(win32api/gui../ctypes , gtk, ...) .
>>
>>I'd believe there is still room for a relly good, platform independent
>>speedy, flat, python-only OO GUI library - which loads modules with
>>discipline into memory, allows building distributables below 2MB,
> 
> 
> Python all by itself is bigger than this unless you totally gut the
> standard library, and even then it's just barely under 2MB.


???

This  2-liner hello world 1.py with win32ui(=MFC) of this thread with 
py2exe / cx_freeze / py2.3 / win32ui 205 is all compressed 869kB ,  or 
even 700 kB with upx&7zip.


A quite big app (upx'ed) with win32ui, ssl, enc., unicode and all ..

                                  app.zip 683 kB
                                  app.exe 8 kB
                              _socket.pyd 16 kB
                                 _sre.pyd 18 kB
                                 _ssl.pyd 192 kB
                              _winreg.pyd 11 kB
                             datetime.pyd 17 kB
                         pywintypes23.dll 39 kB
                          unicodedata.pyd 167 kB
                             w9xpopen.exe 3 kB
                             win32api.pyd 21 kB
                       win32clipboard.pyd 6 kB
                             win32gui.pyd 25 kB
                            win32help.pyd 11 kB
                            win32task.dll 21 kB
                              win32ui.pyd 156 kB
                                 zlib.pyd 23 kB
                                  AES.pyd 13 kB
                             Blowfish.pyd 11 kB
                                 DES3.pyd 9 kB
                               select.pyd 5 kB
                             python23.dll 361 kB



.. is not more than 1700kB.  That competes with Delphi.

A real Python OO GUI lib would be similar in size, maybe even smaller. 
you'd hardly get more than 2MB (without docs) after all compressions.


>>Python first should maybe have a real Python GUI toolkit and unite the
>>OS'es directly - as good as it does for the os module ?
>>
> 
> 
> Even a minimal GUI toolkit is an order of magnitude more complicated
> than the os module.

Of course its some effort, but with Python you code very very fast.

Once a basic OO message handling system is wired and the first commctrls 
of Windows are covered and resembled on the other systems, things would 
go very fast. Resembling indispensable things of MFC/wx like 
tool/statusbars, docking windows, ...  can also be coded quickly with a 
clean python GUI system. And soon first professional apps could be built 
... the more I think about it

Most effort would be to have a mature, compatible event system. wx 
learned it anyway from Windows (WM_ -> EVT_ ) and resembled it more on 
Linux, etc.

That would be principally ok here too, as Windows is quite good in this 
(despite the rest of the OS). One could "steal" a few principles, 
abstract algs. and even names in less time than gluing the fragile C++.

Robert