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

[Steven D'Aprano]

Also one could argue that C and Python are very similar.

One could also argue that black is white, that diamond is softer than
chalk, and that bananas are a type of spaceship. Doesn't make it so.

How to add two numbers in C:

#include <stdio.h>
int main()
{
int a, b;
scanf("%d%d", &a, &b);
printf("%d\n", a + b);
return 0;
}

And in Python:

a, b = input().split() # use raw_input in Python 2
print(int(a) + int(b))


And in Tcl:

scan [gets stdin] "%d %d" x y
puts [expr {$x + $y}]


None of the three are exactly clones of each other, but it seems to me
that Tcl and Python are quite close in spirit, if not syntax.

 

[Terry Reedy]

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

1. A cross-platform printing API. This is mainly an issue on Windows,
which lacks a rich command-line printing framework. The canvas widget
can generate PostScript,

Uh.
1. Postscript is somewhat obsolete; being superseded somewhat by svg.
2. It is not as useful on Windows as it seems to be on *nux and macs --
not easy to either view or print.

3. The files it calls '.eps' are not readable by OOo. They can be read
by Photoshop, which can then write a file, supposedly the same but
actually not, that *can* be read by OOo. There was a thread on this list
about the issue.

I do not know whether tk is too sloppy in what it writes (and the file I
look for a trivial drawing did look sloppy, with lots of near
repetition) or whether OOo is too strict. But clearly, TK *could* write
better .eps files (like Photoshop does). And the current output is
clearly limited for my purposes.

 

[Mel]

Also one could argue that C and Python are very similar.

One could also argue that black is white, that diamond is softer than
chalk, and that bananas are a type of spaceship. Doesn't make it so.

How to add two numbers in C:

#include <stdio.h>
int main()
{
int a, b;
scanf("%d%d", &a, &b);
printf("%d\n", a + b);
return 0;
}

And in Python:

a, b = input().split() # use raw_input in Python 2
print(int(a) + int(b))


And in Tcl:

scan [gets stdin] "%d %d" x y
puts [expr {$x + $y}]


None of the three are exactly clones of each other, but it seems to me
that Tcl and Python are quite close in spirit, if not syntax.

They both have the interpreter spirit. Very different under the hood; Tcl
is the LISP of strings. They could have called it STRP.

Mel.

 

[Kevin Walzer]

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

You can build web servers, database tools, FTP clients, test
suite/automation tools, chat clients, and drivers of other CLI tools
with Tcl, just to name a few. In terms of what can be done with the
language, I'm not aware of anything that can be done in Python that
can't be done in Tcl.

The size of Python's community and its large standard library are an
advantage over Tcl. While Tcl is technically capable of many things,
it's often easier to find a Python library already coded for specific
functions--for instance, while Tcl has XML parsing and can parse RSS, it
doesn't have a rich library like feedparser all wrapped up and ready to go.

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

I find that Tcl's "everything is a string" representation offers a more
flexible and expressive approach in certain contexts. Tcl's "exec"
function makes interacting with external tools simpler than os.popen and
subprocess--I can get the output of a command with less code.

Of course, this is partly a matter of taste.

--Kevin

 

[rantingrick]

How to add two numbers in C:

[...snip code example...]

None of the three are exactly clones of each other, but it seems to me
that Tcl and Python are quite close in spirit, if not syntax.

Yes i'll agree to that if you also agree that Python and Perl are the
same. Then i "maybe" your "suggestion" holds water, maybe. But you
forgot to comment on the other big point which is... What language
would you rather spend your time learning if you only had C and Tcl to
choose from? If you answer Tcl you are either foolish or just trying
to win the argument by playing devils advocate, and in that case
you're even more foolish!

The moral is that C and Python are far more useful to any programmer
than Tcl will ever be -- whether you consider them together or apart
does not matter. Tcl is too limited whereas Python and especially C
are far more useful in various situations.

 

[rantingrick]

You can build web servers, database tools, FTP clients, test
suite/automation tools, chat clients, and drivers of other CLI tools
with Tcl, just to name a few.

Ok, thats swell. But do you have any real examples, links, or some
evidence of this? Or are we witnessing more wishful thinking?

In terms of what can be done with the
language, I'm not aware of anything that can be done in Python that
can't be done in Tcl.

Again the proof is in the pudding my friend!

The size of Python's community and its large standard library are an
advantage over Tcl.

Yes, go on...

While Tcl is technically capable of many things,
it's often easier to find a Python library already coded for specific
functions--for instance, while Tcl has XML parsing and can parse RSS, it
doesn't have a rich library like feedparser all wrapped up and ready to go.

Thanks, well i must say that it it getting easier to win this
argument.

I find that Tcl's "everything is a string" representation offers a more
flexible and expressive approach in certain contexts.

Maybe but that is hardly going to "woo" the masses is it?

Tcl's "exec"
function makes interacting with external tools simpler than os.popen and
subprocess--I can get the output of a command with less code.

Newsflash!, NewsFlash!, Python has an exec function. Am i missing
something here?

Of course, this is partly a matter of taste.

Well your posts so far are leaning heavily that way Kevin

 

[Arndt Roger Schneider]

No wx is not the answer to our problems

Rather: ... to *your* problem...

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

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

There are enough out there in the wild,
they will last quite for awhile indeed;
but it's time for them to die.

Sword Two: On the other hand web frameworks provide awesome cross
platform ability that is surly only going to get better as time goes
-- however i utterly hate JavaScript (although much worse web
languages exist!). And sending requests back and forth between Python,
JavaScript,

Apparently the authors do know that, too:
MessageID:<[email protected]>,
*sigh* no svg.

BTW: Look in comp.lang.javascript:
javascript is framework/toolkit resistent.

and BrowserX is also a real PITA. Because even though

everyone knows this is coming all the major browsers are trying to
insert their API into the mix. So that Joe Scripter has to write code
that is compatible between many browsers. Until the world agrees on a
unified API --AND IMPLEMENTS IT SERIOUSLY-- we are at the mercy of
drunken sailors at the helm.

svg: opera, chrome, safari(including ios), ie9, firefox.
Although svg is missing under webkit/android
--Apple kept the hardware accelerated part to themeselves.
Goolge is currently implementing hardware acceleration for svg in
chrome/webkit, likewise Microsoft/ie.
Lets wait and see when svg becomes available in android, too.

Although smil is quiet another subject.

I believe pyjamas has a bright future in the web playground, however
we still need to focus our community efforts towards a Python based
GUI. I can see a pythonGUI and pyjamas existing side by side in mutual
harmony for many years.

pyjamas: Perhaps without javascript.

-roger

 

[Kevin Walzer]

Ok, thats swell. But do you have any real examples, links, or some
evidence of this? Or are we witnessing more wishful thinking?

http://tcl.apache.org/rivet/
http://www.amsn-project.net/
http://thecoccinella.org/
http://personal5.iddeo.es/andresgarci/tclcurl/english/
http://openacs.org/
http://www.aolserver.com/
http://www.macports.org/
http://www.nist.gov/el/msid/expect.cfm
http://www.simulistics.com/
http://personal5.iddeo.es/andresgarci/getleft/english/
http://model.com/
http://sqlitestudio.one.pl/index.rvt
http://www.speech.kth.se/wavesurfer/
http://www.ellogon.org/
http://moodss.sourceforge.net/
http://www.projectforum.com/
http://www.eggheads.org/
http://brlcad.org/
http://www.muonics.com/

 

[Robert]

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

I am sorry, are you always an inconsiderate idiot? That is exactly what
you are coming across as.

 

[Robert]

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

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

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

Good luck with that.

 

[Robert]

How to add two numbers in C:

[...snip code example...]

None of the three are exactly clones of each other, but it seems to me
that Tcl and Python are quite close in spirit, if not syntax.

Yes i'll agree to that if you also agree that Python and Perl are the
same. Then i "maybe" your "suggestion" holds water, maybe. But you
forgot to comment on the other big point which is... What language
would you rather spend your time learning if you only had C and Tcl to
choose from? If you answer Tcl you are either foolish or just trying
to win the argument by playing devils advocate, and in that case
you're even more foolish!

The moral is that C and Python are far more useful to any programmer
than Tcl will ever be -- whether you consider them together or apart
does not matter. Tcl is too limited whereas Python and especially C
are far more useful in various situations.

I'll bite. Exactly how is Tcl too limited in your view?

 

[Gerry Reno]

For those that are lurking, this might provide a little background:

http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong



Essentially, there is nothing "wrong" with Tcl and Tkinter. They are
part of a long evolutionary chain of how we got to where we are today.
They deserve to be respected for the contributions that they have made.

The question now is whether Python needs to evolve its own GUI toolset.


Regards,
Gerry

 

[rantingrick]

Exactly how is Tcl too limited in your view?

Well Robert if have explain to you why C and Python make Tcl look
limited by comparison then explaining will probably do neither of us
any good. But if you think Tcl is so great by all means go spend the
next couple of years writing legacy code until you realize one day it
was all for nothing.

But let's get back on topic here shall we. I have some questions
specifically for you Robert...

1. Have you ever used Tkinter?
2. If so, explain what you created with it in detail?
3. What is your opinion of Tkinter as to it's usefulness within the
stdlib?
4. How long should we keep Tkinter in the stdlib?
5. Should Python even have a GUI in the stdlib?
6. If Python should have a GUI, then what traits would serve our
community best?

I will be really surprised if you answer any of these questions. And
sorry, but i did not have time to spec out a multiple choice Q&A for
you. So take your time Robert.

 

[Katie T]

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

It's very hard to write a good gui framework, very very few people
have managed to do it well. Microsoft, Sun and Google have all had the
resources to hire very good developers and designers to dedicate to
the task and still haven't managed to do it well.

There's not the expertise or the investment in the Python community to
build a strong Python GUI solution. From an educational viewpoint I
see that there could be value in having a pure Python solution, but in
terms of having a GUI solution that people will actually want to use
in their apps, I'm dubious that it's achievable.

Katie

 

[Robert]

For those that are lurking, this might provide a little background:

http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong



Essentially, there is nothing "wrong" with Tcl and Tkinter. They are
part of a long evolutionary chain of how we got to where we are today.
They deserve to be respected for the contributions that they have made.

The question now is whether Python needs to evolve its own GUI toolset.


Regards,
Gerry

You mean outside of wxPython or PySide/PyQt? I don't see the need really.

 

[rantingrick]

For those that are lurking, this might provide a little background:

   http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong

That was a great and thought provoking article Gerry. Thanks!

 

[rantingrick]

On 2010-12-30 19:46:24 -0500, rantingrick said:
Just to clarify...I like Python. I am learning it at the moment.

Glad to have you aboard Robert!

No, I really don't see the need for it to be in the stdlib but that
isn't my call.

But it is your call Robert. Anyone who writes Python code --whether
they be a beginner with no prior programming experience or a fire
breathing Python Guru-- has a right to inject their opinion into th
community. We really need input from first time users as they carry
the very perspective that we have completely lost!

I would say "no" but that is my opinion only and it doesn't matter.
Python's domain isn't GUI programming so having it readily available on
the sidelines would be fine for me.

I agree that Python's domain is not "specifically" GUI programming
however to understand why Tkinter and IDLE exists you need to
understand what Guido's dream was in the beginning. GvR wanted to
bring Programming to everyone (just one of his many heroic goals!). He
believed (i think) that GUI programming is very important , and that
was 20 years ago!!. So he included Tkinter mainly so new Python
programmers could hack away at GUI's with little or no effort. He also
created a wonderful IDE for beginners called IDLE. His idea was
perfect, however his faith in TclTk was flawed and so we find
ourselves in the current situation we have today. With the decay of
Tkinter the dream has faded. However we can revive this dream and
truly bring Python into the 21st century!

This is a good one.

It should be:

- cross platform
- Pythonic
- as "native" as possible

Cross platform and native are hard. Just look at all the work with
PyQt/PySide and wxPython. It took them years to get where they are.

Hmm, wxPython is starting to look like the answer to all our problems.
WxPython already has an IDE so there is no need to rewrite IDLE
completely. What do we have to loose by integrating wx into the
stdlib, really?

 

[Gerry Reno]

Hmm, wxPython is starting to look like the answer to all our problems.
WxPython already has an IDE so there is no need to rewrite IDLE
completely. What do we have to loose by integrating wx into the
stdlib, really?

In the spirit of "batteries included", Python needs to have "something"
in the stdlib as far as gui. But it cannot be overwhelming.

The problem with wx is that it is BIG. And so if we want something like
wx to be in the stdlib then it would have to be refactored so that there
was a small basic wx that was part of stdlib and then import
wx-the-whole-enchilada if you need heavy gui artillery.

 

[Robert]

What is your opinion (or anyone) on wxPython?

Ok, I am curious again. Have you even tried wxPython or PySide/PyQt?

 

[Robert]

In the spirit of "batteries included", Python needs to have "something"
in the stdlib as far as gui. But it cannot be overwhelming.

The problem with wx is that it is BIG. And so if we want something like
wx to be in the stdlib then it would have to be refactored so that there
was a small basic wx that was part of stdlib and then import
wx-the-whole-enchilada if you need heavy gui artillery.

It's BIG.

The question really is, do we need a GUI toolkit in the stdlib. I would
say "no". In wxPython's case it is a no-brainer to install (even as a
second package). I am not sure if PySide is "that easy" but it could be.