WxPython versus Tkinter.

[rantingrick]

On Jan 27, 5:50 pm, Kevin Walzer <k... at codebykevin.com> wrote:
> On 1/27/11 1:11 PM, rantingrick wrote:

[...]

Hello again Kevin and nice to have you back!

Yes the minor details have been evolving over the course of this and
another thread. We have been floating new ideas all along the way in
an effort to get the best result. In the very beginning because we all
know that wxPython IS HUGE i offered a divide and conquer approach...

 * Small "Tkinter-like" stdlib module.
 * Full featured third party download.

By doing this we can keep the stdlib smaller and leave the bulk of wx
in a 3rd party download. Then we floated around installing the entire
wxPython library because after all hard drives are only getting
bigger. However i think that neither are the best Option.

In any event the ideas (like any ideas in a lively discussion) are
very fluid in nature. Part of generating the best conclusion is by
twisting and turning every idea until it fits neatly into some stated
goals. And yes, we want to get the most bang for our community buck!

I am now convinced that "Robins wxPython" is woefully inadequate due
to the API. We can never consider putting such a blasphemy into the
stdlib. Does that mean we should ignore the great benefits of
wxWidgets? HELL NO, we would be fools if we did!

Now i am thinking along the lines of an abstraction API that plugs
into wxPython. We keep Tkinter until say "Python4000", but in the
meantime we create a "pythonic wxPython" from the ground up (stealing
as much as we can from Robin!). By doing this we can integrate
wxPython at whatever rate the community can bear at the time.

The only thing better would be to convince all GUI library creators to
start thinking globally. To start setting a global standard for all
GUI libraries. Then all we would have to do is create a Python API and
just "plug" it in generically to WX, TK, GTK, QT, Etc, Etc. I know
this sounds like a pipe dream, but this is what must happen at some
point. And we should all be demanding this everyday. Always Remember:

  Selfishness = Multiplicity = Entropy = Shock = Stagnation = None


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

Yes this discussion has taken many turns. Read my previous statement
for insight.

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

Yes Tk has just recently "come out of stagnation". But for how long?
How long must we wait for them to "get it together"? Thats my point.
We will all be dead and rotting by the time Tkinter is including a
ListCtrl and accessibility. And i don't know about you Kevin, but i
really don't want to wait that long!

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

wxPython IS NOT less stable than Tkinter: That is a FACT. However,
WxPythons API was written in such a horribly unpythonic way (sorry
Robin) that someone could find themselves in trouble IF they are not
experienced enough to use the library. However, we can easily fix an
API. What we can't fix is lack of vision and stagnation in an outside
community. We must help ourselves because no one else is going to do
it for us!

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

Not exactly Kevin. What i intend to do is take your Yugo (Tkinter) to
my shop and rip out the antiquated engine, rusty transmission, and
remove those "may-pop" tires. Then i plan to replace them with the
best high performance parts that are available (wxWidgets) and
probably even give her a nice paint job too (Tkinter API)! And when i
am done, all your friends are going to be jealous and all the women
are going to want a ride in your new hotrod.

Kevin, i am going to make you the coolest cat in town! But nobody said
it was going to an easy task!  ;-)