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

[rantingrick]

All of the python programmers I know (we use python every day at
work) would say, "what is tkinter?" It's just not relevant to any of
them that I know.

And that is the very point i am trying to make Micheal! TclTk is SO
old and dated that most people don't even know it exists -- MUCH LESS
TKINTER!

In the meantime they happily crank out code with Django, or PyQt, or
PyGTK, or even Tkinter--whatever tool is appropriate for the job.

I noticed wxPython did not make your list. Was that conscience or sub-
conscience because i find it hard to believe that none of them use
wxPython... ever. However the REAL point is that they obviously prefer
*anything* except Tkinter and only use Tkinter as a last resort. This
is very interesting Micheal.

 

[geremy condra]

Actually the joke is on you Geremy. Obviously you cannot tell the
difference between "stereotypes" and "racism". And there is a HUGE,
HUGE, difference! Asians are stereotypical bad drivers, just as white
guys are stereotypical bad dancers, just as black guys have
stereotypical huge cucumbers.

Congratulations; you are the second person better than a decade to
land in my bozo bin. Don't bother replying- I won't be hearing from
you.

Geremy Condra

 

[Octavian Rasnita]

I think you're playing a bit fast and loose with your accusations.

I've made no accusations, but I only try to inform the people about the
accessibility of different GUI libs.

Which of my statements was "not true"?

1) On all of my computers wxPython uses Gtk.

2) There are other backend choices on Linux besides Gtk.

3) Gtk is by far the most common wxWidgets backend on Linux/Unix.

4) If Gtk is bad then wxPython is bad.

Note that 4) follows logically from 3), so to say that 4) is "not
true" you have to show that 3) is "not true".

The wrong conclusion is that if Gtk is bad, then WxPython is bad.
Gtk is inaccessible under Windows, not under Linux, but WxPython doesn't use
Gtk under Windows so WxPython is OK.

Under Linux Gtk is OK, but I don't know about Motif. Under Linux Motif might
not be accessible, however note that I am not sure about Motif's
accessibility.

Octavian

 

[Octavian Rasnita]

From: "Adam Skutt" <[email protected]>
The fact that /every/ toolkit provides accessibility guidelines over
and above whatever other UI guidelines they provide tells me that
creating an accessible application is hardly obvious. Plus, if it
were really that simple, the accessibility situation wouldn't be so
poor.


Where do you got the conclusion that the accessibility is so poor?
The accessibility is not so great under Mac and under Linux it is less
advanced than under Windows, but under Windows the accessibility is usually
very good for most apps.
All the standard Windows programs are accessible, all the DotNet programs
are generally accessible, SWT and wxWIDGETS - based programs are accessible,
SWING-based GUIS are also pretty accessible and even more strange interfaces
like the one found in Winamp are accessible.
Even Flash have a very limited accessibility although I think it is too much
to say that it is accessible.

But You keep telling me that it is hard to create accessible programs, which
is false, but you don't know and don't want to try to see.
Try to create a WxPython app that doesn't do anything but only displays some
menus, buttons, combo boxes, list boxes, list views, tree views, text
fields, check boxes, radio buttons... and you will see that they are very
accessible with that screen reader I told you about, without requiring you
to do anything special that you wouldn't do otherwise.

Yes, those things should be followed for creating a better app, but what I
wanted to say is that no matter if you do those things or not in a Tk, Gtk
or QT GUI, they will be useless, because the screen readers can't
understand those GUIS even they have text labels, and even if you will see
a focus rectangle around buttons. They don't report that those objects
have the focus so the screen readers won't speak anything.

Your "something is better than nothing" argument isn't particularly
compelling to me personally as a justification for ripping out
TkInter. And Qt is the only toolkit with some level of functioning
accessibility support on all three major platforms, assuming the
library and software are built correctly, so again, your argument is
really for Qt, not for wxWidgets.


How do you came to the conclusion that QT is accessible on all operating
system? I haven't seen any QT-based accessible interface, but WxPython
offers that thing without any effort.

When you talk about accessibility, try it yourself and don't take the word
of the GUI widgets developers.

Octavian

 

[Adam Skutt]

Where do you got the conclusion that the accessibility is so poor?

By an examination of the facts. MSAA is universally hated and all
screen readers actively have to work around it and its many
limitations (meaning that as an application programmer, you can do the
"right" thing and still get undesired behavior through no fault of
your own). I have no clue if it's replacement is better, but I do
know few programs use it, so it's little comfort.

The situation on Linux is still an outright disaster. Neither Qt4 nor
GTK enable accessibility functionality automatically and support from
the various distribution vendors is pretty limited. It is improving,
however.

Accessibility still requires special effort "over and above" the norm
by the programmer whether you believe this to be the case or not.
Most programmers aren't even aware of the fact they must consider it
(a point you've made yourself before!) and hence commit various
accessibility sins. This is mostly a cultural problem, not a
technical one, but it's still a real problem.

Plus, out of the stuff I run daily on Windows: two of the applications
are entirely inaccessible: the Adobe AIR one and the Gtk one.
Songbird, the XUL based music player, has some accessibility, but none
of the navigation controls seem to be enabled, which would make it
very difficult to actually use, I imagine. It's also not particularly
keyboard friendly: you don't even get a visual focus indicator most of
the time, even though the focus is moving.

But You keep telling me that it is hard to create accessible programs, which
is false, but you don't know and don't want to try to see.
Try to create a WxPython app that doesn't do anything but only displays some
menus, buttons, combo boxes, list boxes, list views, tree views, text
fields, check boxes, radio buttons... and you will see that they are very
accessible with that screen reader I told you about, without requiring you
to do anything special that you wouldn't do otherwise.

Applications that only display these things aren't very interesting.
And no, they still require additional effort. Most developers can't
even be assed to get a sane tab focus order set, to say nothing of
keyboard shortcuts, accessibility descriptions / proper label
associations for buttons and other controls.

It gets even more complicated when you get away from controls only
meant to display text. How many web pages have you visited where
images are missing alt tags? Do you really thing those same people
are going to bother trying to do the right thing if asked to create a
desktop GUI application? No, they're not, and you're going to get
whatever happens automatically. Which isn't nothing (in some
toolkits), but it's also not what one really wants, either.

How do you came to the conclusion that QT is accessible on all operating
system?

By actually going out, reading, and even testing? Qt has had
functional accessibility support on OS X and Windows since Qt3, and
functional support on Linux, OS X, and Windows since Qt4. It even
extends to PySide, with a few limitations: you can't write custom
accessible widgets in PySide, though I'm pretty confident they'd
enable support if someone wrote a patch to enable the bindings.

When you talk about accessibility, try it yourself and don't take the word
of the GUI widgets developers.

I just did, NVDA was able to read my button text and its accessibility
description just fine, both in C++ and Python versions of my Qt
application. I didn't bother testing Linux or OS X, but I'm sure it
would work there too.

Adam

 

[Bill Felton]

I don't see the original bizarre rants for some reason (spam filter
likely), but I have to say this is the most ridiculous thing I've heard
in some time. Tkinter the downfall of python? Wow. All of the python
programmers I know (we use python every day at work) would say, "what
is tkinter?" It's just not relevant to any of them that I know. Google
probably uses as much Python as anyone, and their programmers would
probably agree. Perhaps that's an argument to remove tkinter entirely,
but not really a good one.

With some hesitation, I feel a need to jump in here.
I'm a complete newbie to Python.
I'm still learning the language. And you know what? I've ignored Tkinter. I quickly discovered the alternatives and am already working with wxPython.
I can't believe anyone is so hung up by their own arrogance that they honestly believe that the mere *presence* of a gui kit inside of the standard distribution would prevent a newbie from learning about the existence and possible benefits of alternatives. Sure, *they* can see alternatives and evaluate why Tkinter might not be a good choice under conditions x or y or z, but god forbid anyone new to the language should have to confront those issues or be asked to make such a decision. How could we trust those lowly newbies to think *properly* about the issue!
ESPECIALLY in a language widely touted for the vast array of external libraries available.
The attitude that the standard distribution needs this kind of obsessive, hysterically blinkered, focused on irrelevant minutiae is far more likely to be the downfall of the language than the presence of a sub-optimal gui kit that no one is required to use.
As one of 'the people' who is presumably the focus of rantingrick's concern, let me assure him Tkinter is a non-issue. MIchael is more in touch with my issues than rr, and appears to be suffering fewer disconnects from the reality of a programming language that ships with a large standard library and offers a plethora of extensions and alternatives, widely available and easy to find.

cheers,
Bill

 

[Giacomo Boffi]

Yep when I started looking much more at other toolkits, I started to
like Tkinter more and more. Maybe its simplicity,

maybe the good design of Tk,

 

[Octavian Rasnita]

From: "Adam Skutt" <[email protected]>

Where do you got the conclusion that the accessibility is so poor?

By an examination of the facts. MSAA is universally hated and all
screen readers actively have to work around it and its many
limitations (meaning that as an application programmer, you can do the
"right" thing and still get undesired behavior through no fault of
your own). I have no clue if it's replacement is better, but I do
know few programs use it, so it's little comfort.


The Windows applications are not accessible only if they use MSAA. The
screen readers know how to get the necessary information for making the
interfaces accessible in other ways, but of course, it is harder for the
screen reader manufacturers if the GUIs don't respect a standard.
And if MSAA is hated it doesn't mean that the accessibility is so poor as
you might think.


The situation on Linux is still an outright disaster. Neither Qt4 nor
GTK enable accessibility functionality automatically and support from
the various distribution vendors is pretty limited. It is improving,
however.


It might be true, I don't know, because I use Linux only in command line
mode.


Accessibility still requires special effort "over and above" the norm
by the programmer whether you believe this to be the case or not.


I don't understand how I need to "believe" this, while I made perfectly
accessible applications without doing special efforts for making them to be
accessible.
Of course, I don't consider something special to put a text label on a
button, or radio button or check box.


Most programmers aren't even aware of the fact they must consider it
(a point you've made yourself before!) and hence commit various
accessibility sins. This is mostly a cultural problem, not a
technical one, but it's still a real problem.


Yes, that's a problem but we divagate. The programmers need to take care
about those details, like putting text labels on buttons, or tooltips for
images, but these things are relevant only for accessible widgets. It
*doesn't matter* if they put those labels if they use GUIS like Tk because
they won't be accessible at all anyway.


Plus, out of the stuff I run daily on Windows: two of the applications
are entirely inaccessible: the Adobe AIR one and the Gtk one.
Songbird, the XUL based music player, has some accessibility, but none
of the navigation controls seem to be enabled, which would make it
very difficult to actually use, I imagine. It's also not particularly
keyboard friendly: you don't even get a visual focus indicator most of
the time, even though the focus is moving.


Yes of course, Adobe's products are at most very hard accessible or not
accessible at all and I already said that Gtk is not accessible under
Windows, just like Tk.

But You keep telling me that it is hard to create accessible programs,
which
is false, but you don't know and don't want to try to see.
Try to create a WxPython app that doesn't do anything but only displays
some
menus, buttons, combo boxes, list boxes, list views, tree views, text
fields, check boxes, radio buttons... and you will see that they are very
accessible with that screen reader I told you about, without requiring you
to do anything special that you wouldn't do otherwise.

Applications that only display these things aren't very interesting.
And no, they still require additional effort. Most developers can't
even be assed to get a sane tab focus order set,


Well, I haven't used WxPython until now, but only WxPerl, however the WxPerl
programmers don't need to set the tab focus because by default the tab focus
is set in the order of the controls on the form and I thought it should be
the same in WxPython.
So no special effort would be necessary.

Are you sure you are not confusing accessibility with usability?
Of course that an application which respects more usability rules is easier
to use, and this means that it should have the controls with a right tab
order, with clear text labels and so on, but we can talk about usability
only for an accessible GUI.

JAWS screen reader has its own programming language and it can be used for
improving the usability of a program. It can do very many things and it has
more than 1000 functions, but it can't do anything in the case of
inaccessible interfaces like Tk.

to say nothing of keyboard shortcuts, accessibility descriptions / proper
label

associations for buttons and other controls.
It gets even more complicated when you get away from controls only
meant to display text. How many web pages have you visited where
images are missing alt tags? Do you really thing those same people
are going to bother trying to do the right thing if asked to create a
desktop GUI application? No, they're not, and you're going to get
whatever happens automatically. Which isn't nothing (in some
toolkits), but it's also not what one really wants, either.


Yes, that's true, but as I said, some GUIS like WxPython offer the
accessibility, so those controls are visible, and it is less important if
they are in a right tab order or if some of the controls are not labeled,
because the screen reader can solve these things.
But the screen reader can't solve the absolute inaccessibility of GUIS like
Tk because it can't read anything from it.

How do you came to the conclusion that QT is accessible on all operating
system?

By actually going out, reading, and even testing? Qt has had
functional accessibility support on OS X and Windows since Qt3, and
functional support on Linux, OS X, and Windows since Qt4. It even
extends to PySide, with a few limitations: you can't write custom
accessible widgets in PySide, though I'm pretty confident they'd
enable support if someone wrote a patch to enable the bindings.


A GUI which offers accessible widgets only if they are coded specially for
beeing accessible are not accessible at all, because most programmers won't
care to make the applications accessible so the results will be bad anyway.

When you talk about accessibility, try it yourself and don't take the word
of the GUI widgets developers.

I just did, NVDA was able to read my button text and its accessibility
description just fine, both in C++ and Python versions of my Qt
application. I didn't bother testing Linux or OS X, but I'm sure it
would work there too.


Have you created that QT application with its default options? Without doing
anything special to make it accessible?
And most important, have you tested it with JAWS screen reader? (Or
WindowEyes at least) because these are the most used screen readers.
NVDA is pretty poor and it can't be used for very complex things (yet).


Octavian

 

[Adam Skutt]

The Windows applications are not accessible only if they use MSAA. The
screen readers know how to get the necessary information for making the
interfaces accessible in other ways, but of course, it is harder for the
screen reader manufacturers if the GUIs don't respect a standard.

Actually, JAWS uses MSAA dead last, as I understand it, because the
API is truly that awful. But MSAA is necessary whenever you're not
using a Win32 common control or most of the other stuff developed by
MS. That means essentially every non-MS toolkit that's been
discussed.

And if MSAA is hated it doesn't mean that the accessibility is so poor as
you might think.

No, but it does mean precisely what I said: application developers can
do the "right" thing and get the wrong result.

Yes, that's a problem but we divagate.

If you believe that is a problem then you cannot say, "Accessibility
does not require special effort" without contradicting yourself. If
it did not require effort over and above the norm, then the cultural
problem would not exist.

Yes of course, Adobe's products are at most very hard accessible or not
accessible at all and I already said that Gtk is not accessible under
Windows, just like Tk.

Which means you're excluding a large swath of applications in your
analysis.

Well, I haven't used WxPython until now, but only WxPerl, however the WxPerl
programmers don't need to set the tab focus because by default the tab focus
is set in the order of the controls on the form and I thought it should be
the same in WxPython.

It's set in the order you create the controls (with some exceptions),
which may or may not be the correct tab focus order. Moreover, the
same FAQ I linked tells you that you need to set special styles to
support proper tab order when tabbed widgets and certain other
controls are involved, to say nothing of fall backs for certain other
controls that aren't provided automatically.

Yes, that's true, but as I said, some GUIS like WxPython offer the
accessibility, so those controls are visible, and it is less important if
they are in a right tab order or if some of the controls are not labeled,
because the screen reader can solve these things.

You've said yourself that it often requires trial and error on the
part of the user, so which is it?

A GUI which offers accessible widgets only if they are coded specially for
beeing accessible are not accessible at all,

That's the case with every GUI API on the planet: if you write a
custom widget you must provide accessibility support for it. This is
nothing new.

Have you created that QT application with its default options? Without doing
anything special to make it accessible?

Yes, you don't have to do a thing, unless you're custom building Qt
yourself. On Linux, you have to set QT_ACCESSIBILITY = 1, but Linux
is the exception.

And most important, have you tested it with JAWS screen reader? (Or
WindowEyes at least) because these are the most used screen readers.
NVDA is pretty poor and it can't be used for very complex things (yet).

No, and I have zero interest in doing so. Point was merely to
demonstrate your statement was false.

Adam

 

[rantingrick]

With some hesitation, I feel a need to jump in here. I'm a complete
newbie to Python. I'm still learning the language. And you know
what? I've ignored Tkinter.

Well it is really not a good idea to show your ignorance of a subject
matter directly before offering your opinion on that same subject
matter. Most people don't listen to the uninformed. Just FYI. However
lucky for you i am a fair guy and will give anyone a chance, sometimes
even two. ;-)

I quickly discovered the alternatives and am already working with
wxPython.

But is wxPython the correct alternative for you? What is so bad about
Tkinter exactly?. Why did you choose to skip it? There must be a
compelling reason. Why did you go out of your way to download another
GUI library when one exists in the stdlib? These are all good
questions that demand answers. So far you've offered opinion and no
facts. You said you ignored Tkinter but you did not explain why. Now
would be a good time to inject some facts into your argument.

I can't believe anyone is so hung up by their own arrogance that
they honestly believe that the mere *presence* of a gui kit inside
of the standard distribution would prevent a newbie from learning
about the existence and possible benefits of alternatives.

No one has ever said such an outlandish thing as this. You have missed
the entire point of this thread, congratulations! Now, go back and
read over the entire thread again and again until you comprehend it
completely before making another post. I look forward to your coherent
and lively discussion based on facts and not simply opinions.

Sure, *they* can see alternatives and evaluate why Tkinter might not
be a good choice under conditions x or y or z, but god forbid anyone
new to the language should have to confront those issues or be asked
to make such a decision. How could we trust those lowly newbies to
think *properly* about the issue!

We can't. Are you actually suggestion that someone with NO experience
with ANY of the GUI library available somehow has a better insight
into choosing the best GUI library than someone who (i don't know)
ACTUALLY HAS USED ALL OF THEM! Who's sock puppet are you Bill? Really.
And if you are not a sock puppet i HOPE you are just trolling because
this is a bombastic display of ignorance!. You could not be more
*uninformed* my friend. Heck with your mindset, the "Cookie Monster"
should replace Guido as BDFL. He has NO experience with anything
besides chowing down cookies, perfect choice!

ESPECIALLY in a language widely touted for the vast array of
external libraries available.The attitude that the standard
distribution needs this kind of obsessive, hysterically blinkered,
focused on irrelevant minutiae is far more likely to be the downfall
of the language than the presence of a sub-optimal gui kit that no
one is required to use.

Yes, and you just hit the nail on the the head! Why leave the stdlib
full of cruft (Tkinter)?

As one of 'the people' who is presumably the focus of rantingrick's
concern, let me assure him Tkinter is a non-issue. MIchael is more
in touch with my issues than rr.

FYI you are NOT one of the people that is the focus of my concern
because YOU only see the world from a limited viewpoint. And i never
proposed to solve every Python programmers problems. You completely
misunderstand my intentions (along with everyone else!). I do not
believe in "Utopian dreams". Some people will never be happy with the
state of Python and that is OK. However, the goal is to keep the
majority happy AND keep Python "presentable" and "competitive" for the
next decade. I am sorry you don't fit into any of these categories but
that is your own fault. Why? Because you are not concerned with the
community as a whole. You are only concerned with YOURSELF. You are
displaying both selfishness and ignorance at the same time. We don't
care what selfish people think and we care even less what the ignorant
think. If you decide to become a "team player" then you will be a part
of this community. Lucky for you ignorance and selfishness are
reversible personality traits.

 

[rantingrick]

Bill, [...snip...]

+1 (very well said)

Yes maybe Bill should be BDFL or a core developer. He has all the
answers. But no FACTS!

 

[Grant Edwards]

I don't see the original bizarre rants for some reason (spam filter
likely), but I have to say this is the most ridiculous thing I've heard
in some time. Tkinter the downfall of python? Wow. All of the python
programmers I know (we use python every day at work) would say, "what
is tkinter?" It's just not relevant to any of them that I know. Google
probably uses as much Python as anyone, and their programmers would
probably agree. Perhaps that's an argument to remove tkinter entirely,
but not really a good one.

In the meantime they happily crank out code with Django, or PyQt, or
PyGTK, or even Tkinter--whatever tool is appropriate for the job.

Tkinter has it's flaws. For example, the fact that it inclues a Tcl
interpreter inside the black box annoys me because I think Tcl is an
awful, awful language. That's somewhat irrational, so perhaps that's
my flaw and not Tkinter's.

However, Tkinter is easy to use (especially for simple tasks) and it
_works_. I wrote a moderatly complex (to me) UI in Tkinter 10+ years
ago. It still works fine. I couldn't say that about some wxPython
programs a quarter that old.

Perhaps a reference to Xah Lee's web site would suffice.

 

[Grant Edwards]

I've made no accusations,

Yes you have. You claimed what I stated was not true.

but I only try to inform the people about the
accessibility of different GUI libs.


The wrong conclusion is that if Gtk is bad, then WxPython is bad. Gtk
is inaccessible under Windows, not under Linux, but WxPython doesn't
use Gtk under Windows so WxPython is OK.

Ah. I didn't realize we were operating under the premise that Windows
was the only OS that mattered. Sorry.

 

[Octavian Rasnita]

From: "Adam Skutt" <[email protected]>
Actually, JAWS uses MSAA dead last, as I understand it, because the
API is truly that awful. But MSAA is necessary whenever you're not
using a Win32 common control or most of the other stuff developed by
MS. That means essentially every non-MS toolkit that's been
discussed.


Yes, but WxPython uses wxWIDGETS and wxWIDGETS use the standard Win32 controls under Windows, so they are accessible.
And they use Gtk under Linux and Gtk is accessible under Linux also.

That's why I said that WxPython should be prefered.

And if MSAA is hated it doesn't mean that the accessibility is so poor as
you might think.

No, but it does mean precisely what I said: application developers can
do the "right" thing and get the wrong result.


Yes of course they can do that if they use the wrong tool. They can't do the right thing if they believe that Tk or Silverlight or Flash is accessible no matter if they follow the recommendations for accessibility, because the screen readers don't support those interfaces.

Yes, that's a problem but we divagate.

If you believe that is a problem then you cannot say, "Accessibility
does not require special effort" without contradicting yourself. If
it did not require effort over and above the norm, then the cultural
problem would not exist.


Nope, the cultural problem exists because the programmers use the wrong interface, not because they just don't make the efforts for making that interface more accessible.
To be more clear and not to include in the discussion many interfaces, we are comparing Tkinter and WxPython. Most users that require accessibility are using Windows and under Windows WxPython use the underlying Win32 GUI which is accessible, while Tk is not accessible at all, no matter what the programmers do in order to make the interface accessible.

Yes of course, Adobe's products are at most very hard accessible or not
accessible at all and I already said that Gtk is not accessible under
Windows, just like Tk.

Which means you're excluding a large swath of applications in your
analysis.


I am not excluding anything. I said that all the Tk-based programs are inaccessible no matter what the programmer does to make it accessible, because the screen readers can't work with that interface.
And I have also said which are the accessible interfaces: wxWIDGETS (which use Win32 GUI under Windows and Gtk under Linux), SWT (which I think it does exactly the same thing as wxWIDGETS), WindowsForms (DotNet) and SWING (if the user installs Java Access Bridge).

Some of the interfaces created with other GUI libs might be accessible but it is not sure. What is sure is that the Tk-based interfaces are not accessible.

Well, I haven't used WxPython until now, but only WxPerl, however the WxPerl
programmers don't need to set the tab focus because by default the tab focus
is set in the order of the controls on the form and I thought it should be
the same in WxPython.

It's set in the order you create the controls (with some exceptions),
which may or may not be the correct tab focus order. Moreover, the
same FAQ I linked tells you that you need to set special styles to
support proper tab order when tabbed widgets and certain other
controls are involved, to say nothing of fall backs for certain other
controls that aren't provided automatically.

Yes, but with or without a proper tab order, WxPython creates accessible apps, while Tkinter doesn't.

Yes, that's true, but as I said, some GUIS like WxPython offer the
accessibility, so those controls are visible, and it is less important if
they are in a right tab order or if some of the controls are not labeled,
because the screen reader can solve these things.

You've said yourself that it often requires trial and error on the
part of the user, so which is it?


It depends if there is a JAWS script defined. JAWS provides by default scripts for dozens of popular applications for making them more usable. Each user can create his/her own script, because JAWS include that scripting language and a programming interface so the user can create their own script for an application for improving its usability, for labeling some not-named controls, for reading some parts of the screen when some events occur and many other things.
If the user doesn't want or don't know how to create that script for improving the usability, he/she might need to learn how to use the application by trial and error, but what I want to show is that the user is *able* to use that application, even if the interface is not very friendly, but it would be absolutely impossible to use an application created with Tkinter.

A GUI which offers accessible widgets only if they are coded specially for
beeing accessible are not accessible at all,

That's the case with every GUI API on the planet: if you write a
custom widget you must provide accessibility support for it. This is
nothing new.


I am not talking about custom controls. Those things are the worst thing possible from the perspective of accessibility, because usually nobody cares about providing accessibility features.
I am talking about standard controls. The standard controls provided by WxPython are accessible, no matter how usable and friendly they are, while the standard controls offered by Tkinter are absolutely inaccessible.

Have you created that QT application with its default options? Without doing
anything special to make it accessible?

Yes, you don't have to do a thing, unless you're custom building Qt
yourself. On Linux, you have to set QT_ACCESSIBILITY = 1, but Linux
is the exception.

And most important, have you tested it with JAWS screen reader? (Or
WindowEyes at least) because these are the most used screen readers.
NVDA is pretty poor and it can't be used for very complex things (yet).

No, and I have zero interest in doing so. Point was merely to
demonstrate your statement was false.


My point was that Tkinter which uses Tk is bad, and I didn't tried too many QT-based applications.
It would be nice if now QT would be accessible, but this won't mean too much if it would be accessible just for NVDA and not for the most used screen readers.

And I don't see what you demonstrate when you wanted to show Tkinter it is comparing with WxPython...

Octavian

 

[rantingrick]

Ah.  I didn't realize we were operating under the premise that Windows
was the only OS that mattered.  Sorry.

Windows IS the only OS that matters WHEN we are talking about "hand
holding". Anyone who uses Unix/Linux and cries about downloading
dependencies is just doing so for sake of discrediting the opposite
position. Only the lemmings would believe such nonsense. Unix/Linux
are NOT hand holding OS's. Thats what windows is for.

And the argument presented earlier (i think Octavian) about how the
majority of accessibility users are using windows is spot on! Anyone
who also denies this fact is just contributing more BS to the "devils
advocates" here. I am not suggesting that accessibility is not
important to a small sub set of Linux users. However the fact is that
the majority of "special needs" folks use windows. And thats a fact!

 

[rusi]

With some hesitation, I feel a need to jump in here.  

This thread is now at 239 posts (and so I too hesitate...)

The arguments for size, dependencies etc are what may be termed 'sys-
ad' perspectives.
The questions of 'it looks nice/ancient etc' are user issues.

What about some programmer perspective?

Using something like VB-in-.NET allows a programmer to put up
significant uis with close to zero coding. Many programmers would
look down on these as 'non-programmers'
[I should know: I inhabited a university CS dept for nearly 20 years
where Turing machines and lambda calculus are fashionable and getchar/
putchar programs are more hip than pleasant-looking GUIs. Many of our
problems stem from the fact that this academic hubris is justified as
objective]

So the (to me) relevant questions relating to GUIs are for example:
1. Is glade (and others such) equal to wxpython, tkinter and other
such 'backends'?
2. Can glade (or whichever is the best such tool today) compare to VB
in .NET or does it look like a bad joke in comparison (I guess the
current thing may not be VB but WPF but I dont want to pretend to know
too much about windows)

 

[MRAB]

On Jan 20, 6:30 am, Bill Felton<[email protected]>
wrote:
[snip]

As one of 'the people' who is presumably the focus of rantingrick's
concern, let me assure him Tkinter is a non-issue. MIchael is more
in touch with my issues than rr.

FYI you are NOT one of the people that is the focus of my concern
because YOU only see the world from a limited viewpoint. And i never
proposed to solve every Python programmers problems. You completely
misunderstand my intentions (along with everyone else!). I do not
believe in "Utopian dreams". Some people will never be happy with the
state of Python and that is OK. However, the goal is to keep the
majority happy AND keep Python "presentable" and "competitive" for the
next decade. I am sorry you don't fit into any of these categories but
that is your own fault. Why? Because you are not concerned with the
community as a whole. You are only concerned with YOURSELF. You are
displaying both selfishness and ignorance at the same time. We don't
care what selfish people think and we care even less what the ignorant
think. If you decide to become a "team player" then you will be a part
of this community. Lucky for you ignorance and selfishness are
reversible personality traits.

So you're going to lead the "peasants" (your word) whether they like it
or not, and any who don't want to follow are clearly being selfish and
ignorant?

Have you ever thought that if everyone is misunderstanding your
intentions, then perhaps you're doing something wrong?

(BTW, welcome to Pythonia, Bill! Most of us are friendly. )

 

[Bill Felton]

On Jan 20, 6:30 am, Bill Felton<[email protected]>
wrote:
[snip]

As one of 'the people' who is presumably the focus of rantingrick's
concern, let me assure him Tkinter is a non-issue. MIchael is more
in touch with my issues than rr.

FYI you are NOT one of the people that is the focus of my concern
because YOU only see the world from a limited viewpoint. And i never
proposed to solve every Python programmers problems. You completely
misunderstand my intentions (along with everyone else!). I do not
believe in "Utopian dreams". Some people will never be happy with the
state of Python and that is OK. However, the goal is to keep the
majority happy AND keep Python "presentable" and "competitive" for the
next decade. I am sorry you don't fit into any of these categories but
that is your own fault. Why? Because you are not concerned with the
community as a whole. You are only concerned with YOURSELF. You are
displaying both selfishness and ignorance at the same time. We don't
care what selfish people think and we care even less what the ignorant
think. If you decide to become a "team player" then you will be a part
of this community. Lucky for you ignorance and selfishness are
reversible personality traits.

So you're going to lead the "peasants" (your word) whether they like it
or not, and any who don't want to follow are clearly being selfish and
ignorant?

Have you ever thought that if everyone is misunderstanding your
intentions, then perhaps you're doing something wrong?

(BTW, welcome to Pythonia, Bill! Most of us are friendly. )\

Thanks!
And yes, I had noticed that in general this is a congenial, thoughtful, and helpful community. While a lot of what is discussed is not of particular interest to me, there's been a lot that has been of interest and/or of value. So far, I'm pretty impressed with the language as well as the community. And it's wonderful to be involved with a language that has such voluminous supporting materials of all sorts. [I self-taught Smalltalk back in the early and mid-80's when there were 3 books and that's about it...]
Hopefully I'll be able to contribute code, learning materials, or such like, at some point ;-)

cheers,
Bill

 

[rantingrick]

On Jan 20, 5:30 pm, Bill Felton <[email protected]>
This thread is now at 239 posts (and so I too hesitate...)

Why hesitate? Whether it be one post or a million posts, if you have
ideas, opinions, or suggestions then by all means jump in and share
them. If your words are FUD, not based on fact, or just completely
ignorant, don't worry, someone will correct you

The arguments for size, dependencies etc are what may be termed
'sys-ad' perspectives. The questions of 'it looks nice/ancient etc'
are user issues. What about some programmer perspective?

Size is very important. Dependencies are very important (within
context!). So too are aesthetics just as important when considering a
"graphics" module. In the end, Python should aim to bring the best
looking, most advanced (but well tested!), scalable modules we can
muster into the stdlib. At the time of it's inclusion Guido believed
Tkinter was the best choice -- and i agree with him! However we are
talking now about ~20 years of time between then and now. Is anyone so
bombastic as to suggest that GUI has not changed significantly in that
time. And likewise, is anyone so bombastic as to suggest that the
lowly Tkinter module (and even worse TclTk) is representative of 21st
century GUI programming? Heck, when Tkinter was added GUIs where just
in their infancy as far as popular adoption is concerned! TclTk have
lacked vision from the beginning. NEWSFLASH! They did not support
themes until version 8.5! (~2009) And they still have much work to do
if they ever want to compete with the likes of wxPython however i know
thay will never reach that level of sophistication. TclTk as a
community are not concerned about keeping up with he times, so be it!
However we should not degrade "our" stdlib and "our" community with
such backward thinking communities. We must move forward. We must pull
our heads out of the sand or mentality will be our undoing.

Using something like VB-in-.NET allows a programmer to put up
significant uis with close to zero coding. Many programmers would
look down on these as 'non-programmers'

Well i don't look down on these folks i just feel they are missing out
on the richness and abstract thinking that creating the GUI mentally
evokes. However. I believe it would be of great benefit to have a
graphical GUI builder as part of any GUI package we consider for the
stdlib. Do i think it should be IN the stdlib? Probably not due to
size. But the fact that it is available for those who would like it to
be is great. My biggest complaint with Tkinter is that it lacks so
much functionality (even outside the stdlib!) that you really end up
wasting your time learning and using it. Because eventually you will
be forced to throw away everything you've learned and written and
convert to something else.

So the (to me) relevant questions relating to GUIs are for example:
1. Is glade (and others such) equal to wxpython, tkinter and other
such 'backends'? 2. Can glade (or whichever is the best such tool
today) compare to VB in .NET or does it look like a bad joke in
comparison (I guess the current thing may not be VB but WPF but I
dont want to pretend to know too much about windows)

I think we need to add a graphical GUI builder to the list of
important attributes of a 21st century GUI library. Not the most
important, but still quite important. Especially if we want to
"market" Python as a GUI language. And I am not saying we should
market Python that way.

So the attributes we must demand of a 21st century GUI library are a
follows:

* Quality Documentation (our problem really)
* Cross Platform (their problem)
* Rich Full Featured Widget Set. (their problem)
* Simplistic API (our problem)
* Scalability (their problem)
* Accessibility (their problem)
* Graphical GUI Builder. (Either or)

Also some attributes related to the "Big Picture" of GUI and Python:

* Mobile and Web support

 

[Adam Skutt]

From: "Adam Skutt" <[email protected]>
Actually, JAWS uses MSAA dead last, as I understand it, because the
API is truly that awful.  But MSAA is necessary whenever you're not
using a Win32 common control or most of the other stuff developed by
MS.  That means essentially every non-MS toolkit that's been
discussed.

Yes, but WxPython uses wxWIDGETS and wxWIDGETS use the standard Win32 controls under Windows, so they are accessible.
And they use Gtk under Linux and Gtk is accessible under Linux also.

wxGTK is not, though. wxWidgets is only accessible under Windows. Qt
is accessible under Windwos, OS X, and anything that supports AT-
SPI[1]. Yet, for some unfathomable reason, you keep promoting
wxWidgets even though it is plainly the inferior solution.

Yes of course they can do that if they use the wrong tool. They can't do the right thing if they believe that Tk or Silverlight or Flash is accessible no matter if they follow the recommendations for accessibility, because the screen readers don't support those interfaces.

No, even using the right tools: http://doc.qt.nokia.com/qq/qq24-accessibility.html#dealingwithquirks
(a few years old, but AFAIK still relevant). It's a crap shoot even
if I use tools that support accessibility, because the APIs aren't
very good. Some of the new APIs improve the problem, but some reading
suggests there will still be the need for a lot of special case
handling on both sides of the table.

Nope, the cultural problem exists because the programmers use the wrong interface, not because they just don't make the efforts for making that interface more accessible.

No, they don't think about it, they don't test, they don't make the
necessary calls to enable accessible applications. Plenty of
applications with poor to non-existent accessibility support are
written with toolkits that support accessibility.

To be more clear and not to include in the discussion many interfaces, we are comparing Tkinter and WxPython.

No, we're not comparing just them, because they're hardly the only
solutions.

I am not excluding anything. I said that all the Tk-based programs are inaccessible no matter what the programmer does to make it accessible, because the screen readers can't work with that interface.
And I have also said which are the accessible interfaces: wxWIDGETS (which use Win32 GUI under Windows and Gtk under Linux), SWT (which I think it does exactly the same thing as wxWIDGETS), WindowsForms (DotNet) and SWING (if the user installs Java Access Bridge).

This is not a complete list, or even a correct list, which was my
point.

It depends if there is a JAWS script defined.

Stop. You've insisted many times that I need to not do anything
special for making accessible applications. Yet, JAWS has an API
entirely for the purpose of enhancing accessibility for specific
applications! So, which is it? If I don't need to do anything
special, then why does the API exist? Oh right, it exists so people
can compensate for developers shortcomings.

It's very hard to take anything you say seriously when you repeatedly
get basic facts wrong and when you make claims that aren't consistent
with the facts.

If the user doesn't want or don't know how to create that script for improving the usability, he/she might need to learn how to use the application by trial and error, but what I want to show is that the user is *able* to use that application, even if the interface is not very friendly, but it would be absolutely impossible to use an application created with Tkinter.

He / she might be able to use the application. It's a "maybe", not a
"for sure", yet you consistently imply it's the latter.

I am not talking about custom controls. Those things are the worst thing possible from the perspective of accessibility, because usually nobody cares about providing accessibility features.

Yet I was talking about custom controls, and plenty of applications
use custom controls, so you cannot ignore them even if you'd wish to
do so.

My point was that Tkinter which uses Tk is bad, and I didn't tried too many QT-based applications.

No, you explicitly stated that Qt has zero accessibility support,
which is simply false. You didn't say, "The ones I tried haven't
worked", which is certainly possible depending on version and how Qt
was compiled (since Qt is normally shipped with the application on
Windows). You said, "But the interfaces created with Tk, Gtk and QT
are completely inaccessible."

And I don't see what you demonstrate when you wanted to show Tkinter it is comparing with WxPython...

I never said I was going to demonstrate anything between Tkinter and
wxPython. Such a demonstrate is in your imagination.

Adam