Tkinter: The good, the bad, and the ugly!

Discussion in 'Python' started by rantingrick, Dec 29, 2010.

  1. rantingrick

    rantingrick Guest

    Tkinter: The good, the bad, and the ugly!
    -----------------------------------------
    An expose by rantingrick


    ----------------------
    The Good
    ----------------------
    Back in the early days of Python --when this simplistic beauty of
    programming bliss we enjoy today was just a tiny glimmer of hope in a
    archaic world plagued by dark forest of braces and jagged caverns of
    cryptic syntaxes-- our beloved dictator (Mr. Van Rossum) had the
    foresight to include a simplistic GUI toolkit that we call Tkinter
    into the stdlib. And he saw that it was great, and that it was good,
    and so he rested.

    And when the first python programmers used this gift handed down from
    the gods they were pleased. They could see that all of the heavy work
    of cross-platform-ism landed square on the shoulders of TCL/Tk and all
    Python had to do was wrap a few methods to wield the beast we all know
    as graphical user interfaces.

    Life was good, people were happy...but darkness loomed on the
    horizon...


    ----------------
    Enter the Bad
    ----------------
    However as we all know there exists no real Utopian bliss without many
    pitfalls and snares. Since Tkinter is just a wrapping of some TclTk
    calls the people realized that they are now at the perilous mercy of
    another group of developers (psst: thats the TCL folks!) who have only
    their own goals and dreams in mind and could care less for the
    troubles of others. They realized that Tkinter was lacking. However
    this lacking was not Tkinters fault, no, the fault lye with TclTk. And
    to compound these problems they also realized that in order to fix the
    design problems inherit in TclTk they must learn an obscure and mostly
    useless language... TclTk!!

    --------------------------------
    Utterly destroyed by the Ugly!
    --------------------------------
    And then the people became very angry... "What a double cross!" they
    chanted. Why should we learn a language like TclTk just to fix
    problems that the TclTk folks need to fix themselves? Would not that
    time be more wisely spent in looking over code that is 100% Python and
    modifying it? Not only would our community benefit but we can
    propagate the maintainece and/or improvements to a wider group of
    folks by removing the high entrance requirements. When we elevate
    every python programmer to a PythonGUI maintainer then we will have
    achieved community nirvana!

    We have now reached a point where the very simplicity we have embraced
    (Tkinter) has become a stumbling block not only for the users of
    Tkinter, but more devastating is the damage this TCL/Tk monkey has
    done to keep our fellow Python brothers and sisters from learning how
    a GUI kit works (behind the scenes) with each OS to bring all this
    graphical stuff to life.

    ------------------------
    So what should we do?
    ------------------------
    The answer is simple. We need a 100% Python GUI. A GUI coded in Python
    from top to bottom. A GUI that is cross platform to the big three
    (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but
    also a GUI that can be manipulated by the average python programmer. A
    GUI that not only teaches the fundamentals of using a GUI, but also a
    GUI that teaches how a GUI works under the hood

    Then and only then will Python be truly what GvR intended. I want
    everyone here to consider what i am proposing and offer some opinions
    because it is time for change.
    rantingrick, Dec 29, 2010
    #1
    1. Advertising

  2. rantingrick

    Katie T Guest

    On Wed, Dec 29, 2010 at 11:58 PM, rantingrick <> wrote:
    >
    > Then and only then will Python be truly what GvR intended. I want
    > everyone here to consider what i am proposing and offer some opinions
    > because it is time for change.


    What's your opinion of the other gui toolkits with Python bindings
    like PyQt and PyGtk?

    Katie
    --
    CoderStack
    http://www.coderstack.co.uk/perl-jobs
    The Software Developer Job Board
    Katie T, Dec 30, 2010
    #2
    1. Advertising

  3. rantingrick

    rantingrick Guest

    On Dec 29, 6:07 pm, Katie T <> wrote:
    > On Wed, Dec 29, 2010 at 11:58 PM, rantingrick <> wrote:
    >
    > What's your opinion of the other gui toolkits with Python bindings
    > like PyQt and PyGtk?


    Hello KateT,

    Well i like wxPython as it is quite well rounded but we all know it
    has some shortcomings too and wx is far too bloated for the stdlib!
    pyQt and pyGtk i cannot comment on because i have no experience with
    them.

    However i need to stress that my intention is towards a 100% Python
    GUI. Not a binding, not a wrapping (except for OS calls!) but a *real*
    Python GUI. The only thing that i know of at this point is pyGUI
    although there are probably others. Allowing the average Python
    programmer the ability to read OS specific calls written in Python
    would not only benefit their GUI knowledge, but also there knowledge
    of OS's in general.

    I guess you could sum it as "Getting the most bang for your community
    buck".
    rantingrick, Dec 30, 2010
    #3
  4. rantingrick

    Gerry Reno Guest

    wxPython looks good but I don't see anyone developing support for things
    like smartphones.

    Also, what do you think about frameworks such as pyjamas? It lets you
    write in python and compiles everything down to Javascript so it can be
    used across the Web as well as on the desktop.
    Gerry Reno, Dec 30, 2010
    #4
  5. From: "rantingrick" <>
    > Back in the early days of Python --when this simplistic beauty of
    > programming bliss we enjoy today was just a tiny glimmer of hope in a
    > archaic world plagued by dark forest of braces and jagged caverns of
    > cryptic syntaxes-- our beloved dictator (Mr. Van Rossum) had the
    > foresight to include a simplistic GUI toolkit that we call Tkinter
    > into the stdlib. And he saw that it was great, and that it was good,
    > and so he rested.



    Yes, for that time it was good.

    > Life was good, people were happy...but darkness loomed on the
    > horizon...


    Not all the people were happy because the darkness disappeared partially for some of them and more and more blind people started to use a computer, and discovered that the Tk interfaces are absolutely inaccessible for them.

    > The answer is simple. We need a 100% Python GUI. A GUI coded in Python
    > from top to bottom. A GUI that is cross platform to the big three
    > (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but
    > also a GUI that can be manipulated by the average python programmer. A
    > GUI that not only teaches the fundamentals of using a GUI, but also a
    > GUI that teaches how a GUI works under the hood



    So it should be a kind of SWING library made in Python, right?
    It is a good idea, but it should not have the problems of SWING and in that case it would be very hard to do.

    First, the interface should look exactly as the native interfaces for each system named, and it should provide the same features, because otherwise the interface would look strange for all the users on all the operating systems.
    And of course, it should not only look OK, but it should also follow the accessibility standards for beeing accessible for screen readers also.

    WxPython is the best GUI because it is fast, even though it is bloated, it uses the native GUI elements on all those 3 operating systems and a relatively good accessibility for screen readers.

    But WxPython still have problems because not all operating systems native GUIS offer the same widgets and features and those features custom-made don't respect the accessibility standards.

    WxPython is fast because it is made in C - it uses the native GUI elements of the OS which are also made in C. Would a Python - only GUI have the same speed? If yes, it would be great.

    Octavian
    Octavian Rasnita, Dec 30, 2010
    #5
  6. From: "Katie T" <>
    > What's your opinion of the other gui toolkits with Python bindings
    > like PyQt and PyGtk?
    >
    > Katie
    > --



    They are not accessible at all for screen readers, so the programs that still use them won't be accessible to all potential users.

    Octavian
    Octavian Rasnita, Dec 30, 2010
    #6
  7. rantingrick

    rantingrick Guest

    On Dec 29, 6:41 pm, Gerry Reno <> wrote:
    > wxPython looks good but I don't see anyone developing support for things
    > like smartphones.


    No wx is not the answer to our problems

    > Also, what do you think about frameworks such as pyjamas?  It lets you
    > write in python and compiles everything down to Javascript so it can be
    > used across the Web as well as on the desktop.


    Hmm, this is like two double edged swords smashing one another in
    battle.

    Sword One: On one hand web frameworks are going to be really big soon
    -- however legacy GUI's are not going away any time soon!

    Sword Two: On the other hand web frameworks provide awesome cross
    platform ability that is surly only going to get better as time goes
    -- however i utterly hate JavaScript (although much worse web
    languages exist!). And sending requests back and forth between Python,
    JavaScript, and BrowserX is also a real PITA. Because even though
    everyone knows this is coming all the major browsers are trying to
    insert their API into the mix. So that Joe Scripter has to write code
    that is compatible between many browsers. Until the world agrees on a
    unified API --AND IMPLEMENTS IT SERIOUSLY-- we are at the mercy of
    drunken sailors at the helm.

    I believe pyjamas has a bright future in the web playground, however
    we still need to focus our community efforts towards a Python based
    GUI. I can see a pythonGUI and pyjamas existing side by side in mutual
    harmony for many years.
    rantingrick, Dec 30, 2010
    #7
  8. On Wed, 29 Dec 2010 15:58:53 -0800, rantingrick wrote:

    > Tkinter: The good, the bad, and the ugly!
    > -----------------------------------------
    > An expose by rantingrick



    Your ideas are intriguing to me and I wish to subscribe to your
    newsletter.


    > The answer is simple. We need a 100% Python GUI. A GUI coded in Python
    > from top to bottom. A GUI that is cross platform to the big three
    > (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but
    > also a GUI that can be manipulated by the average python programmer. A
    > GUI that not only teaches the fundamentals of using a GUI, but also a
    > GUI that teaches how a GUI works under the hood


    I look forward to seeing this software of yours. Let us know when you've
    got some code, and not just empty talk.



    --
    Steven
    Steven D'Aprano, Dec 30, 2010
    #8
  9. rantingrick

    Adam Skutt Guest

    On Dec 29, 7:48 pm, "Octavian Rasnita" <> wrote:
    > First, the interface should look exactly as the native interfaces for each system named, and it should provide the same features, because otherwise the interface would look strange for all the users on all the operating systems.
    > And of course, it should not only look OK, but it should also follow the accessibility standards for beeing accessible for screen readers also.
    >


    Which is where the contradiction comes into play: to use the actual
    native widgets, you have to write some C (or Objective-C). Of course,
    on Windows, people have faked the native widgets so many times that
    you could probably get away with it if you made a really good fake,
    though there are still a lot of gotchas that go with that
    (accessibility and all that "other stuff"). On Linux, it's not like
    there's really a standard anyway. That leaves OS X as the really
    troublesome one.

    >WxPython is fast because it is made in C - it uses the native GUI elements of the OS which are also made in C. Would a Python - only GUI have the same speed? If yes, it would be great.
    >


    Speed is not even on the list of things I'd be worried about first.

    Adam
    Adam Skutt, Dec 30, 2010
    #9
  10. rantingrick

    Kevin Walzer Guest

    On 12/29/10 6:58 PM, rantingrick wrote:
    > The answer is simple. We need a 100% Python GUI. A GUI coded in Python
    > from top to bottom. A GUI that is cross platform to the big three
    > (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but
    > also a GUI that can be manipulated by the average python programmer. A
    > GUI that not only teaches the fundamentals of using a GUI, but also a
    > GUI that teaches how a GUI works under the hood


    Any GUI framework is going to require at least some heavy lifting in C,
    C++ or Objective-C (depending on the platform). A pure-Python approach
    to GUI development is technically infeasible.

    --
    Kevin Walzer
    Code by Kevin
    http://www.codebykevin.com
    Kevin Walzer, Dec 30, 2010
    #10
  11. rantingrick

    Kevin Walzer Guest

    On 12/30/10 10:24 AM, rantingrick wrote:
    > On Dec 30, 8:59 am, Kevin Walzer<> wrote:
    >> On 12/29/10 6:58 PM, rantingrick wrote:

    >
    >> Any GUI framework is going to require at least some heavy lifting in C,
    >> C++ or Objective-C (depending on the platform). A pure-Python approach
    >> to GUI development is technically infeasible.

    >
    >
    > This is a very good point Kevin however i would much rather spend time
    > learning a language like C --which is hugely useful in many
    > contexts!-- than to waste one second of my time on a domain specific
    > language like TCl which is created only for drawing GUIs using Tk. I
    > think everyone can agree that learning C is of benefit far more
    > benefit to anyone in the programming field. Also one could argue that
    > C and Python are very similar. However Python and Tcl are like night
    > and day.


    Tcl is not a domain-specific language for creating GUI's. Tcl is a
    full-featured, general-purpose programming language that is a peer to
    Python in its capabilities, and surpasses Python in some respects.

    >
    > This monkey on our back (TclTk) is dead weight. We need to free
    > ourselves of this GUI prison and bring Python into the 21st century.
    > Tk is old and ugly. Tk is slow. Tk is incomplete and it will never be
    > complete or extensible within our community.


    In 2010, Tk only lacks two major features common to GUI toolkits:

    1. A cross-platform printing API. This is mainly an issue on Windows,
    which lacks a rich command-line printing framework. The canvas widget
    can generate PostScript, and the text widget can export its contents to
    a text file, and then "lpr" can handle the rest on Unix systems
    (including the Mac). Still, if you want native dialogs and full
    integration with a platform-specific printing API, you will have to
    utilize one of several, incompatible, platform-specific extensions.

    2. A robust widget for HTML display. The old TkHTML widget (authored by
    D. Richard Hipp, the author of SQLite) works, but it's very dated (last
    updated in 2002) and lacks modern features like CSS support. An effort
    to produce a next-generation HTML widget, TkHTML 3, yielded an
    alpha-quality widget that is enormously complex, somewhat buggy, and
    little used.

    These days, Tkinter has pretty much everything that other GUI toolkits
    have: tree views, multi-column listboxes, plus all the basics, available
    through the core widget, the themed ttk widgets, or extension packages.
    Today, there's no excuse for developing an ugly Tk GUI--if a new Tk app
    is ugly, that's a reflection on the developer, not the toolkit.

    >
    > There is no OpenGL canvas readily available. Sure you can use Togl (as
    > i have successfully!) however Togl is old and unmaintained. Any GUI
    > library in this day and age must support opengl out of the box!


    Togl is still developed. One of its maintainers, Greg Couch, is a
    developer on the UCSF Chimera project (a Python-Tkinter based molecule
    viewer).

    > Look, losing Tkinter will be very painful for me as i have tons of
    > code written already. However the more i learn about Tkinter the more
    > i realize how Tkinter is a dead end street. Why let a rotting dinosaur
    > stagnate in the stdlib? Anybody that has foresight knows Tkinter is
    > dying and cannot be revived. It is time to move on. Tkinter served us
    > well for a time but we must let go and evolve -- lest we wither and
    > die ourselves!
    >


    I have nothing against other toolkits, and if one happens to catch on,
    fine. But your assertions that Tkinter/Tk is dying have no basis in
    fact. I'm an active developer in Tk with both Tcl and Python, and the
    reason I have stayed with the toolkit is precisely because it isn't
    dying. Check out the screenshots at my website--all those GUI's are
    developed in Tk. Here's one in Tkinter/Python:

    http://www.codebykevin.com/phynchronicity-running.png

    --Kevin

    --
    Kevin Walzer
    Code by Kevin
    http://www.codebykevin.com
    Kevin Walzer, Dec 30, 2010
    #11
  12. rantingrick, 30.12.2010 00:58:
    > So what should we do?
    > ------------------------
    > The answer is simple. We need a 100% Python GUI. A GUI coded in Python
    > from top to bottom. A GUI that is cross platform to the big three
    > (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but
    > also a GUI that can be manipulated by the average python programmer. A
    > GUI that not only teaches the fundamentals of using a GUI, but also a
    > GUI that teaches how a GUI works under the hood


    I hope you invested as much time into writing this "expose" as you did
    searching the web before writing it.

    http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

    (the site is currently broken for me, you can use the following instead:

    http://webcache.googleusercontent.c....cosc.canterbury.ac.nz/greg.ewing/python_gui/

    Stefan
    Stefan Behnel, Dec 30, 2010
    #12
  13. rantingrick

    Kevin Walzer Guest

    On 12/30/10 10:52 AM, Stefan Behnel wrote:
    > rantingrick, 30.12.2010 00:58:
    >> So what should we do?
    >> ------------------------
    >> The answer is simple. We need a 100% Python GUI. A GUI coded in Python
    >> from top to bottom. A GUI that is cross platform to the big three
    >> (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but
    >> also a GUI that can be manipulated by the average python programmer. A
    >> GUI that not only teaches the fundamentals of using a GUI, but also a
    >> GUI that teaches how a GUI works under the hood

    >
    > I hope you invested as much time into writing this "expose" as you did
    > searching the web before writing it.
    >
    > http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/
    >
    > (the site is currently broken for me, you can use the following instead:
    >
    > http://webcache.googleusercontent.c....cosc.canterbury.ac.nz/greg.ewing/python_gui/


    This library isn't much different from other Python GUI toolkits--it's
    dependent on underlying, rather large, platform-specific
    implementations--but it provides an even higher level of abstraction. On
    the Mac, it is dependent on PyObjC; on Windows, pywin32; and on X11,
    pygtk. In short, it's a wrapper over other wrappers.
    --
    Kevin Walzer
    Code by Kevin
    http://www.codebykevin.com
    Kevin Walzer, Dec 30, 2010
    #13
  14. rantingrick

    rantingrick Guest

    On Dec 30, 9:52 am, Stefan Behnel <> wrote:

    > I hope you invested as much time into writing this "expose" as you did
    > searching the web before writing it.


    And ditto to you. If you would have followed the thread so far, in my
    second post i said...

    """However i need to stress that my intention is towards a 100% Python
    GUI. Not a binding, not a wrapping (except for OS calls!) but a *real*
    Python GUI. The only thing that i know of at this point is pyGUI
    although there are probably others."""[198:203]
    rantingrick, Dec 30, 2010
    #14
  15. rantingrick, 30.12.2010 17:02:
    > On Dec 30, 9:52 am, Stefan Behnel wrote:
    >
    >> I hope you invested as much time into writing this "expose" as you did
    >> searching the web before writing it.

    >
    > in my second post i said...
    >
    > """However i need to stress that my intention is towards a 100% Python
    > GUI. Not a binding, not a wrapping (except for OS calls!) but a *real*
    > Python GUI. The only thing that i know of at this point is pyGUI
    > although there are probably others."""


    Sure, fine, just making sure you know the terrain. If that's not enough for
    you, you should follow Steven's advice to get started implementing
    something, because this may become a lengthy undertaking.

    Stefan
    Stefan Behnel, Dec 30, 2010
    #15
  16. rantingrick

    Guest

    > These days, Tkinter has pretty much everything that other GUI toolkits
    have: tree views, multi-column listboxes, plus all the basics, available
    through the core widget, the themed ttk widgets, or extension packages.

    ***Today, there's no excuse for developing an ugly Tk GUI--if a new Tk
    app is ugly, that's a reflection on the developer, not the toolkit***

    +1 (emphasis added)

    Other tk/ttk benefits:
    - Very stable
    - Cross platform (w/native look and feel via Python 2.7/3.1 ttk)
    - Light weight
    - Easy to distribute
    - Extensible

    Regarding lack of print support: All GUI frameworks suck in this regard.
    The best approach is to use a technology designed for generating hard
    copy output - something like PDF, TeX, or RTF library.

    Malcolm
    , Dec 30, 2010
    #16
  17. rantingrick

    rantingrick Guest

    On Dec 30, 9:51 am, Kevin Walzer <> wrote:
    >
    > Tcl is not a domain-specific language for creating GUI's. Tcl is a
    > full-featured, general-purpose programming language that is a peer to
    > Python in its capabilities,


    Anybody can gloat and gush about their favorite programming language
    however what separates fantasy from reality is evidence of these
    "theories". Or rather, Illusions of grandeur!

    > and surpasses Python in some respects.


    The only thing that Tcl has over Python is building Tk GUI's. Please
    post evidence otherwise if you dare! In the meantime i will not be
    holding my breath.

    > In 2010, Tk only lacks two major features common to GUI toolkits:
    >
    > 1. A cross-platform printing API. This is mainly an issue on Windows,
    > which lacks a rich command-line printing framework.


    True windows has no "one-liner" "send-to-print-function" but what it
    does have is GDI and GDI+ which are far more powerful for windows
    programmers. Sure you may have to issue a few dc.MoveTo(x,y) and
    dc.LineTo(x,y) and dc.TextOut(blah) but what is so hard about that?
    Really, if you want a one liner just wrap up some Python code into a
    nice interface. This argument is either completely bogus or utterly
    idiotic.

    > 2. A robust widget for HTML display.


    The fact that Tkinter lacks an HTML widget is of no concern to me.
    Actually if i had a choice of including HTML support or not i would
    opt for not. Why? Because the simple fact is that Python needs a
    simplistic GUI and not bloat-ware in the stdlib. HTML widgets, handy
    dandy anolog clocks, happy faces and dancing bananas widgets belong in
    3rd party extension library's and not in the Python stdlib. However we
    must make sure that any GUI we support not only has these widgets
    available as extension libraries but that these libraries are
    currently maintained. If you are going to complain about lacking
    widgets then Togl would be a good starting point.


    > These days, Tkinter has pretty much everything that other GUI toolkits
    > have: tree views, multi-column listboxes, plus all the basics, available
    > through the core widget, the themed ttk widgets, or extension packages.
    > Today, there's no excuse for developing an ugly Tk GUI--if a new Tk app
    > is ugly, that's a reflection on the developer, not the toolkit.


    Yes Tk is not all bad for TclTk, however it IS all bad for Python. Let
    the Tcl folks use Tk and we will use a python GUI. Nuff said.

    > Togl is still developed. One of its maintainers, Greg Couch, is a
    > developer on the UCSF Chimera project (a Python-Tkinter based molecule
    > viewer).


    Have you seen the code in togl.py yourself? I mean really read it from
    beginning to end? It's a hodgepodge of poorly written code. I know
    this because i had to update the code myself for one of my projects.

    Look i have nothing against you Kevin. However i know you and Tkinter
    (and Tcl) are in bed together. So this is more of a *personal*
    decision for you instead of a *community* decision. Whether Tkinter
    exists in the stdlib or not should't matter to you because you can
    just download it from a 3rd party site.

    And *if* enough people really love Tkinter as you suggest then
    removing it will not kill it. However you know as well as i do that
    Tkinter is a drain on this community and the only thing keeping it
    alive is the fact that it is packaged in the stdlib. Once Tkinter is
    removed it will die as it should and something better will take it's
    place. Something more Pythonic. And most importantly something that is
    completely and totally under the direct control of the Python
    community.
    rantingrick, Dec 30, 2010
    #17
  18. rantingrick

    rantingrick Guest

    On Dec 30, 10:02 am, Kevin Walzer <> wrote:

    > >http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/


    > This library isn't much different from other Python GUI toolkits--it's
    > dependent on underlying, rather large, platform-specific
    > implementations--but it provides an even higher level of abstraction. On
    > the Mac, it is dependent on PyObjC;  on Windows, pywin32; and on X11,
    > pygtk. In short, it's a wrapper over other wrappers.



    hmm. And what is Tkinter exactly? And more importantly how is it
    better than pyGUI (design wise)? And even more importanly, how will it
    be better in the long run? Is this just more FUD Kevin "Gates"?
    rantingrick, Dec 30, 2010
    #18
  19. rantingrick

    Guest

    Tkinter accessability options (was Re: Tkinter: The good, the bad, andthe ugly!)

    Octavian,

    > Not all the people were happy because the darkness disappeared partially for some of them and more and more blind people started to use a computer, and discovered that the Tk interfaces are absolutely inaccessible for them.


    Might this package help? (I have no experience with this project)

    Tka11y 0.1.1 - accessibility-aware Tkinter
    http://pypi.python.org/pypi/Tka11y

    Another idea: Use Tkinters <Enter> events to speak TTS descriptions of
    the current control and/or its contents?

    I would love to hear from anyone using either of techniques ... or other
    techniques or screen reader products ... to make their Tkinter
    applications accessible to low vision/blind users.

    Malcolm
    , Dec 30, 2010
    #19
  20. Re: Tkinter accessability options (was Re: Tkinter: The good, the bad,and the ugly!)

    From: <>
    Subject: Tkinter accessability options (was Re: Tkinter: The good, the bad, and the ugly!)


    > Octavian,
    >
    >> Not all the people were happy because the darkness disappeared partially for some of them and more and more blind people started to use a computer, and discovered that the Tk interfaces are absolutely inaccessible for them.

    >
    > Might this package help? (I have no experience with this project)
    >
    > Tka11y 0.1.1 - accessibility-aware Tkinter
    > http://pypi.python.org/pypi/Tka11y
    >
    > Another idea: Use Tkinters <Enter> events to speak TTS descriptions of
    > the current control and/or its contents?
    >
    > I would love to hear from anyone using either of techniques ... or other
    > techniques or screen reader products ... to make their Tkinter
    > applications accessible to low vision/blind users.
    >
    > Malcolm



    Thank you very much for those projects! I will test them.

    Unfortunately they are not a solution because if I want to create an accessible app I can do it using an accessible library, but if the other programmers of the world use a non-accessible by default GUI, than their programs won't be accessible, or they will offer a limited accessibility like Java Access Bridge offers to SWING-based apps.

    If Tkinter would use that project that should offer the accessibility by default, that would be a real solution.

    Octavian
    Octavian Rasnita, Dec 30, 2010
    #20
    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. Dan Cernat
    Replies:
    18
    Views:
    462
    lilburne
    Nov 8, 2003
  2. Steven T. Hatton

    Sutter's Pimples: Good, Bad, or Ugly?

    Steven T. Hatton, Apr 11, 2004, in forum: C++
    Replies:
    24
    Views:
    1,069
    Steven T. Hatton
    Apr 12, 2004
  3. tonytech08
    Replies:
    32
    Views:
    1,134
    tonytech08
    Nov 13, 2008
  4. rantingrick
    Replies:
    44
    Views:
    1,142
    Peter Pearson
    Jul 13, 2010
  5. Patty
    Replies:
    2
    Views:
    578
    Martin Gregorie
    Jan 19, 2011
Loading...

Share This Page