Re: WxPython versus Tkinter.

Discussion in 'Python' started by Octavian Rasnita, Jan 27, 2011.

  1. From: "Brendan Simon (eTRIX)" <>
    > Since it seems the python motto is "Batteries included", then it would
    > seem to me that wxPython is the natural fit as it also has "Batteries
    > included" (e.g. accessibility, native look-n-feel, mature and evolving,
    > can produce simple or complex gui programs, etc, etc).




    Yes Brendan, you are perfectly right, but unfortunately WxPython developers
    don't want to have it included in the stdlib.
    Finally I understood that this is the main problem, because if they would
    want to do it in the conditions imposed by Python, it would have been much
    easier and many of other problems could have been solved.

    But WxPython is their work and they decision is their.

    Octavian
     
    Octavian Rasnita, Jan 27, 2011
    #1
    1. Advertising

  2. Octavian Rasnita

    rantingrick Guest

    On Jan 27, 1:28 am, "Octavian Rasnita" <> wrote:
    > From: "Brendan Simon (eTRIX)" <>
    >
    > > Since it seems the python motto is "Batteries included", then it would
    > > seem to me that wxPython is the natural fit as it also has "Batteries
    > > included" (e.g. accessibility, native look-n-feel, mature and evolving,
    > > can produce simple or complex gui programs, etc, etc).

    >
    > Yes Brendan, you are perfectly right, but unfortunately WxPython developers
    > don't want to have it included in the stdlib.


    [...]

    > But WxPython is their work and they decision is their.


    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.

    We all respect Robin however python is greater then me, then you, and
    yes, EVEN Guido van Rossum! Python belongs to the world now. And what
    is best for Python's community AS A WHOLE is what we should be
    concerned about.
     
    rantingrick, Jan 27, 2011
    #2
    1. Advertising

  3. On 1/27/11 10:11 AM, rantingrick wrote:
    > On Jan 27, 1:28 am, "Octavian Rasnita" <> wrote:
    >> But WxPython is their work and they decision is their.

    > Actually we


    The word "we" does not mean what you think it means.

    --

    Stephen Hansen
    ... Also: Ixokai
    ... Mail: me+list/python (AT) ixokai (DOT) io
    ... Blog: http://meh.ixokai.io/


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.10 (Darwin)

    iQEcBAEBAgAGBQJNQcGiAAoJEKcbwptVWx/llq4H/j00UI6eT8nLutDdUqDKRp9c
    VutbYF9YvN2uJSNeqevLVJMvx78TPvR+wTOSqAKBSGD3U5TpQnrPr8xcU1VvrO7p
    ZIPBxz4R/823Hti+OIwx0VB2z1Nqjj9lPHP8s5w87pbJFqz3o+dRH7nJualr+It8
    JarahNaKFy7PQc3s6QR0D1fMw7QCbY52Mv9/94nOspDF4K2XsC+huXjvaqUnkwE7
    F3VXmsU/bdsAttG+VTGeAK27SfrIEmYCDy66A3PG/bj4EGrp3LHsJ7Jbgv5QVcoD
    jQ3r7miKgnjxDb7cmf7VfDjrmW6RRHvjW3lav+t2m8chWt79WBZowveVsbbX7kg=
    =SRRv
    -----END PGP SIGNATURE-----
     
    Stephen Hansen, Jan 27, 2011
    #3
  4. Octavian Rasnita

    Kevin Walzer Guest

    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
     
    Kevin Walzer, Jan 27, 2011
    #4
  5. Octavian Rasnita

    rantingrick Guest

    On Jan 27, 5:50 pm, Kevin Walzer <> 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! ;-)
     
    rantingrick, Jan 28, 2011
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Matthew Louden
    Replies:
    1
    Views:
    7,114
    Scott M.
    Oct 11, 2003
  2. Russ

    script versus code versus ?

    Russ, Jun 10, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    2,540
  3. rantingrick
    Replies:
    220
    Views:
    3,595
    Gregory Ewing
    Mar 2, 2011
  4. Littlefield, Tyler

    Re: WxPython versus Tkinter.

    Littlefield, Tyler, Jan 25, 2011, in forum: Python
    Replies:
    130
    Views:
    2,011
    Gregory Ewing
    Mar 3, 2011
  5. Paul Butcher
    Replies:
    12
    Views:
    784
    Gary Wright
    Nov 28, 2007
Loading...

Share This Page