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

[Arndt Roger Schneider]

From: "Arndt Roger Schneider" <[email protected]>

At least keep the disclaimer:

This is the most important thing, because most users use Windows. Those
who have other preferences are not forced to choose Windows, so it's
their choice, and if the interface doesn't look so nice, that's it.

See disclaimer.
Since you mentioned "nice": I do not use such words
to charcterize a gui. I think the developers of said software
tried hard to make it "nice" and "beauty", hence the brushed
background and group-boxes --BTW: the windows Guidelines also
discourage using group-boxes for usability reasons (see Theo. Mandel
object oriented user interfaces).

Python is an open source software and the programmers that use Python
might also prefer to offer open source software for free so this is not
important. And "not legal" is not a very correct term, because somebody
from Iran or North Corea must respect the laws from his/her country and
in her/his country some things might not be forbidden by law, so it may
be perfectly legal.

Nice cropping,

>pieces from named computer companies

Illict as in unlicensed. Law has nothing to do with it.
And yes these unlicensed sofware has an negative
impact on the distribution of free open source software.

I wonder, what license do you use in your own work,
and what do you think about people which violate your license?

This is a bad comparison because the programs targetted to the mobile
phones are in most cases very different than the programs that need to
be used on the desktop.

This is the marketplace for all gui applications,
and not a comparision.

Do you want to say that WxPython is not good just because it doesn't
work well on mobile phones?

I do not comment on the quality of either wxWidgets
nor wxPython. Both exist for certain reasons.
The desktop pc was the sole target for all the
big C++ gui class liraries in 1992. Over time a large code
base evolved which makes it very difficult to get these class
libraries into new
markets--such as today with mobile devices.

Those numbers show that only the mobile phones are important, because
there are more mobile phones than computers.

No, it doesn't. There are billions of mobile phones with
graphical user interfaces, still these phones weren't
relevant for gui applications.

Well, Python needs a better GUI lib for using them on desktop computers,
not on mobile phones.

wxWidgets is suiteable for the desktop.

What do you mean by declining? Are there fewer desktop PCs today than a
year ago?

I am writing about graphical applications not computers.

Who says that they are obsolete?
A good GUI interface should offer keyboard accessibility. Otherwise it
is broken.

OK, I take keyboard focus back.

Yes, Python should promote a good GUI lib for desktop computers, and not
a poor GUI lib for desktop computers that might also work on other
platforms.



Why do you think that everything what's modern is better?

"I belive in the horse", Kaiser Wilhelm II
-roger

 

[rantingrick]

Summary wxWidgets:
wxWidgets is large scale C++ library from the 20th century,
solemnly dedicated toward desktop computers.
wxWidgets originates from a time before templates
were used in C++ and thus duplicates many of
today's C++ features.
wxWidgets is not suitable for a modern type
GUI ad thus clearly not the toolkit/framework
of the 21st century.

Alight i'll except that Rodger. Wx may be unusable for the mobile
market. And since the mobile market is exploding --and will continue
to explode-- then we need to consider this. However, does any GUI
library exist that can handle desktop, mobile, and accessibility and
do it all in a 21st century way? You slaughtered wx but failed to
provide any alternative, however i am listing to your advice contently
because it is very good advice. Read on...

We DO need to consider the mobile market in this decision. Maybe it is
time for us to actually get on the cutting edge of GUI's. Maybe we
should head an effort to create a REAL 21st century GUI that can
handle desktop, mobile, and accessibility, and do it all whilst
looking very sharp! Sure we rob from peter to pay paul. We will use
Tkinters awesome API and geometry managers, wxPythons feature
richness, and any other code we can steal to make this work!

Then we can "advertise" python as the best GUI language available. I
have nothing against seeing Python on more devices and this would no
doubt bring that dream into fruition. There is a huge hole in the
market at this very moment and we need to pounce on it like a hungry
tiger on wildebeest. Just think how wonderful it would be to switch
from mobile to desktop and still write beatiful Python code.

 

[Arndt Roger Schneider]

Alight i'll except that Rodger. Wx may be unusable for the mobile
market. And since the mobile market is exploding --and will continue
to explode-- then we need to consider this. However, does any GUI
library exist that can handle desktop, mobile, and accessibility and
do it all in a 21st century way? You slaughtered wx but failed to
provide any alternative, however i am listing to your advice contently
because it is very good advice. Read on...

Thanks! Again this is not about the quality of wxWidgets,
wxWidgets grew large because there was vested interest in it.
Its success is its undoing.

We DO need to consider the mobile market in this decision. Maybe it is
time for us to actually get on the cutting edge of GUI's. Maybe we
should head an effort to create a REAL 21st century GUI that can
handle desktop, mobile, and accessibility, and do it all whilst
looking very sharp! Sure we rob from peter to pay paul. We will use
Tkinters awesome API and geometry managers, wxPythons feature
richness, and any other code we can steal to make this work!

I am not sure whether this sarcasms or for real...,
so I'll take for genuine.

Tk is also doomed, and Tkinter isn't Tk.
You are right about keeping the separate geometry
managers, though.

For starters:
http://kenai.com/projects/swank

Swank publishes java/swing classes as tk
in jtcl, which is similar to what tkinter does for
python and tk.

It should be feasible to use swank with the
tkinter interface for jpython--without jtcl.
However, this doesn't make tkinter mobile,
neither is swing available on android.
When you look into the android developer
documents concerning the gui, then you can see
that the gui model is quite similar to tk.
So I suppose android can be reached by jpython
in a two stage process.

The other devices are more difficult to reach, though.
There is webkit on some, but not all. Webkit
is available for the desktop, ios and android--today without svg.

There are two ways to gain graphical independence:
First a basic implementation for each platform and
second through abstraction.

With abstraction I mean to base the gui on a common graphical
model present on all platforms and hence to implement the
"toolkit" on-top of it in python (not C, C++, java,javascript), python!
The single common graphical model is SVG.

Then we can "advertise" python as the best GUI language available. I
have nothing against seeing Python on more devices and this would no
doubt bring that dream into fruition. There is a huge hole in the
market at this very moment and we need to pounce on it like a hungry
tiger on wildebeest. Just think how wonderful it would be to switch
from mobile to desktop and still write beatiful Python code.

So be it.
-roger

 

[Adam Skutt]

Back to rantingrick 21st century toolkit/framwork:
Let's have a look at the numbers:
Worlwide pc market are 300 Million pcs per year,
this number includes desktops(2/3) and servers(1/3).
Your gui app is not relevant on servers.

You should tell this "fact" to just about every major enterprise
software manufacturer out there. They all ship GUI tools intended to
be used on the server. Some of them ship only GUI tools or CLI tools
that are worthless, making you use the GUI tools.

The desktop pc market is in decline; there is
however a shift toward pc-servers, instead.
It is anybodies guess how far the pc-desktop decline will go.
Every 21st century toolkit or framework must run on
mobile platforms!

Until we have pixel-perfect touch sensors, toolkits for devices with
pointer interfaces (e.g., PCs) and toolkits for devices with touch
interfaces (e.g., phones and tablets) will necessarily be different.

You note this yourself: the UI paradigms that work well when you have
a pixel-perfect pointer do not work at all when you have a touch
screen, especially on a limited size and resolution display.

Even if you're provided a "single" toolkit, you still end up with two,
maybe three, different applications, each using different widgets
targeted for the device they run on. And no one provides a "single"
toolkit: while Silverlight can run on the desktop, the web, and now on
Windows Phone, you can't use the same widgets everywhere; ditto with
Cocoa for OS X and Cocoa Touch for iTouch devices.

While some further unification is obviously possible, it's rather
doubtful we'll ever have unified widgets that are truly workable on
the web, on the "desktop", and on a portable touch screen device.

wxWidgets was written ~1992, it is a copy of
mfc, which in turn is a copy of MacApp. MacApp
is also OSS, maintained through an industrie consortium.
Why do you not use the original framework?

Because it's not cross-platform, I'd imagine. The entire point of
wxWidgets was to provide a cross-platform "OOP" UI toolkit. It
closely copies MFC since MFC and XView were the two "backends" it
supported.

Screen resolution:
   The time of 72ppi CRT monitors is over. A GUI
   framework/toolkit must be resolution independent,
   including all icons and indicators;
   it should use decluttering (newspeak:ZUI).

WPF is the only functional resolution-independent UI toolkit in
existence. While I don't disagree with you in principal, practice is
pretty heavily divorced from principal here. Principal doesn't help
me write GUI applications today.

wxWidgets is not suitable for a modern type
GUI ad thus clearly not the toolkit/framework
of the 21st century.

None of the toolkits accessible from CPython are suitable for a 21st
century guy by your standard. If we talk about IronPython,
Silverlight becomes the closest, but it isn't a panacea by any stretch
of the imagination.

Adam

 

[Alexander Kapps]

>
> No, they should not be removed because they don't cause any damage,
> very bad damage as Tkinter does.

Tkinter causes damage? Very bad damage? What are you talking about?

>
> Well, in that case, why don't you agree to also include WxPython in
> the Python package?

Well, I don't like wx that much and others have already highlighted
some of the problems with it. I think that adding redundancy is bad
and I really want a GUI toolkit that makes it easy to quickly write
a simple GUI, so I do not want wx to replace Tkinter. But yes, I
wouldn't mind the inclusion of a large GUI package.

>
> Why do you call it "html junk"?

You said a GUI lib is useless because not all programmers write
GUIs. so I say an HTML lib is useless because not all programmers
write web stuff. Got it? Both are useful and I'm absolutely against
any attempt to remove either from the stdlib. *That* would cause damage.

>
> Yes it can be useful for some people, but why promote it instead of
> promoting a better library for beginners?

Which one? That's the whole point. There currently is no better GUI
lib than Tkinter which allows quick and easy GUI programming and
still has a large widget set, is pythonic and so on. PyGUI might be
in the future. If you care that much go on and help making it happen.

I have absolutely no problem with a better GUI lib, I just don't
care much and those who seem to care enough to start a war over and
over again seem to be unwilling to really do anything.

 

[rantingrick]

I am not sure whether this sarcasms or for real...,
so I'll take for genuine.

No this is real, albeit a bit fantastical. Thats probably why you
thought it was sarcasm .

However, we need to start a revolution in the GUI world. Currently we
(as developers) are slaves to the OEM's and OS's. This must change. We
must unify GUI coding the same way OpenGL unified graphics coding.
Multiplicity is ruining any and all advancements in Graphical User
Interfaces. Sure multiplicity is great in emerging systems (language,
culture, GUI, etc, etc) However at some point you must reign in this
multiplicity and harness the collective knowledge into an all
encompassing standard. OpenGUI is that standard. It should be shipped
with every OS in the world. This is the only way we can have mobile,
desktop, and accessibility all combined into one beautiful package.
Then the contest come down to who can create the best abstraction API.

Tk is also doomed, and Tkinter isn't Tk.
You are right about keeping the separate geometry
managers, though.

For starters:http://kenai.com/projects/swank

This looks like a very young project (beta) and i could not find a
widget set. However i will investigate more. Thanks

However we need to think beyond even a Python community scale. This
problem is inherent in every language community out there. We to unify
the GUI standard. And we are a decade behind in development. (yes i am
completely serious about all of this!).

 

[rantingrick]

Until we have pixel-perfect touch sensors, toolkits for devices with
pointer interfaces (e.g., PCs) and toolkits for devices with touch
interfaces (e.g., phones and tablets) will necessarily be different.

You note this yourself: the UI paradigms that work well when you have
a pixel-perfect pointer do not work at all when you have a touch
screen, especially on a limited size and resolution display.

Even if you're provided a "single" toolkit, you still end up with two,
maybe three, different applications, each using different widgets
targeted for the device they run on.  And no one provides a "single"
toolkit: while Silverlight can run on the desktop, the web, and now on
Windows Phone, you can't use the same widgets everywhere; ditto with
Cocoa for OS X and Cocoa Touch for iTouch devices.

While some further unification is obviously possible, it's rather
doubtful we'll ever have unified widgets that are truly workable on
the web, on the "desktop", and on a portable touch screen device.

Adam now you are making sense. Everything you said here is true. This
is why we must push for the OpenGUI standard. The entropy in GUIs has
exploded exponentially and rendered them all useless. We must unify
the collective knowledge base into a single system and shake up the
GUI world from top to bottom. Any other effort is just wasted energy.
Forget WxPython, Forget WxWidgets, Forget any and all GUI libraries
that exists, they are all moot at this point and we are -years-
DECADES behind in development and integration.

See my reply to Rodger for more detail..

 

[jmfauth]

No wxWidgets, but real Python / wxPython applications, all updated on
Windows 7.

http://spinecho.ze.cx/

 

[Mark Roseman]

If you guys spent 1/10th as much time articulating the problems you see
with Tkinter (and being willing to listen when people offer solutions)
as you do trying to convince everyone else you're right, you'd probably
have ... well, anyway, no sense in being practical.

 

[rantingrick]

If you guys spent 1/10th as much time articulating the problems you see
with Tkinter (and being willing to listen when people offer solutions)
as you do trying to convince everyone else you're right, you'd probably
have ... well, anyway, no sense in being practical.

Well mark why don't you offer some facts on the merits of Tkinter
versus WxPython (or libray X) instead of just contributing nothing.
Heck you did not even interject an opinion? This is just argumentative
speech Mark, i would really like some soild input from you since you
(like myself) are neck deep in Tkinter code.

 

[Arndt Roger Schneider]

No this is real, albeit a bit fantastical. Thats probably why you
thought it was sarcasm .

However, we need to start a revolution in the GUI world. Currently we
(as developers) are slaves to the OEM's and OS's. This must change. We
must unify GUI coding the same way OpenGL unified graphics coding.
Multiplicity is ruining any and all advancements in Graphical User
Interfaces. Sure multiplicity is great in emerging systems (language,
culture, GUI, etc, etc) However at some point you must reign in this
multiplicity and harness the collective knowledge into an all
encompassing standard. OpenGUI is that standard. It should be shipped
with every OS in the world. This is the only way we can have mobile,
desktop, and accessibility all combined into one beautiful package.
Then the contest come down to who can create the best abstraction API.

There has been no advancement in GUI-Design. Today it looks and
behaves just the way Bill Atkinson designed it.
Technical revolutions are made by disruptive thoughts,
which are never collective.
....The problem with gui-design:It requires an graphical artist,
a well versed writer, a software architect and a programmer.
The first two job description are the important ones.

....No OS-vender is going to allow that, it equals
lost control.

This looks like a very young project (beta) and i could not find a
widget set. However i will investigate more. Thanks

alpha

However we need to think beyond even a Python community scale. This
problem is inherent in every language community out there. We to unify
the GUI standard. And we are a decade behind in development. (yes i am
completely serious about all of this!).

Then we did find common ground.
-roger

 

[Octavian Rasnita]

Tkinter causes damage? Very bad damage? What are you talking about?

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.

Those applications won't be less nice, or just a little harder to use. They won't be accessible at all and they will help the discrimination of the blind people, and not because of technical problems, because those problems can be solved with a better interface like Wx, which is not perfectly accessible either, but it is much better. That discrimination appears just because some people say that they don't care.

Well, I don't like wx that much and others have already highlighted
some of the problems with it. I think that adding redundancy is bad

It is a redundancy for you, but have you imagined that for some people the display is the redundant part of the computer?

You said a GUI lib is useless because not all programmers write
GUIs. so I say an HTML lib is useless because not all programmers
write web stuff. Got it? Both are useful and I'm absolutely against
any attempt to remove either from the stdlib. *That* would cause damage.

I didn't say that a GUI lib is useless. The GUIS that create discrimination by offering access only for some users (when there are other GUIS that can offer access to everyone) create damage and they should be avoided, and for avoiding them, the beginners need to understand this. But Python promotes that bad GUI lib by including it in the default package instead of promoting a better lib.

Which one? That's the whole point. There currently is no better GUI
lib than Tkinter which allows quick and easy GUI programming and

Are you a beginner? A good programmer is not interested only to create an application with 10 lines of code, no matter the results.
The application need to have a good quality and to be accessible by everyone if the technology allows it.
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).

I have absolutely no problem with a better GUI lib, I just don't care

Well, I was sure that you are one of those who don't care...

Octavian

 

[Octavian Rasnita]

If you guys spent 1/10th as much time articulating the problems you see
with Tkinter (and being willing to listen when people offer solutions)
as you do trying to convince everyone else you're right, you'd probably
have ... well, anyway, no sense in being practical.

The problem: The beginners use the first GUI lib they find in the default Python package and they learn how to create applications which are not accessible for screen readers (at all), while there are better solutions.

Is there any other solution for the problem that Python promotes this bad GUI than removing it from the default package?

Not only Python does this. For the reason that "it is more simple and we don't care about the problems it generates", ActiveState does the same and it does the same with ActivePerl, but it doesn't mean that it is something good.

Octavian

 

[Adam Skutt]

Adam now you are making sense. Everything you said here is true.

This
is why we must push for the OpenGUI standard.

Funny, I write considerable detail about why such a thing is a
pipedream and useless even if it came to fruition, and you somehow
believe I'm in support of such an absurd idea. If you believe what I
said is true, then you cannot seriously support any sort of "OpenGUI"
standard, and I advise you to google that term before you use it
again. Tell me, are you a political science major?

Heck, to be totally honest, I've never been 100% convinced that cross-
platform GUI APIs were even such a good idea. I certainly use them,
but only in situations that are very simple or where I'm OK with
accepting the fact my application will not be truly a first-class
application[1][2]. Even minor differences in presentation can have
large ramifications on how applications should function and therefore
be written.

The entropy in GUIs has
exploded exponentially and rendered them all useless.

Only if you have no clue what you're talking about whatsoever. You
perceive them as useless because you're apparently incapable of
understanding the simplest GUI precepts, nevermind APIs, which is why
you've gone from Pure Python GUI to wxWidgets to this OpenGUI bullshit
you're now espousing. Desperately clinging to a position doesn't make
you look intelligent.

Plus, I'm not sure what entropy you're talking about, but I'm not
seeing it. MS continues to innovate, Apple continues to innovate,
some portions of the Linux community do innovative things. Though
most people just want to put something together and call it a day, and
the functionality provided by a lot of toolkits is beyond adequate for
that.

Adam

[1] Or solely on Linux where all of the "native" toolkits have cross-
platform support.
[2] To say nothing about the explosion of web "applications" in the
world today...

 

[Adam Skutt]

There has been no advancement in GUI-Design. Today it looks and
behaves just the way Bill Atkinson designed it.

That doesn't even begin to equate to a lack of advancement. It's also
not true in the least.

Technical revolutions are made by disruptive thoughts,
which are never collective.

Revolutions are statistical anomalies, so it's best not to depend on
them for progress. It's not even apparent what revolution is
necessary here.

...The problem with gui-design:It requires an graphical artist,
a well versed writer, a software architect and a programmer.
The first two job description are the important ones.

...No OS-vender is going to allow that, it equals
lost control.

You need to go look at the people Apple, MS, Google, et al. hire; this
statement is just patently false too. Plus, after a certainly level
of functionality, the OS vendor does become rather irrelevant.
Otherwise, the web would have never taken off an application platform:
the HTML standard provides the smallest widget set of just about
anything discussed,
though it's painting / layout capabilities are both simultaneously far
advanced and far worse. Yet, it is likely the way of the future for a
large portion of us, like it or not.

Adam

 

[Alexander Kapps]

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.

Those applications won't be less nice, or just a little harder to use. They won't be accessible at all and they will help the discrimination of the blind people, and not because of technical problems, because those problems can be solved with a better interface like Wx, which is not perfectly accessible either, but it is much better. That discrimination appears just because some people say that they don't care.


It is a redundancy for you, but have you imagined that for some people the display is the redundant part of the computer?

I was talking about redundancy as in duplication of already existing
parts. However, for some people, networking is superfluous. That's
not a reason to remove the networking modules from the stdlib.

Anyway, If you think duplicating functionality is a good approach
here, go on, I don't mind. Just remember to stop somewhen and don't
include 10 GUI toolkits and 20 HTML parsers just because some people
don't like the already existing ones.

I didn't say that a GUI lib is useless. The GUIS that create discrimination by offering access only for some users (when there are other GUIS that can offer access to everyone) create damage and they should be avoided, and for avoiding them, the beginners need to understand this. But Python promotes that bad GUI lib by including it in the default package instead of promoting a better lib.

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

Are you a beginner? A good programmer is not interested only to create an application with 10 lines of code, no matter the results.

I'm neither a beginner, nor really a professional programmer. I
occasionally do paid coding and that often includes small tools and
helper utilities and one thing I can tell you: In approx 90% of
those cases, people want a GUI. It hasn't to be fancy, they just
don't want no command line tools.

Tkinter is just great for quickly hacking together a GUI or for
prototyping if somebody wants something more advanced.

The application need to have a good quality and to be accessible by everyone if the technology allows it.
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).


Well, I was sure that you are one of those who don't care...

You make that sound as if I should feel guilty now.

 

[Arndt Roger Schneider]

You should tell this "fact" to just about every major enterprise
software manufacturer out there. They all ship GUI tools intended to
be used on the server. Some of them ship only GUI tools or CLI tools
that are worthless, making you use the GUI tools.




Until we have pixel-perfect touch sensors, toolkits for devices with
pointer interfaces (e.g., PCs) and toolkits for devices with touch
interfaces (e.g., phones and tablets) will necessarily be different.

You note this yourself: the UI paradigms that work well when you have
a pixel-perfect pointer do not work at all when you have a touch
screen, especially on a limited size and resolution display.

Yes I did and that's how it is.

Even if you're provided a "single" toolkit, you still end up with two,
maybe three, different applications, each using different widgets
targeted for the device they run on. And no one provides a "single"
toolkit: while Silverlight can run on the desktop, the web, and now on
Windows Phone, you can't use the same widgets everywhere; ditto with
Cocoa for OS X and Cocoa Touch for iTouch devices.

While some further unification is obviously possible, it's rather
doubtful we'll ever have unified widgets that are truly workable on
the web, on the "desktop", and on a portable touch screen device.

Think about all the programmers earning their butter and bread .
Forget toolkits and widgets for awhile.
What remains are specific types of human/computer interactions,
a visual representation on a screen and a predefined behaviour
for said human action.

E.g. a button is:
A function gets asychnronously performed in response to
a finger/mouse click and release inside a certain screen area.

--A widget is essentially a logical abstraction.

Because it's not cross-platform, I'd imagine. The entire point of
wxWidgets was to provide a cross-platform "OOP" UI toolkit. It
closely copies MFC since MFC and XView were the two "backends" it
supported.

MacApp is/was cross-platform, Apple pulled the plug
on the non-mac platforms; the industrie
consortium took charge of the other platforms.

WPF is the only functional resolution-independent UI toolkit in
existence. While I don't disagree with you in principal, practice is
pretty heavily divorced from principal here. Principal doesn't help
me write GUI applications today.




None of the toolkits accessible from CPython are suitable for a 21st
century guy by your standard. If we talk about IronPython,
Silverlight becomes the closest, but it isn't a panacea by any stretch
of the imagination.

Adam

According to Microsoft neither is silverlight.
-roger

 

[Terry Reedy]

I am talking about the fact that Python promotes Tkinter

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.

TK are not accessible for screen readers,

I did not know that. You could ask on the tracker that that fact be
added to the docs. I would consider it reason to consider another choice
if there ever were to be a suitable one offered.

I agree. Besides IDLE and turtle, there are tools in the Tools directory
that depend on tkinter.

 

[Terry Reedy]

No wxWidgets, but real Python / wxPython applications, all updated on
Windows 7.

http://spinecho.ze.cx/

Yes wxWidgets, underneath wxPython. And yes, look very nice.

 

[Terry Reedy]

Is there any other solution for the problem that Python promotes this
bad GUI than removing it from the default package?

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.

Not only Python does this. For the reason that "it is more simple and
we don't care about the problems it generates", ActiveState does the
same and it does the same with ActivePerl, but it doesn't mean that
it is something good.

So persuade them or someone to make it better, or is ActiveState
actively opposed to that?