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