WORKAROUND & the Python GUI-lib situation ...

Wed Mar 15 11:28:51 EST 2006

On 3/15/06, robert <no-spam at no-spam-no-spam.com> wrote:
> 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 )

Both. wx wraps native controls. If you see something out of place it's
either a custom control for whatever reason, a control win32 doesn't
have (people often assume that Office is "native" windows, it is not),
or something you're doing wrong.

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

I can't give you any sort of diagnosis without more information about
what actually happened. I don't use python2.3 so it's remotely
possible that could be related, but wxPython doesn't put anything in
the base Python dir so I suspect that there is more going on here than
is immediately obvious.

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

Sorry, I was talking about Python 2.4, which is much larger (unicode
conversion tables, I think). 1,824KB, which can be packed down to a
bit less than 800k by UPX (at the cost of not being able to share it
betwen processes)

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

I think you seriously understimate the work involved in such a system.
Especially if you want them to have native look & feel thats
comparable to what wxPython offers. If you give Python a 10x LOC
advantage (not unreasonable) and a 5x productivity advantage you're
still looking at at least 100k LOC and 5+ man-years to create the
equivilent to Qt or wxWidgets in pure Python. And starting on Windows
is really a pretty poor plan - the toolkits on other platforms are far
more capable. wx already suffers in places because of a
windows-centric API that precludes access to more powerful features on
other platforms.

Don't let me stop you, though.

> 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
> --
> http://mail.python.org/mailman/listinfo/python-list
>