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

[rantingrick]

That is a pretty large dependency to rely on, and it is rather
undesirable IMO.

And what exactly is undesirable? Unless you actually back up your
statements with fact they just ring hallow. Can you offer any specific
reasons why wx is a bad choice. And more importantly can you offer any
viable alternatives?

 

[Corey Richardson]

And what exactly is undesirable? Unless you actually back up your
statements with fact they just ring hallow. Can you offer any specific
reasons why wx is a bad choice. And more importantly can you offer any
viable alternatives?

Go ahead and read Adam's fine post about the dependencies of wxwidgets.
As for alternatives? I think Tkinter is fine for most of my purposes.
When I need something else, I use PyQt. I can install python-minimal on
Windows/Linux/What-have-you and know that Tkinter will run without
needing GTK+ and SWIG, as Adam mentioned. If you want to get something
done, here's an idea - do it yourself. That's what OS is all about.
Don't just write something, implement it. If the folks over in
python-dev want nothing to do with it, that's fine - make a package
using your minimal wxpython version, I'm sure people will use it,
especially if you make it as easy to use as Tkinter.

I'm done with this thread. I inserted my 12 cents. Have a nice day, and
good luck with your ventures.

~Corey

 

[rantingrick]

I'm done with this thread. I inserted my 12 cents. Have a nice day, and
good luck with your ventures.

Bye

 

[rantingrick]

 At which point, it's pretty damn
small.  Not as small as all of the Tk functionality, I think, but well
under 10MiB compressed.

Yea but look at all your gaining. I would rather sacrifice a few megs
for the rich functionality and scalability any day.

The problem to me isn't the size (though some might find it
objectionable), but the system dependencies you have to take:
wxWidgets requires GTK+ on UNIX

UNIX? are you kidding? Even if these dependancies are needed the
"UNIX" folks are damn capable of finding and installing them with
great ease. Besides most ship with this out the box already! We are
not talking about the lemmings who use windows or even the weekend
linuxers here. If they are using UNIX then there is no need for "hand
holding".

, which requires a whole mess of crap
in term, plus swig, plus whatever else I may or may not be missing.

Thats quite an exaggeration Adam.

I'm also not 100% certain as to whether it's as portable as Tk is
today.

Wx is just as portable as Tk

 

[Octavian Rasnita]

Please read your previous post. Anyway *which* GUI offers access to
everyone?

You are right. There are probably no GUIs that offer access to everyone, no
matter the language they speak, their health problems or the platforms they
use, but what I want to say is that those GUIS that offer access to as many
people as possible are those that should be promoted, not those who
discriminate people without even wanting to do this.

Octavian

 

[Octavian Rasnita]

Go ahead and read Adam's fine post about the dependencies of wxwidgets.
As for alternatives? I think Tkinter is fine for most of my purposes.
When I need something else, I use PyQt. I can install python-minimal on
Windows/Linux/What-have-you and know that Tkinter will run without
needing GTK+ and SWIG, as Adam mentioned. If you want to get something
done, here's an idea - do it yourself. That's what OS is all about.
Don't just write something, implement it. If the folks over in
python-dev want nothing to do with it, that's fine - make a package
using your minimal wxpython version, I'm sure people will use it,
especially if you make it as easy to use as Tkinter.

I don't think this is what we are talking about on this thread.
If any Python programmer wants to use WxPython because it is better than
Tkinter, then he/she can use it without any problem.

I think we are talking about the GUI lib included in Python, the GUI which
is promoted by Python.
This GUI should be one which is better from the users' perspective, which is
accessible for as many users as possible because the GUI that's promoted by
Python is very important for the beginners.

If you or someone else wants to create a stripped-down application which
doesn't offer so many features then it wouldn't be any problem to get
Tkinter and use it, but the beginners shouldn't learn first to use a GUI lib
like Tkinter.

Octavian

 

[Octavian Rasnita]

Python uses tkinter as the only choice available for the stdlib.
Others choices not in the stdlib are available for those who want
something better.

The users shouldn't want something better. Everyone should create GUIs which
are accessible for everyone by default, without making any special effort
for doing this.
The programmers should make special efforts for making GUIS which are not
accessible for as many users as possible if they want this but this way
shouldn't be promoted by Python.

I did not know that.

Most of the programmers don't know that and they don't even need to know
that, but if a lib that create accessible GUIS would be promoted, most of
the Python programmers would use that lib and would create good apps by
default, without even knowing this.
On the other hand, if they started to learn to create a bad GUI, of course
that after that they will think that a supplemental effort is necessary for
creating good GUIS with another lib and they won't like it.

Octavian

 

[Octavian Rasnita]

I am generally for better accessibility, but I consider the notion that if
everyone cannot have something, then no one should, to be rather
pernicious.

Of course. I have the same opinion. But if using WxPython everyone can have
access and that's why I think it should be promoted.
wxWIDGETS lib is not perfect but it is much better for more categories of
users...

Octavian

 

[Adam Skutt]

I am talking about the fact that Python promotes Tkinter, and many beginners will start using it, and they will start creating applications with it, and they will learn to use it better than WxPython, and they will start believing that Tkinter is better because it is easier to use than WxPython, so they will start convincing others that Tkinter is the best, and they will start finding many reasons that show that Tkinter is better. And after this, they will say that they don't care about the real problems generated by GUIs like Tk.
And a very big problem is that the applications that use Tk/GTK are not accessible for screen readers, so those applications will be just blank for people with visual impairments which need to use a screen reader.

If you want functional accessibility support, you're going to have to
write it in Python yourself, and get the accessibility manufacturers
to support it. All of the cross-platform toolkits have poor to non-
existent accessibility support. Accessibility issues aren't going to
be fixed by going to a different GUI toolkit in the standard library.
The alternative is to fix the accessibility support issues in the
underlying library, and Tk is no less amenable to that than
wxWidgets. If that's what you want, start coding then. You have a
long climb ahead of you.

Accessibility will never be a particular good argument for switching
toolkits. All of the cross-platform offerings with Python bindings
are far too broken to be even remotely interesting.

Why do we like the portable GUIS and don't really like the native interfaces that don't work on other platforms?
Because we want our programs to be usable by as many people as possible. Well, some platforms render the output as sound and Tkinter are not "portable" on those platforms (screen readers).

Or we have cross-platform support as a requirement and no desire to
develop the GUI interface three times over. Hence the continued
popularity of Java GUIs.

Adam

 

[Adam Skutt]

The users shouldn't want something better. Everyone should create GUIs which
are accessible for everyone by default, without making any special effort
for doing this.

Accessibility always requires special effort, and I don't see how
changing toolkits gets away from this.

Adam

 

[Adam Skutt]

Most of the programmers don't know that and they don't even need to know
that, but if a lib that create accessible GUIS would be promoted, most of
the Python programmers would use that lib and would create good apps by
default, without even knowing this.

Have you written an accessible application in any toolkit whatsoever?
It is not magic, and it does not happen by default, even when solely
using the standard widgets.

Adam

 

[Mark Roseman]

Octavian,

Thank you for clearly articulating your concern that Tk does not provide
any support for screen readers.

While I believe that people can have legitimate differences of opinion
as to whether this merits its removal/replacement from stdlib, there is
no question that this is a serious and significant limitation of Tk.

I will attempt to find out if there has been any work done in this area
with Tk, and what it would take to address this important issue.

Thanks again
Mark

 

[python]

Mark/Octavian,

It sounds like Tka11y (spelled with the digit '1' vs. the letter 'L')
addresses this problem for Linux users.

According to its website, adding accessability support is as simple as
changing one import statement.

Details follow my signature.

Malcolm


Tka11y - Tk Accessibility
http://tkinter.unpythonic.net/wiki/Tka11y

<quote>
Note: Currently, accessibility is only available via ATK <=> AT-SPI on
Linux. Sorry, no Windows MSAA support.

Download
http://pypi.python.org/pypi/Tka11y

A modification to Tkinter to make widgets visible to the AT-SPI layer so
that tools like dogtail and Accerciser can see them. Tka11y uses Papi,
the Python Accessibility Programming Interface, which in turn uses ATK,
the GNOME Accessibility Toolkit, to expose Tkinter widgets to AT-SPI,
the Assistive Technologies Service Provider Interface. This allows a
Tkinter application's widgets to be viewed and/or controlled by a
variety of assistive technologies such as Orca and Accerciser, and
automated GUI testing tools such as dogtail and LDTP. These client tools
usually use either cspi (C) or pyatspi (Python).

Typical usage:

import Tka11y as Tkinter

or

from Tka11y import *
</quote>

 

[Octavian Rasnita]

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

I am talking about the fact that Python promotes Tkinter, and many beginners will start using it, and they will start creating applications with it, and they will learn to use it better than WxPython, and they will start believing that Tkinter is better because it is easier to use than WxPython, so they will start convincing others that Tkinter is the best, and they will start finding many reasons that show that Tkinter is better. And after this, they will say that they don't care about the real problems generated by GUIs like Tk.
And a very big problem is that the applications that use Tk/GTK are not accessible for screen readers, so those applications will be just blank for people with visual impairments which need to use a screen reader.

If you want functional accessibility support, you're going to have to
write it in Python yourself, and get the accessibility manufacturers
to support it. All of the cross-platform toolkits have poor to non-
existent accessibility support. Accessibility issues aren't going to
be fixed by going to a different GUI toolkit in the standard library.

Not true. WxPython uses wxWIDGETS which uses the default OS widgets which usually offer the accessibility features.
(At least under Windows, but most users that need accessibility use Windows anyway).

The alternative is to fix the accessibility support issues in the
underlying library, and Tk is no less amenable to that than
wxWidgets. If that's what you want, start coding then. You have a
long climb ahead of you.

The underlying libraries for Windows offer the necessary accessibility and WxPython uses it, but Tkinter uses Tk not those libraries.

Accessibility will never be a particular good argument for switching
toolkits. All of the cross-platform offerings with Python bindings
are far too broken to be even remotely interesting.

WxPython is not perfect but most of the objects it offers are accessible so this is not true. Only Tk and GTK are bad.

Why do we like the portable GUIS and don't really like the native interfaces that don't work on other platforms?
Because we want our programs to be usable by as many people as possible. Well, some platforms render the output as sound and Tkinter are not "portable" on those platforms (screen readers).

Or we have cross-platform support as a requirement and no desire to
develop the GUI interface three times over. Hence the continued
popularity of Java GUIs.

Java GUIS are accessible. Maybe that's the reason.
SWT offers the same kind of accessibility as WxPython and for SWING there is Java Access Bridge. So they are not as accessible as the native Windows GUI objects, but they are accessible, unlike Tk and GTK which are not.

Octavian

 

[Octavian Rasnita]

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

The users shouldn't want something better. Everyone should create GUIs which
are accessible for everyone by default, without making any special effort
for doing this.

Accessibility always requires special effort, and I don't see how
changing toolkits gets away from this.

Adam

This is the most false thing I ever heard and the most dangerous.
The GUIS like wxWIDGETS and SWT (at least under Windows), Win32 GUI, MFC, WindowsForms (.Net), are accessible out of the box and they don't require any effort from the programmer. The programmer doesn't even know that the application will also offer accessibility features.
Java SWING is not accessible out of the box, but Sun offers Java Access Bridge, a program which can be installed by the user which needs accessibility, so finally SWING GUIS are also pretty accessible (also without any effort from the programmer).

(Which is not the case of Tk, Gtk and QT.)

Octavian

 

[Octavian Rasnita]

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

Most of the programmers don't know that and they don't even need to know
that, but if a lib that create accessible GUIS would be promoted, most of
the Python programmers would use that lib and would create good apps by
default, without even knowing this.

Have you written an accessible application in any toolkit whatsoever?
It is not magic, and it does not happen by default, even when solely
using the standard widgets.

Adam

Of course I did. Using WxPerl, Win32::GUI Perl module, SWT and DotNet.
(And without doing absolutely anything special for making them accessible).

But it is very simple to test this. You can download a demo version of JAWS screen reader from
www.freedomscientific.com
that will run for 40 minutes or so and then you will need to reboot the computer to make it work again.

It is the most used and most powerful screen reader. You will be able to see how accessible (or not accessible) are the applications made with any GUI lib.

Octavian

 

[Octavian Rasnita]

Octavian,

Thank you for clearly articulating your concern that Tk does not provide
any support for screen readers.

While I believe that people can have legitimate differences of opinion
as to whether this merits its removal/replacement from stdlib, there is
no question that this is a serious and significant limitation of Tk.

I will attempt to find out if there has been any work done in this area
with Tk, and what it would take to address this important issue.

Thanks again
Mark

Thank you Mark. I don't have anything against Tk, Gtk or QT or other GUI libs, but I just shown why some interfaces are much better than others, for very important reasons, which unfortunately can't be seen, so many programmers don't know about them and promote the discrimination without wanting to do that.

Octavian

 

[Octavian Rasnita]

Mark/Octavian,

It sounds like Tka11y (spelled with the digit '1' vs. the letter 'L')
addresses this problem for Linux users.

According to its website, adding accessability support is as simple as
changing one import statement.

Details follow my signature.

Malcolm


Tka11y - Tk Accessibility
http://tkinter.unpythonic.net/wiki/Tka11y

<quote>
Note: Currently, accessibility is only available via ATK <=> AT-SPI on
Linux. Sorry, no Windows MSAA support.

This project is good, a step ahead, but in order to be really useful it should be the one provided by the default Python package.
And of course, it should also offer support for Windows, since most of the computer users use Windows, especially those who need accessibility features.

Octavian

 

[Adam Skutt]

Not true. WxPython uses wxWIDGETS which uses the default OS widgets which usually offer the accessibility features.
(At least under Windows, but most users that need accessibility use Windows anyway).

Right, under Windows, which is a problem. By your line of reasoning,
you really should be supporting PySide / PyQt and not wxWidgets, since
they at least play at cross-platform support.

The underlying libraries for Windows offer the necessary accessibility and WxPython uses it, but Tkinter uses Tk not those libraries.

wxWidgets' support is completely inadequate for a true cross-platform
system, the developers are aware of this and acknowledge this and
believe a rewrite is necessary. Thus, it is currently really in no
better state than Tk.

Java GUIS are accessible. Maybe that's the reason.

No, the reason is as I stated, no more, no less. Accessibility
doesn't enter into most designs.

Adam

 

[Adam Skutt]

This is the most false thing I ever heard and the most dangerous.

O RLY? http://www.wxwidgets.org/docs/technote/wxaccesstips.htm sure
looks like there's a whole host of things that I, the application
programmer, must do manually to enable an accessible application[1].
I can't just plop down controls and have an accessible application.

The programmer doesn't even know that the application will also offer accessibility features.

No, accessibility requires consideration in the design and
implementation of the GUIs, in all of those toolkits. It is not
transparent, nor can it be transparent. It requires both
consideration when laying out the widgets, but also ensuring that the
widgets have specific properties set. How many applications have you
ever used that had focus order bugs? That's an accessibility issue
that requires programmer intervention to get right.

Adam

[1] That list is not comprehensive by a long shot.