On Jan 27, 5:50 pm, Kevin Walzer <k...@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! ;-) -- http://mail.python.org/mailman/listinfo/python-list
