WORKAROUND & the Python GUI-lib situation ...

[Chris Mellon]

On 3/15/06, robert <no-spam at no-spam-no-spam.com> wrote:
> PyDenis wrote:
>
> > I fixed problem using Atypes:
> >
> > import ctypes
> >
> > ctypes.windll.user32.MessageBoxA(0, 'test', 'Title',
> > win32con.MB_ICONINFORMATION | win32con.MB_OK |
> > win32con.MB_TOPMOST)
> >
> >
> > It compiles and runs fine with py2exe.
> >
> >
> > Dont remember buggy pywin32 :)
> >
>
>
> better use win32api.MessageBox
> win32api/gui/...  are flat modules unlikely to have errors.
>
> I tested your 2-liner with build207/py2.4.2 and build205/py2.3.5 with
> py2exe and cx_Freeze in each combination and could not reproduce the bug
> on XP, W2K and 98.
> ( The DestroyWindow bug appears only for more complex apps explicitly
> using .DestroyWindow from certain Notification Handlers; the dual core
> bug does not apply here )
>
> I'm curious what it is?
> If you could post a bug - if reproduceable - with all your detailed
> context data to pywin32 project/bugs on sf.net, that would be fine.
>
> --- Python GUI situation:
>
> win32ui most probably is responsible for this bug; its a complex beast
> with lot of descriptional status (MFC).
> win32ui wants a mainframe, a document-template, an all that like until
> you can do any simple thing  :-( :-) But once settled and maybe hiding
> its added complexity in a custom wrapper you can program quite fluid
> apps with official Windows look&feel with it.
>
> Yet in my recent tests with wxPython (I tried now 4x over years to get
> something stable with wx :-( ), Boa, Kommodo, ...  I had so much more
> freezes and damages, and fat memory consumption and slowness and
> fatigue, and funny appearance, that I'd say, for Windows its better to
> live with win32ui for non-trivial GUI's (especially distributable ones),
> which appear and behave like real Windows apps - and not like something
> copyied from a Donald Duck magazine.
>

win32gui and wxPython use *exactly* the same controls in almost all
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.

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

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

>raises
> only Python exceptions and would even attack Delphi in terms of
> stability, endurance, VHL language typing speed - first by Pythons
> qualities, and quickly by features (for which people would contribute
> very quickly if a good plan is raised).
> ( But maybe I'm only dreaming ... ? )
>
> Anygui was an academical test.
>
> Some want to see wx as standard Python GUI lib. In my opinion thats
> compromising cheaply with a C++ monster for producing clumsy test
> in-door apps by carefully avoiding too much stepping with broken builds ..
>
> It is strange, that each of the big python IDE's uses another GUI
> toolkit: In an urge they use everything from Tk and to even the 20MB
> MozillaWindowing-Toolkit (Komodo; I dropped 3.5 yesterday from my HD
> after it core-dumped on second start and stepped 20x slower in the
> debugger than PythonWin, no consistent Interactive Win/history, 100MB in
> memory, .. ).
>
> 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.

>
> Robert
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>