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

[rantingrick]

I did. Well, they say, "Beauty is in the eye of the beholder!". To me,
these are mostly awesomely ugly, ugly, ugly. Shot 1: Ugly gray field
followed by shot2: ugly black on gray. These first two examples look
like Windows 95/8 -- ie, 20th century look, not 21st.

Now hold on Terry because you are overreacting just a bit here. If you
remember i had requested that everyone download the beautiful demo and
only look at the screen shots as a last resort. It seems you went to
the screenshots page and went home in a huff. However let's
investigate the screen shots with a little more clarity shall we?

#########
# Shot1 #
#########
This shot shows the most minimal wx GUI, that is, a simple Toplevel
window and nothing more. And if you took the time to read the captions
above that said... "Here is a screen shot of the "minimal" wxPython
application:"... and the screenshot below that said... "Okay, so it is
very minimal, but it is small enough that the source should be
understandable without somebody holding your hand... Take a peek."...
you probably would not have jumped to such bombastic conclusions.

##########
# Shot 2 #
##########
This shot merely builds on shot one. Nothing fancy. They were not
trying to woo you with the most fancy GUI coding available from shot
one (psst: THAT IS WHAT THE DEMO IS FOR!). You must remember that
screen shots are for inquisitive and possible future users. If you
continue to follow along with the shots you'll see the complexity
increase with each shot. It seems to me that "easy intoduction" was
the focus of the screenshots not "selfish vanity" (psst: THAT IS WHAT
THE DEMO IS FOR!)

Based on this page, wxwidgets would be a regression from tk.

Yes one might come to that conclusion if they are as shallow as you
seem to be behaving Terry. However i urge you to download the wxPython
demo and then give me an honest opinion. but only AFTER you have spent
at least one hour familiarizing yourself with all the feature richness
of this great GUI library. Heck each widget has an overview page, a
source code page, and a demo page all wrapped up into a nice GUI. No
GUI in the world is this user friendly! Geesh!

Current
tkinter on Windows looks like it use native Windows windows. IDLE on
WinXP looks like a WinXP app; on Windows 7 it looks like a Windows 7
app. If wxwidgets/wxpython does the same, this page hides it very well.
And this is apparently an update from 'the old Screen shots' page.

I'll agree this screenshots page needs an update. However (like me)
the wxPython folks probably put more time into the demo and thought
that most people would at least download it before jumping to
conclusions about the screenshots without sufficient data. Oh, did i
give you the demo link. No? Well here it is again...

http://www.wxpython.org/download.php#stable

The above is based on presented looks. I have no idea whether, to what
extent, and how easily one could duplicate the layout and performance of
the examples with tk.

Tkinter and all of TclTk cannot hold a matchstick to WxPython in
feature richness. Anyone who says otherwise is ill-informed!

There are, however, other problems with wx that I
have and will point out in other posts.

Please elaborate, these are free and open forums as far as know...?

 

[rantingrick]

[...snip: emotionally nonsensical hyperbole...]

Adam. Arguing with you is like masturbating with a cheese-grater...
slightly amusing, but mostly painful. I don't have the energy to chase
my tail like you do.

 

[geremy condra]

I don't have the energy to chase my tail like you do.

Hahahahahahahaha. Troll.

Geremy Condra

 

[rantingrick]

Hahahahahahahaha. Troll.

Coming from someone who actually gives advice on how to troll more
efficiently... now that is ironic!

###################################################
# Geremy Condra From: I strongly dislike Python 3 #
###################################################
Eh, 3 troll points out of 10. Bonus awarded for the gratuitous sexual
reference, but the deductions for lack of finesse more than overcame
it. Some suggestions for next time:
* use proper punctuation- it lends your posts an air of
seriousness.
* use the weakest arguments presented- it infuriates those who
support the position you're trolling from as well.
* overly dramatic statements are a dead giveaway.

Hmm. So i take it you are some sort of *expert* on the matter of
trolling then?

 

[geremy condra]

Coming from someone who actually gives advice on how to troll more
efficiently... now that is ironic!

###################################################
# Geremy Condra From: I strongly dislike Python 3 #
###################################################
Eh, 3 troll points out of 10. Bonus awarded for the gratuitous sexual
reference, but the deductions for lack of finesse more than overcame
it. Some suggestions for next time:
 * use proper punctuation- it lends your posts an air of
seriousness.
 * use the weakest arguments presented- it infuriates those who
   support the position you're trolling from as well.
 * overly dramatic statements are a dead giveaway.

Hmm. So i take it you are some sort of *expert* on the matter of
trolling then?

I've read most of your threads, yes.

Geremy Condra

 

[Terry Reedy]

remember i had requested that everyone download the beautiful demo and
only look at the screen shots as a last resort.

You called them 'awesome'. I did not expect 'awesomely ugly'.

Screenshots are the first thing for someone to look at, to see WHAT THE
APP LOOKS LIKE, and to decide whether one wants to bother to download,
switch to admin, install, run, and uninstall (and hope that that really
disinstalls everything). I looked and decided that what I saw (except
for the Mac example), was too ugly to bother with, at least for now.

One of the criticisms against tk has been that it is 'ugly' compared to
other other guis. Comparing current tk against the screenshots, I saw
the reverse.

If the screenshots are awesomely unfair to wx, because they are actually
12 years old and RD and the wxpython community cannot be bothered to
update them at least to merely 7 years old, that is their fault, not
mine for taking them at their presentation.

#########
# Shot1 #
#########
This shot shows the most minimal wx GUI, that is, a simple Toplevel
window and nothing more.

And to me it is ugly compared to a minimal tk GUI.

##########
# Shot 2 #
##########
This shot merely builds on shot one. Nothing fancy.

And it is ugly compared to the equivalent tk example.

> However i urge you to download the wxPython
demo and then give me an honest opinion.

If you think the site is bad, send me a ONE better screenshot, or link
thereto, of wx on WinXP/Vista/7. I promise to look at it. Then urge
Robin to update the page.

But until wx is either a serious contender for the stdlib, or I have
personal need of a modern gui system, or I become curious enough about
wx, compared to other things I have already downloaded and not looked
at, I have little reason to spend more time with it. I already know that
some people like wx and swear by it and have even had the vague idea
that it somehow should replace tk.

I'll agree this screenshots page needs an update. However (like me)
the wxPython folks probably put more time into the demo and thought

If Python developers gave that excuse to not update decade-old examples
in the doc, you would probably rant about it for a week;-).

Instead, we are updating text and examples as problems are discovered
and we can get to them. I improved some years-old text and examples just
last week. 3.2 will have hundreds of other improvements.

Please elaborate, these are free and open forums as far as know...?

There are two issues: some interface to wxwidgets, and wxpython as that
interface or the base therefore.

As to wxpython: for starters, it is written in Python2, not Python3. It
is owned by Roben Dunn and he has shown no interest that I know of in
having it in the stdlib. Given what that would mean in terms of loss of
control of interface, code style, docs, release schedule, repository,
and so on, I would not either if I had done what he has done.

A wxinter written for the stdlib in Python3, possibly based on ctypes
rather than swig or the equivalent, might be a stdlib candidate,
somewhat independently of the fate of tkinter. But no one has
volunteered and you yourself suggested that such are unlikely.

 

[rantingrick]

You called them 'awesome'. I did not expect 'awesomely ugly'.
Screenshots are the first thing for someone to look at, to see WHAT THE
APP LOOKS LIKE, and to decide whether one wants to bother to download,
switch to admin, install, run, and uninstall (and hope that that really
disinstalls everything). I looked and decided that what I saw (except
for the Mac example), was too ugly to bother with, at least for now.

Ok, Ok, i concede. The screenshots are horrendous, atrocious, and
utterly reprehensible. I should never had posted a link to such a
horrible example of wx. Trust me wx is much more beautiful than that!

One of the criticisms against tk has been that it is 'ugly' compared to
other other guis. Comparing current tk against the screenshots, I saw
the reverse.

Ok, but read on because i may be able to convince you with some new
screenshots...

If you think the site is bad, send me a ONE better screenshot, or link
thereto, of wx on WinXP/Vista/7. I promise to look at it. Then urge
Robin to update the page.

Ok, try this...

http://juicereceiver.sourceforge.net/screenshots/index.php

and this...

http://www.sensi.org/~ak/pyslsk/pyslsk6.png

and this (wxWidgets)...

http://www.wxwidgets.org/about/screensh.htm

If Python developers gave that excuse to not update decade-old examples
in the doc, you would probably rant about it for a week ;-).

Agreed. These horrible screenshots need to be updated yesterday! Or
just redirect to the wxwidgets screenshots if they are too lazy.

There are two issues: some interface to wxwidgets, and wxpython as that
interface or the base therefore.

As to wxpython: for starters, it is written in Python2, not Python3. It
is owned by Roben Dunn and he has shown no interest that I know of in
having it in the stdlib. Given what that would mean in terms of loss of
control of interface, code style, docs, release schedule, repository,
and so on, I would not either if I had done what he has done.

Agreed. However we NEED Roben Dunn to keep doing what he is doing now.
And we need the people who are investing (maybe wasting) energy on
Tkinter to focus on a small subset of wx for stdlib inclusion. Roben
can keep his BDFL title, and Python can be updated.

 

[Octavian Rasnita]

From: "Steven D'Aprano" <[email protected]>
Sent: Monday, January 17, 2011 1:04 AM
Subject: Re: Tkinter: The good, the bad, and the ugly!
.....

Well, true, but people tend to *use* the parts of the GUIs that are
simple and basic. Not only do the big complicated apps get all the press
even when they are actually a niche product (everyone knows about
Photoshop, but more people use MS Paint) but it's a truism that most
people use something like 20% of the functionality of big, complicated
GUI apps. Most people use Microsoft Word or OpenOffice for little more
than text editing with formatting.

True, but the most important thing is that those apps need to work and these
days the portability of programs is also important for making them available
to as many people as possible.

wxWIDGETS are portable and also pretty accessible for those who need to use
screen readers which is not the case of purely native widgets as the Win32
GUI standard controls or the libraries like Tk, GTK or QT.

Octavian

 

[Steven Howe]

From: "Steven D'Aprano" <[email protected]>
Sent: Monday, January 17, 2011 1:04 AM
Subject: Re: Tkinter: The good, the bad, and the ugly!
....



True, but the most important thing is that those apps need to work and
these days the portability of programs is also important for making
them available to as many people as possible.

wxWIDGETS are portable and also pretty accessible for those who need
to use screen readers which is not the case of purely native widgets
as the Win32 GUI standard controls or the libraries like Tk, GTK or QT.

Octavian

If you are making a product, you want it to be unique and inaccessible
to other companies/products. Hence 'propriety'. It's part of that
'capture the market' mindset that engineers and programmers have a
problem with. Fight or flight, you have to deal with it.

So ...

Target your market. Design your software in the Model-View-Controller
format. It becomes easy to configure you frontend, your GUI, your web
page, if your code is written to separate the work from the glitz.

Car companies know this. There is the body design crew, and the
engineers that make it work. So software products too. Artists always
come first; with good reason, their work catches the eye; remember what
Dr. Lecter said "Don't your eyes seek out what you want Clares?".
Fighting that fact, for 'efficiency' is just tilting at windmills (or
Pontiac Aztec).

Instead, think 'optimal' i.e. maximum usage per market. MVC makes that
approach reasonable in the first market. Easy in the second (Apple),
third (Linux) and fourth (BSD).

In the mean time, quit bad mouthing works like Tk/Tcl that have come
before the current crop. Their successors too shall pass.

Oh, and if your interested, I'm in the third market, been here since
1992. Time and Tide Microsoft, Apple. Time and tide.

Steven

 

[Adam Skutt]

Target your market. Design your software in the Model-View-Controller
format. It becomes easy to configure you frontend, your GUI, your web
page, if your code is written to separate the work from the glitz.

If there were some evidence MVC actually worked, perhaps.
Unfortunately, there isn't, so there's little reason to do this.
Nevermind that most MVC frameworks get the definitions entirely wrong,
despite the plethora of examples from the original paper (e.g., Swing
does).

Car companies know this. There is the body design crew, and the
engineers that make it work.

No, there really isn't anymore. Integrated teams are the mandatory
order of the day, because getting the necessary fuel economy requires
paying close attention to body design. Vehicles where the designer
runs rampant over the look are getting rarer, and will continue to do
so as long as governments continue to tighten fuel economy standards
(and to a lesser degree, safety standards).

Adam

 

[Adam Skutt]

We are not talking about running applications, but about writing
applications.

Someone has to write the applications I run...

I count 4000+ .py files in my /usr/share alone on Ubuntu.
Your set is totally unrepresentative for those scripts.

Yeah, go back and count how many of those actually use a GUI and were
not written by Canonical for the purpose of OS configuration (though
it'd be especially odd to find them in /usr/_share_). Such a response
is entirely and completely disingenuous and borderline insulting. You
and rick both need eye exams, apparently.

Adam

 

[Albert van der Horst]

You need a tremendous set to write /the majority of the applications
on your computer/.

On my desktop right now, I have running:
* Google Chrome
* TweetDeck
* PuTTY
* Pidgin
* Game for Windows Launcher
* Free Download Manager
* Steam Client
* A Windows Control Panel Window

None of those applications could be written with his proposed widget
set, he's literally 0/7 on running applications. If the situation
isn't the same on your computer then your application usage is highly
unusual or you don't understand what widgets are used to construct
your applications. You've just told me that Python would no longer be
suitable for constructing the majority of GUI applications on the
planet.

We are not talking about running applications, but about writing
applications.
I count 4000+ .py files in my /usr/share alone on Ubuntu.
Your set is totally unrepresentative for those scripts.

Adam

Groetjes Albert

 

[Albert van der Horst]

On Sun, 16 Jan 2011 07:18:16 -0800, Adam Skutt wrote:

[...]

I'm afraid I found most of your post hard to interpret, because you
didn't give sufficient context for me to understand it. You refer to "his
proposed widget set", but with no clue as to who he is, or what the
widget set is, or what essential widgets you continue missing. I can
guess "he" is rantingrick, but am not sure -- there's only so much of his
time-wasting I can read before reaching for the killfile. Rantingrick
believes he is doing us a service by haranguing us incessantly into
scratching *his* poorly thought-out itches, regardless of practicality or
actual need.

But putting that aside, I'd like to comment on a few points:

[...]

If the situation isn't
the same on your computer then your application usage is highly unusual
or you don't understand what widgets are used to construct your
applications. You've just told me that Python would no longer be
suitable for constructing the majority of GUI applications on the
planet.

No, that does not follow. Unless "he" (I'll assume it is rantingrick) has
proposed hunting down and destroying all third-party GUI tool sets, what
you've been told is that *one specific* tool set is unsuitable for
constructing the majority of GUI apps.

Actually it was me. Those guys don't even know how to attribute
or quote.

[...]

Really, if you believe the case to be otherwise, I truly believe you
aren't paying attention to your own computer(s), or don't understand how
the applications you use are constructed. What's out there isn't
interesting, it's what people use that's interesting, and people tend to
use GUIs that are moderately to highly complicated.

Well, true, but people tend to *use* the parts of the GUIs that are
simple and basic. Not only do the big complicated apps get all the press
even when they are actually a niche product (everyone knows about
Photoshop, but more people use MS Paint) but it's a truism that most
people use something like 20% of the functionality of big, complicated
GUI apps. Most people use Microsoft Word or OpenOffice for little more
than text editing with formatting.

It's easy for power users to overestimate how much of their complicated
GUIs are actually used by the average user. Or even the *above* average
user.

Or even for the support of other packages, I gave the bluetooth
example. I think the use of Python for e.g. configuration of
packages is quite common.

I suspect that a variation of Zipf's Law probably holds for GUI
complexity -- if you rank the widgets in order of most to least commonly
used, I expect that you'll see actual use drop away rapidly and at an
accelerated rate. E.g. the widget in second place might be used roughly
half as often as the widget in first place place, the widget in third
place one third as often, the widget in fourth place one quarter as
often, and so forth.

That is the point I wanted to make.

Groetjes Albert

 

[Steven D'Aprano]

If you're going to expect me to be that pedantic, then pay me the
courtesy of taking the time to find the necessary context. Nevertheless,
it's not the least bit unreasonable to address deficiencies in the
standard library as deficiencies in the language, like it or not;

I'm afraid that's precisely what I'm arguing you *can't* do -- there's
nothing reasonable about equating the standard library with the language.
Some languages don't even have a standard library, or for that matter a
standard implementation.

Would you argue that Python is unsuitable for parsing real-world (i.e.
broken) HTML because Beautiful Soup is not in the standard library? That
Python is unsuitable for scientific and mathematical processing because
Scipy and Numpy aren't in the standard library? That you can't do natural
language processing with Python because NLTK is not in the standard
library? That you can't do image processing with Python because PIL is a
third-party library?

There's no doubt that having a good standard library with a rich toolset
is a beneficial feature of Python. Python's philosophy of "batteries
included" has been one of it's strengths. But it would be absurd to claim
that if a tool isn't in the standard library, the language can't do it.

and since rick's proposal involves regressing the standard library..

If you think I'm supporting Rick's incoherent proposal, you've
misunderstood me.

In any case, I'm not disputing that if you wish to write modern looking,
and feeling, GUI apps, you need a powerful widget set, or spend all your
time reinventing the wheel. Nevertheless, you can do good, useful work
with only a minimal widget set. Back when dinosaurs walked the earth, I
wrote GUI apps using an *extremely* limited widget set, equivalent to
window, button, text field, and simple bit-mapped graphics -- no menus,
no scroll bars, no list boxes, no styled text, and certainly no layout
widgets. By today's standards, that's even more primitive than the
average web UI, and yet some of the apps written in it were useful and
even elegant. (I don't claim credit for the elegant ones, but the ones I
wrote were at least useful to me.) You can get surprisingly far with only
simple widgets and a bit of ingenuity. Or at least by lowering your
expectations. *wink*

 

[rantingrick]

Everyone needs to jump off the troll wagon and come back to reality.
We need to get back on topic and compare Tkinter and wxPython by nuts
and bolts. We need to make a decision based on facts NOT
misconceptions, based on merit NOT prejudice, and finally based on
sanity NOT lunacy!

-------------------
Tkinter Pros:
-------------------
* Very simple to use!
* Geometry managers are a delight!

------------------
Tkinter Cons:
------------------
* very limited widget set!
* some of the widgets have a asinine API!
* very poor packaging of widgets (extensions)
* the events where given horrendous names:
ButtonRelease-1 -> ButtonOneRelease
B1-Motion -> ButtonOneMotion
etc
* slow execution speed due to calling ANOTHER interpretor!
* not extensible within our community!
* no real Grid Widget.
* no real Listveiw Widget.
* not real OpenGL Widget (togl sucks).
* the Canvas is lacking manipulators, rotation, etc.

 

[Octavian Rasnita]

From: "Steven D'Aprano" <[email protected]>
Subject: Re: Tkinter: The good, the bad, and the ugly!

I'm afraid that's precisely what I'm arguing you *can't* do -- there's
nothing reasonable about equating the standard library with the language.
Some languages don't even have a standard library, or for that matter a
standard implementation.

Would you argue that Python is unsuitable for parsing real-world (i.e.
broken) HTML because Beautiful Soup is not in the standard library? That
Python is unsuitable for scientific and mathematical processing because
Scipy and Numpy aren't in the standard library? That you can't do natural
language processing with Python because NLTK is not in the standard
library? That you can't do image processing with Python because PIL is a
third-party library?

There's no doubt that having a good standard library with a rich toolset
is a beneficial feature of Python. Python's philosophy of "batteries
included" has been one of it's strengths. But it would be absurd to claim
that if a tool isn't in the standard library, the language can't do it.

Well, you are right, but it is not the same thing.

If Tkinter is included by default in Python package, much more programmers would be tempted to use Tkinter instead of WxPython, so they will create bad programs.

The best idea would be to include WxPython in Python and eliminate Tkinter.
If this is not possible, because of those reasons that were discussed here, then the second-best idea would be to just eliminate Tkinter from Python, because as you said, if it is not included, it doesn't mean that a module can't be used, but in that case the programmers won't be tempted to use it.

And Python should also not include any editor because for some programmers it is absolutely useless anyway. The editor can be installed separately very easy and the programmers can choose the editor they like.

The problem is not that WxPython is not encouraged, but that Tkinter is encouraged because it is promoted.

Octavian

 

[rantingrick]

And Python should also not include any editor because for
some programmers it is absolutely useless anyway. The
editor can be installed separately very easy and the
programmers can choose the editor they like. The problem
is not that WxPython is not encouraged, but that Tkinter
is encouraged because it is promoted.

These are very true statements Octavian! I had always believed that
Python should include a GUI AND and IDE even though Tkinter and IDLE
are severely dated. Now i am thinking that maybe we should judt dump
both and leave it that way.

Why did i previously think this way? Well my concern was to keep the
goals of GvR alive. That is that programming should be for everyone
and having a simplistic IDE and GUI in the stdlib help foster these
goals. However that was circa 1980's and we now find our selfs a
decade past the 21st century. We now have a huge amount of 3rd party
GUI's and IDE's. Do we even need to include them any more? Sure one
could always argue batteries included however with the plethera of 3rd
party downloads, the batteries may not be included, but they are
located witin reach at the reqister check out

Q. Do we need ANY GUI or ANY IDE in the stdlib anymore?

I say probably not considering the availability of 3rd party
downloads. What say you, Python community?

 

[rantingrick]

More post thoughts on removing all GUI's from stdlib...

This change would not only affect Python in a positive way (lighting
the proverbial load) it would also serve to speed the advancement of
Tkinter because now Tkinter could advance at its own pace untethered
by the release cycles of Python! You guys need to start thinking about
this from a purley community perspective.

 

[Adam Skutt]

I'm afraid that's precisely what I'm arguing you *can't* do -- there's
nothing reasonable about equating the standard library with the language.
Some languages don't even have a standard library, or for that matter a
standard implementation.

And we're not discussing those languages, we're discussing Python,
which has an explicit policy of "batteries included". As such,
criticism of the standard library is perfectly acceptable under the
name "Python", whether you like it or not. Besides, it's inevitable
anyway.

Would you argue that Python is unsuitable for parsing real-world (i.e.
broken) HTML because Beautiful Soup is not in the standard library? That
Python is unsuitable for scientific and mathematical processing because
Scipy and Numpy aren't in the standard library? That you can't do natural
language processing with Python because NLTK is not in the standard
library? That you can't do image processing with Python because PIL is a
third-party library?

Out of the box? Absolutely. Again, expecting me to explicitly state
that is worthless pedantry, especially when the discussion at hand
proposes modifications to the standard library. There's no question,
in context, about what my words meant.

There's no doubt that having a good standard library with a rich toolset
is a beneficial feature of Python. Python's philosophy of "batteries
included" has been one of it's strengths. But it would be absurd to claim
that if a tool isn't in the standard library, the language can't do it.

Too bad that isn't what I claimed, nor can what I said be interpreted
as such in any way whatsoever, unless you're a pedantic twit.

If you think I'm supporting Rick's incoherent proposal, you've
misunderstood me.

If you think what I said somehow even implies you support his
proposal, then you need to take a few English courses.

Nevertheless, you can do good, useful work
with only a minimal widget set. Back when dinosaurs walked the earth, I
wrote GUI apps using an *extremely* limited widget set, equivalent to
window, button, text field, and simple bit-mapped graphics -- no menus,
no scroll bars, no list boxes, no styled text, and certainly no layout
widgets. By today's standards, that's even more primitive than the
average web UI, and yet some of the apps written in it were useful and
even elegant. (I don't claim credit for the elegant ones, but the ones I
wrote were at least useful to me.) You can get surprisingly far with only
simple widgets and a bit of ingenuity. Or at least by lowering your
expectations. *wink*

And when a time machine warps all back to the 1980s, that argument
might have some merit. Since you're not Dr. Emmett Brown, I suggest
you refrain from making arguments that predicate themselves on time
travel.

Adam

 

[rantingrick]

Even more post thoughts on removing all GUI's from stlib...

Q: If you could replace Tkinter with any module/library (THAT IS NOT A
GUI OR IDE!!) what would you like to see fill its place?

PS: And please make this decision from a *community* perspective and
not pure selfishness.