On 3/15/06, robert <[EMAIL PROTECTED]> 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 > -- http://mail.python.org/mailman/listinfo/python-list
