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

R

rantingrick

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?

If you could read Bill's words and not find them to be overly selfish
and ignorant then i don't know what to say. He clearly stated many
times that he NEVER used Tkinter. However somehow we are to believe
that he has some "magical" insight on the merits (or lack there of) of
Tkinter? This IS THE VERY DEFINITION OF IGNORANCE MRAB. Ignorance is
defined as the lack of knowledge. Bill has presented just that.

However, even in light of such bombastic ignorance and selfish display
I in good humility and grace offered Bill advice on how he could
present more facts instead of just baseless opinion. I asked him very
specific questions THAT IF he would answer MIGHT inject some facts
into his baseless argument. However I bet we won't get any answers
from him.

PS: You never cease to amaze me MRAB.
 
M

MRAB

If you could read Bill's words and not find them to be overly selfish
and ignorant then i don't know what to say. He clearly stated many
times that he NEVER used Tkinter. However somehow we are to believe
that he has some "magical" insight on the merits (or lack there of) of
Tkinter? This IS THE VERY DEFINITION OF IGNORANCE MRAB. Ignorance is
defined as the lack of knowledge. Bill has presented just that.

However, even in light of such bombastic ignorance and selfish display
I in good humility and grace offered Bill advice on how he could
present more facts instead of just baseless opinion. I asked him very
specific questions THAT IF he would answer MIGHT inject some facts
into his baseless argument. However I bet we won't get any answers
from him.

PS: You never cease to amaze me MRAB.

The feeling is mutual.
 
E

Emile van Sebille

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.[/QUOTE]



The problem with QT is the license.

From http://qt.nokia.com/products/licensing/:

Qt Commercial Developer License
The Qt Commercial Developer License is the correct license to use for
the development of proprietary and/or commercial software with Qt where
you do not want to share any source code.

You must purchase a Qt Commercial Developer License from us or from one
of our authorized resellers before you start developing commercial
software as you are not permitted to begin your development with an open
source licensed Qt version and convert to the commercially license
version at a later . The Qt Commercial Developer License includes a
restriction that prevents the combining of code developed with the Qt
GNU LGPL v. 2.1 or GNU GPL v. 3.0 license versions with commercially
licensed Qt code.
 
O

Octavian Rasnita

From: "Grant Edwards said:
Ah. I didn't realize we were operating under the premise that Windows
was the only OS that mattered. Sorry.

This conclusion is hatefully because you have already read that Gtk is accessible under Linux, so WxPython doesn't offer accessibility only for Windows.
From the perspective of most of those who need accessibility however, yes, Windows is most important.

Octavian
 
O

Octavian Rasnita

From: "Adam Skutt said:
Yet, for some unfathomable reason, you keep promoting
wxWidgets even though it is plainly the inferior solution.


Inferior to what?

I would be glad if you could tell me about a portable solution which is accessible with JAWS and Window Eyes, the most used screen readers under Windows (real glad).

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.


Exactly. When you will read that thing on a GUI creator site it means that that GUI is not accessible because the screen readers don't support it yet. The GUI libs manufacturers will say that the screen readers are bad because they don't offer support for their GUI, although that GUI offers accessibility features.
Well, I don't care that the screen readers are bad and don't support some libs. I care only if the interfaces created with a certain GUI lib is accessible out of the box as WxPython is under Windows.
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.

You confuse again the accessibility with the usability or you think that if a GUI lib offers accessibility features it is accessible. Well, a GUI lib is accessible only if JAWS and Window Eyes offer support for it because those are the screen readers used by the majority and this is because they have the most features.
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.

We were starting from the idea that Tkinter is worse than WxPython so let's come to that idea and not divagate.
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.

My point was that Tkinter shouldn't be promoted by Python because it doesn't create accessible GUI out of the box at least for Windows as WxPython does.
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.

I've told you a lot of times that you confuse accessibility with usability. And I told you that the JAWS scripts can't make an absolutely inaccessible application made with Tk to be accessible.
And that's why Tkinter is bad.
The JAWS scripts can only improve the usability, can make the application be much friendly, but if it is not accessible, it can't make it accessible, because if it could do it, there would be no accessibility issues anymore.


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.

Which are those 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.

Yes, but there is a chance to be able to use that application while if the application is done with Tk, she/he would have absolutely no chance to use it.

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.

If the application uses custom controls and the programmer adds custom accessibility features for them (which usually never happends), that application might be accessible if it uses an accessible GUI lib. But if the programmer adds accessibility features to a Tk GUI, that GUI won't be accessible because the screen readers don't offer the necessary support for Tk.

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."

If QT is not consistent and some versions can be accessible and other versions not, it means that QT should be avoided just because it is not consistent.
A sane GUI should offer accessibility by default in all its versions without needing to activate anything in order to make the application accessible.

Octavian
 
R

rantingrick

The problem with QT is the license.

 Fromhttp://qt.nokia.com/products/licensing/:

Qt Commercial Developer License
The Qt Commercial Developer License is the correct license to use for
the development of proprietary and/or commercial software with Qt where
you do not want to share any source code.

Well as far as i am concerned that takes QT out of the contest. So
that leaves WxPython and pyGTK as the only viable options that are
mature libraries. Both carry the LGPL license.

http://www.pygtk.org/
http://www.wxwidgets.org/about/newlicen.htm

One more is FLTK however it looks like a mirror of Tkinter so back in
the same place:

http://pyfltk.sourceforge.net/index.php#download
 
A

Adam Skutt

The problem with QT is the license.

Qt and wxWidgets are both LGPL and equally non-starters due to
license, today. There was a hypothetical assumption on my part that
the library would be made license compatible somehow, through the
entire discussion. I didn't think it worth mentioning because I
didn't think it all that relevant to any of the discussions that end
ed up occurring here.

Adam
 
A

Adam Skutt

From: "Adam Skutt" <[email protected]>> Yet, for some unfathomable reason, you keep promoting
I would be glad if you could tell me about a portable solution which is accessible with JAWS and Window Eyes, the most used screen readers under Windows (real glad).

I did, Qt. I'm not yournanny and I'm not going to go test it for
you. There are bugs in the Qt database relating to JAWS
functionality, so it others have plainly gotten it working to some
degree. But honestly, why should I waste my time replying to you when
you're too damn lazy to even use Google? I certainly won't be doing
so in the future. "Lead a ignorant, thirsty horse to water, watch it
die of thirst" and all that.
Exactly. When you will read that thing on a GUI creator site it means that that GUI is not accessible because the screen readers don't support it yet.
The GUI libs manufacturers will say that the screen readers are bad because they don't offer support for their GUI, although that GUI offers accessibility features.

No, that's not what that page says or means. But I'm not going to be
able to explain it to you any more clearly, so if you'd prefer to keep
living in your own delusional, illydic world, that's your decision.
Qt has been pretty clear in painting the blame on who it belongs on,
which is not the screen reader vendors.

Adam
 
R

rantingrick

Qt and wxWidgets are both LGPL and equally non-starters due to
license, today.

Everything out there is LGPL! But you cannot just use that argument to
keep Tkinter. So are you suggesting that we just hold on Tkinter
forver! Are you mad? Can you image Python still lugging around the
antiquated Tkinter module in 2020? That's a nightmare. You know damn
good and well that even nine years from now TclTk will be two decades
behind in development. AND SLOWER THAN EVER!
 
E

Emile van Sebille

On 1/20/2011 12:17 PM rantingrick said...
Well as far as i am concerned that takes QT out of the contest. So
that leaves WxPython and pyGTK as the only viable options that are
mature libraries. Both carry the LGPL license.

http://www.pygtk.org/
http://www.wxwidgets.org/about/newlicen.htm


You might find this interesting...

http://mail.python.org/pipermail/python-announce-list/2000-November/000572.html

Yes, it's old. That's part of the reason you get no traction on this.

Emile
 
R

rantingrick

You might find this interesting...
http://mail.python.org/pipermail/python-announce-list/2000-November/0...
Yes, it's old.  That's part of the reason you get no traction on this.

Thanks Emile. This read was both hair raising and informative.
Following is the relevant Tkinter parts posted verbatim with my
comments sprinkled throughout...

However, this process is still in its infancy, and the announcement
caused much worrying in the Tcl/Tk user community about the
language's future and its continued maintenance. This affects
Python because Tk, through the Tkinter module, is the most GUI most
commonly used with Python. Tkinter is included in the source
distribution, it's the most extensively documented, and it's the
most portable, supported on the Big Three platforms, namely Windows,
Unix, and MacOS.

It seems at the time (a decade ago) fantasies abounded about the
importance of Tkinter. I find it highly unlikely that Tkinter was OR
IS the "Most commonly used GUI with Python". Maybe the most commonly
used GUI library for utilities, but that's about it
Fredrik Lundh first posted a note about the announcement, and Eric
S. Raymond raised the question of what this meant for Tkinter: "This
raises anew a question I've been meaning to bring up for the last
week: is it finally time to move away from Python's dependence on
Tcl/Tk for GUI support?"

Yes (even a decade later!).
People were split on this question, though Guido was receptive to
the idea ("Yes, it may be time to have this discussion again.") and
pointed out some reasons to stick with Tkinter: "Tk has two very
high quality widgets: the Canvas and Text widgets are unsurpassed in
functionality and robustness by other widget sets.

Not anymore Guido!
You can draw
more lines or characters per second in most toolkits, but few
toolkits offer the convenience of marks and tags, not having to deal
with refresh events, being able to group objects, move them around,
change attributes, etc., etc., etc."

Thats a very weak argument. While i'll agree that the tagging system
employed by the TK::Canvas widget is helpful, the same functionality
can be reproduced by the programmer very easily. And i always prefer
to work with objects as opposed to tags because of the obvious
limitations.
Greg Wilson's reaction was "Yes please", and he went on to explain
what factors kept him using Tkinter for a recent course:
http://www.python.org/pipermail/python-dev/2000-October/016757.html

Well that link is broken so we will never know what greg said?
/F thought Tk was still a good choice, and said " ... and trust me,
the Python 2.0/Tk8.4/Tkinter3000 combo will rock ;-)". Tkinter3000
is an improved Tk interface that /F has been working on, with more
flexibility and better performance.
http://tkinter.effbot.org

Yea Frederic maybe Tkinter < exaggeration >"rocked the casba"</
exaggeration > in 2000, however we are building with steel and glass
now, not rock and stone.
/F also hoped that the Tcl Core Team would become more receptive to
making it easier to use Tk from other languages without Tcl having
to be in the middle, which would let the maintainers of Tkinter and
the Perl/Tk interface participate more in Tk's development.

Why in the world do WE -- THE Python community-- give two figs as to
how useful TclTk is to OTHER communities?
Eric S. Raymond speculated about the success of Tcl's new
development model: "Good for Tcl: Osterhout's rather lame attempts
to develop under a mixed model have almost certainly come to an end
in favor of an Apache-like model funded by big Tcl users."
http://www.python.org/pipermail/python-dev/2000-October/016763.html

Greg Ewing wondered if stdwin should be revived. GvR and Raymond
both thought that far too much work, and not productive of very good
results. "And stdwin would really look pathetic in this time", GvR
observed.

Well Guido, just imagine how bad Tkinter will look in 10 years ;-)
Python isn't tied very tightly to Tk, of course; well-maintained and
reasonably complete bindings exist for many different GUI toolkits,
such as Qt, GTk+, wxWindows, Windows MFC, and a few more.
http://www.thekompany.com/projects/pykde/
http://www.daa.com.au/~james/pygtk/ http://wxpython.org/
http://http://www.oreillynet.com/pub/a/217

Well i'd have to disagree being that Tkinter is IN the STDLIB!!!!
wxWindows is probably the most obvious second candidate, since it
actually supports all of the Big Three platforms, and no other
toolkit does. Robin Dunn, author of the wxPython binding, posted to
discuss the status of wxWindows on the Mac: "My understanding is
that the version in CVS is nearly up to date with the features in
the MSW and GTK versions, though I haven't had a chance to use it
myself. ... The next step I guess is getting it wrapped up in
wxPython..." http://www.python.org/pipermail/python-
dev/2000-October/016764.html

Finally some sanity in this thread!
There was no clear final decision, and my crystal ball didn't deign
to give an answer. Given all the uncertainties, it's probably best
to wait and see. If Tk's development continues to progress and
becomes more open to languages other than Tcl, Tkinter will probably
continue to be the most common Python GUI.

Thats ridiculous. Just because Tk becomes more open to other
developers (namely Perl, and Ruby) does not mean we should keep it
around for the same reason.
If not, we can consider
this question in another 6 months, which will give wxWindows and
wxPython time to develop on the Mac platform. And who knows? Maybe
something else will happen, such as Qt or GTk+ being ported to the
Macintosh.

Yea, i'll bet the author did not expect what has happened.

* Very slow if any advancement of Tk.
* wxPython became rich GUI library.
* Tkinter used only for utility and toy apps.
* An apathy for Tkinter within the community.
* and more
 
R

rantingrick



---- Greg Wilson -----
I thought about using wxPython in the most recent run of my Python
course, but
decided to stick to Tkinter because:

- There isn't a wxWindows/wxPython book (matters a lot when
organizations are
trying to decide what to adopt for long-term use).
---- Greg Wilson -----

WxPython could use better docs even today (not sure of what books are
available) however when we decide to integrate wx into the stdlib that
would be the best time to write a comprihensive "python specific
tutorial/docs

---- Greg Wilson -----
- Tkinter came packaged with the 1.5.2 installer, wxPython didn't.
---- Greg Wilson -----

Duh! And if wxPython came prepackaged this post whould never have
existed eh?

---- Greg Wilson -----
- There aren't as many tools on top of wxPython as there are on top of
Tkinter.
In particular, I think that a vector drawing package on top of
wxPython that
did what Sketch does, but on Windows as well as Linux, would make a
great
subject for a book on Python, non-trivial OO, and HCI (hint,
hint...)
---- Greg Wilson -----

Oh come on, this is about as weak as Guido's "tag" rant. A vector
drawing app is not a tool it's an app! An besides more "tools" or apps
will be written in wx when we integrate it into the stdlib, no doubt.
These are really ridiculous reasons for not choosing wxPython and i
suspect that you are just another one of the mindless "Tkinter"
zombies who base their judgments on friendships and constituents.
 
M

MRAB

[snip]
Greg Wilson's reaction was "Yes please", and he went on to explain
what factors kept him using Tkinter for a recent course:
http://www.python.org/pipermail/python-dev/2000-October/016757.html
Well that link is broken so we will never know what greg said?

[snip]
Yes:
http://mail.python.org/pipermail/python-dev/2000-October.txt

Sorry MRAB. I could not find Greg's reply in this mountain of Usenet
you posted a link to. You lose two points :(, oh wait, why should i be
unhappy ;-)
Did you try searching for "yes please"? It takes just seconds...
 
N

Neil Hodgson

Emile van Sebille:
The problem with QT is the license.

From http://qt.nokia.com/products/licensing/:

Qt Commercial Developer License
The Qt Commercial Developer License is the correct license to use for
the development of proprietary and/or commercial software ...

The LGPL version is also useful for producing commercial software.
From the same web page:

"""
Qt GNU LGPL v. 2.1 Version
This version is available for development of proprietary and commercial
applications in accordance with the terms and conditions of the GNU
Lesser General Public License version 2.1.
"""

Developing a proprietary (closed source) application using LGPL
libraries is normally not a problem as the only pieces of code you have
to publish are changes to those LGPL libraries, not the application
code. Most applications do not change the libraries.

The "can't reuse LGPL code" clause is a restriction on what can be
done with the Qt Commercial Developer License not on what can be done
with the LGPL license.

GTK+ has always been LGPL and that license has not been an obstacle
to either open source or closed source projects.

Neil
 
O

Octavian Rasnita

From: "Adam Skutt said:
you keep promoting
I would be glad if you could tell me about a portable solution which is
accessible with JAWS and Window Eyes, the most used screen readers under
Windows (real glad).

I did, Qt. I'm not yournanny and I'm not going to go test it for
you. There are bugs in the Qt database relating to JAWS
functionality, so it others have plainly gotten it working to some
degree. But honestly, why should I waste my time replying to you when
you're too damn lazy to even use Google? I certainly won't be doing
so in the future. "Lead a ignorant, thirsty horse to water, watch it
die of thirst" and all that.


I have tried more QT-based apps and I couldn't find one to be accessible,
while most widgets offered by WxPython are accessible out of the box.

QT is really bad, but you hijacked the tread because as you can see even in
the subject, we are talking about Tkinter, not about QT.

If QT is not included by default in Python, it is not such a big problem
because only those who care more about the visual aspect than about the
accessibility use it, but Tkinter is bad because it is promoted and many
beginners will start using it witout knowing how bad it is and why.

You keep telling that you searched on the web for finding what the others
say about accessibility but this is a very wrong way. Don't say anything
about accessibility if you haven't tried personally.

Octavian
 
R

rantingrick

This is exactly what Aristotle meant when he said...


""" Tolerance and Apathy are the last virtues of a dying society! """

Specifically no one here has the nerve to question/argue Guido when he
offers such weak arguments like the "tag" argument. Can you really
base the worth of any library on such a limited argument. I would bet
that most people who use Tkinter ARE NOT using the canvas anyway. They
are not interested in drawing simple lines and rects and just looking
at them. No. They are intersted in creating GUIs with frames, buttons,
labels, radiobuttons, checkbuttons, listboxes, textboxes, notebooks,
comboboxes, and dialogs just to name a few.

However in light of such a weak argument presented TEN YEARS AGO not
one person dared to even question the BDFL. If i were Guido i would be
disappointed. The very community he has built has degenerated into
mindless goose stepping "yes" men. AND THAT WAS TEN YEARS AGO!

Congratulations "yes men" you are the genesis of this self
destruction. I think i should find a fiddle...
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,764
Messages
2,569,564
Members
45,041
Latest member
RomeoFarnh

Latest Threads

Top