Bill Janssen <[EMAIL PROTECTED]> wrote: > > > Python already comes with a standard GUI toolkit; tk. > > With a decidedly unpythonic bad interface. And it's not standard; I > frequently find Python installations where no one has installed Tk. > Pardon me for being blunt: Tkinter is a half-assed "solution" that's > set Python back for years.
No argument here; I tried to use Tk, spent a weekend with it, got frustrated, tried wxPython, and was going in about 30 minutes. I've only ever really dealt with Windows GUI programming, so it was certainly my mistake to assume that Tk was always available with Python. > > Also, while I > > generally like Greg Ewing's work (Pyrex has saved me so much brain power > > interfacing with C extensions), PyGUI doesn't have nearly the market > > penetration (into the Python GUI toolkit area) to justify its inclusion > > into the python standard library. > > Doesn't matter. Putting it into the stdlib will solve the penetration > problem. Yes and no. It will only really solve the penetration problem it if it actually superior to the other options available (in widget availability, ease of use, etc.). Note how Tk in Python isn't used nearly as often as wxPython is? > > Also, it would require shipping a Python GTK binding, which would > > basically necessitate shipping GTK+ with Python. > > No, it wouldn't. It runs natively on Mac OS X, and could be made to > do on Windows. I'd suggest using the existing GTK+ binding for Linux, > and only in the interim for Windows. I certainly wouldn't ship GTK+ > with Python, or wxWindows either. As I suggested, I think that it > would be a good idea to do a PyGUI port to a lower-level system, such > as cairo, for more generic use. I wouldn't object to shipping cairo > to those few systems where it won't be pre-installed. Ultimately, PyGUI is essentially a wrapper of native or near-native widgets into a common interface. wxPython is exactly the same thing, only it has a much larger user base, developer support, and (native and emulated) platform support. Similar things can be said about the GTK and Qt bindings for Python (at least in terms of user base, developer and platform support), but I don't have experience with PyGTK or PyQt, so cannot comment on their quality/support/etc. versus wxPython. I should also mention that while it would take Greg and/or others a time to go and wrap the Windows native widgets, it has already been done with wxPython. > > it's market penetration (into the Python GUI toolkit area) > > is growing steadily > > Pointless consideration. Tkinter has a great penetration, but it's a > bad solution. It is not pointless. Even though it is more difficult to install wxPython than Tk (which should have build rules in the Python source, and should be distributed with the Python binaries, if I understand correctly), it is still used far more than the Python Tk bindings. In this case, wxPython's market penetration at least suggests higher-quality. - Josiah _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
