WxPython versus Tkinter.

[Kevin Walzer]

On 1/27/11 1:11 PM, rantingrick wrote:
> Actually we don't want "Robins wxPython" in the stdlib "as is" anyway.
> What we DO want is an abstraction API for the short term that plugs
> into Robin's wx. Then over the long term we will either convince him
> to create a better API OR just create our own wxPython directly from
> WxWidgets and mold it into the stdlib. So hinging on the argument of
> what one*single*  man thinks is a non-starter.

I saw this comment elsewhere in the thread, and I'm a bit confused. As I 
understand it, you want to layer a Tkinter-style abstraction API over 
wxPython? You had mentioned that you want to include something like 
Tkinter's grid/pack/place management API's,  its event-handling 
mechanism, its use of tags, and a few other things?

I'd like to suggest that these things are already in the stdlib, in the 
form of Tkinter itself. And at least some thing these things are tightly 
bound to Tkinter's inclusion of the Tcl interpreter. For instance, Tcl 
has a powerful and flexible event loop mechanism. Does wxWidgets have 
something similar? And are Tkinter's grid/pack/place geometry managers 
(which are defined at the C level) compatible with wx sizers, which are 
also defined at the lower C++ level?

While this thread has taken many twists and turns, it nonetheless seems 
to me that the proposal being offered is to layer a Tkinter-style API 
over a Tkinter-scale subset of wxPython's widgets (listbox, button, 
menu, etc.). After all that work, what would really be gained? We'd have 
the same small core of widgets, with an arguably less stable base (since 
wxPython seems to have problems with segfaults on Linux).

It is not persuasive to say that Tkinter is "legacy" while wxPython is 
"the future." Both Tk and wxWidgets date to the early 1990s. Tk did 
stagnate for a number of years, but its development in the past few 
years has been reinvigorated by the ttk themed widgets, in addition to 
various extension packages that use Tk's C API, and it is now a peer to 
wxWidgets in its GUI capabilties. I can't speak to Tkinter's performance 
relative to wxPython and the Tcl interpreter, but any performance gains 
that are achieved by wxPython's underlying C++ library may be obviated 
by lesser stability.

After all the back-and-forth, I am simply not persuaded, especially 
since the proposal being offered is not to replace Tkinter with wxPython 
in the stdlib, but to instead replace Tkinter with a yet-to-be-designed 
wxTkinter amalgamation (a Tkinter body on a wxPython chassis).

--Kevin
-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com