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

[Steven D'Aprano]

The
second way the Tcl community irks me is the "not invented here"
attitude. I like the syntax of Tcl and I like the community. They are
some good folks. Try asking "I want to build a Nagios clone in Tcl" type
question and invariably you get "Why? There is already Nagios?".

You're the one who wants to re-write Nagios in Tcl, the Tcl community are
perfectly happy using the existing Nagios instead of re-inventing the
wheel, and you accuse *them* of suffering from NIH syndrome.

Oh the irony.

 

[rantingrick]

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

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.

Exactly! All we need to do is replace the existing Tkinter with a
small sub-set of wxPython widgets that mirrors exactly what we have
now...

Toplevel
Label
Entry
Button
Radiobutton
Checkbutton
Canvas
Textbox
Listbox
Menu
Scale
Scrollbar

....thats all you need in the std library "widget wise". The rest of
what makes up wx can exist in the "wxPython Extension Library".
Python needs this change! We have already made incompatible changes so
now is the time to start seriously brainstorming on how we can
integrate the beauty, elegance, and feature rich power of wxPython.

 

[rantingrick]

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

Yes i have used wxPython on a few projects and was very happy with the
feature rich nature of it. I found previously (with Tkinter) i would
have to build my own compound widgets due to non-existence or just
plain poor design. That was not the case in wx as it has more eye
candy than i could ever put to good use

 

[Adam Skutt]

Exactly! All we need to do is replace the existing Tkinter with a
small sub-set of wxPython widgets that mirrors exactly what we have
now...

Toplevel
Label
Entry
Button
Radiobutton
Checkbutton
Canvas
Textbox
Listbox
Menu
Scale
Scrollbar

...thats all you need in the std library "widget wise". The rest of
what makes up wx can exist in the  "wxPython Extension Library".
Python needs this change! We have already made incompatible changes so
now is the time to start seriously brainstorming on how we can
integrate the beauty, elegance, and feature rich power of wxPython.

I have never, ever, made a GUI that consistent only of those options
excep when following a tutorial, sorry. While I won't claim to stand
for anyone else, I'm hardly alone, judging by /every application
running on my desktop right now/. Well, maybe notepad.

Interesting applications require interesting features. Anything you
end up writing is going to be at least as complicated as TkInter for
the standard library, if not vastly more so, and have all of the same
faults you find in TkInter. This would be because such problems are
fundamentally inescapable, a simple fact of reality you have yet to
even grasp, AFAICT, much yet acknowledge.

Adam

 

[rantingrick]

wxPython is really good. The downside is that is shows (or did show)
its C++ roots.

Well i will admit the api is not as simplistic as Tkinter. However i
noticed over time that wx had started adopting a slight Tkinter "feel"
to the API and that is a good thing. So they are coming around.

Anyway, I wasn't meaning to be rough with you. Just trying to figure
out where you were coming from. I am acquianted with Kevin Walzer and
he is a good guy.

No harm done Robert my skin is far thicker than your average grape. We
just ended up on opposite sides of a passionate argument. I hope you
stick around with us because I look forward to hearing more of your
opinions and ideas. And i agree that Kevin is a great guy! I've never
met him but i can tell from his writing style and mannerisms that he
is truly an honest and virtuous soul. And i totally understand why he
wants to keep Tkinter alive as he and i both have tons of code that
depends on Tkinter.

I wish we could keep Tkinter forever as it really is a great starter
GUI. I wrote my first GUI code with it and fell in love just like with
Python! However i know we will always be lacking our full potential
with Tkinter as developers and as a community. Sadly i see no other
way but to replace it with something more up-to-date. Sometimes we
have to "take one for the team". What is in our best interest may not
necessarily be in the community's best interest. If we *do* replace
Tkinter, it will be a very painful adjustment because it has been with
us for such a long time. However, just as Py3000 was painful at first,
and then started slowly gaining speed into a much better language, i
also believe this change will move us forward into an even greater
language.

 

[rantingrick]

I have never, ever, made a GUI that consistent only of those options
excep when following a tutorial, sorry.  While I won't claim to stand
for anyone else, I'm hardly alone, judging by /every application
running on my desktop right now/.  Well, maybe notepad.

Of course a tiny widget set like this is not going to handle extensive
GUI coding, thats a no brainer. But currently that is EXACTLY what we
have to work with in the stdlib. Sure you have TIX and a few other
extensions but they will never compare to the vast features of
wxPython. Have you even aquinted yourself with wxPython Adam?

What i (and others) are proposing is to replace the existing Tkinter
library with a matching wxPython libray. Then allocate the remaining
wxPython library (which is ginormous btw!) into a 3rd party module
available for download. My argument is that because wxPython is soooo
feature rich. We will break the glass ceiling that exist now with
Tkinter.

Interesting applications require interesting features.  Anything you
end up writing is going to be at least as complicated as TkInter for
the standard library, if not vastly more so,

Agreed! We need at least the same capability that Tkinter offers in
the stdlib. Why would we sacrifice?

and have all of the same
faults you find in TkInter.

Thats not true. Yes all projects have faults of some kind. I am not
suggesting that wxPython is some sort of "miracle" library. However
anyone of average intelligence can do a side by side comparison and
agree that wx is far superior to TclTk in many, many ways. If you have
a valid argument as to how Tkinter is better feel free to share this
information with us.

 This would be because such problems are
fundamentally inescapable, a simple fact of reality you have yet to
even grasp, AFAICT, much yet acknowledge.

Adam, Adam. I feel you are desperately trying to inject negative
energy into what is now the very beginnings of a healthy and positive
community discussion on the future of Python's GUI library. If you do
care about Python's future then you should get involved with this
discussion in a positive way. You can disagree with me and still be
positive. I wish you would spend more energy bringing forth your own
ideas and thoughtful discussion instead of resorting to these wasteful
and vengeful tactics.

So with that in mind i ask you some direct questions...

1. Do you use Tkinter yourself?
2. Explain some of the applications you have created with Tkinter.
3. How do you feel about Tkinter being in the stdlib?
4. Should Python even include a GUI library?
5. If so, what traits should this library encompass?
6. If you could choose what library do you think would be in the
communities best interest?

 

[Owen Jacobson]

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!

One: it's "delusions" of grandeur.

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.

Two: were you raised in a barn? How the hell did you get so up on
yourself that you think this is an okay way to respond to a perfectly
civil post? Abusing people's opinions and soldiering around demanding
everyone justify themselves to you is a great way to get people to
ignore whatever point you were trying to make.

From your other posts, I gather that you have a very clear idea of what
your ideal Python GUI framework would look like. That puts you in the
best possible position to implement it. If you're successful, share it
around; if it's good, it will gain traction on its own merit. You're
not earning any traction on rhetorical grounds here.

-o

 

[Owen Jacobson]

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.

My two cents, given freely: I'd rather have better integration with
each platform's GUI libraries and desktop services than one
cross-platform GUI library. There are so many fundamental differences
in accepted behaviour between each of the major GUI platforms (Gnome,
KDE, Mac OS, and Windows, at minimum; you could include Blackberry,
iOS, and Android in here as well, if you wanted something really
different) that being able to put the same window with the same widgets
on all of them is of limited value.

Consider Java's Swing toolkit - a passable cross-platform GUI library,
whether you like its API or not. Swing apps almost *never* feel as
pleasant to use as a native application, even on modern JVMs where
performance isn't the problem and even using the native look & feel.
Little things like keyboard shortcut conventions, mouse button
conventions, and menu organization guidelines don't quite mesh. Then
there are more complex issues, like process management, library
packaging, software updates, and user notification, where the
conventions on each platform differ more dramatically.

Python's native UI capabilities, on the other hand, give programmers
the tools they need to write the core of their application using
portable code while being able to write a UI (or UIs) that actually
takes advantage of the underlying platform's features and that plays
nicely with the underlying platform's conventions and interfaces - all
without switching languages. I don't see having to maintain two or
three UI codebases as being that much worse than riddling a single UI
codebase with conditionals or extension points for handling each
platform's idiosyncracies.

Fortunately for me and my opinions, Python is already shaped like that.
PyObjC provides bindings for writing OS X applications; PyGTK and PyQt
support Gnome and KDE respectively (as well as any other X11 desktop);
PyWin32 provides passable support for Windows UIs, or you can use
IronPython and .Net's GUI APIs. It is absolutely zero skin off of my
nose if someone decides I'm utterly out of my tree, figures out that
cross-platform GUIs are the future, and goes on to write an amazing
pure-Python GUI stack that works everywhere with a colour monitor.

Cheers,

-o

 

[python]

Rick,

However, now Tkinter just looks old and dumpy.

Have you taken a look at the ttk module (based on tile) that ships with
Python 2.7/3.1? This adds native/theme-aware widgets to Tkinter. And it
adds additional widgets such as a treeview (which can also be used as a
grid), notebook, progressbar, scales, panedwindow (splitters), etc.

The widgets in ttk match each platform's standards and look as
professional as the equivalents found in wxPython/pyQt. Take a look at
the screenshots on this rather long page to get an idea of what is now
possible - "out-of-box" with Python 2.7/3.1.
http://www.tkdocs.com/tutorial/onepage.html

I've done GUI development in wxPython and pyQt, and until recently
*never* considered Tkinter. Once I saw what was possible with the ttk
module, I've started moving a lot of new GUI projects from these other
platforms back to Tkinter/ttk (enhanced with PIL module).

Why Tkinter/ttk vs. wxPython or pyQt
- professional looking apps are now possible (really!)
- very light weight install and distribution
- works with both 2.x/3.x (not possible with wx)
- very robust (wx can be finicky at times)

Subjective: I also prefer Tk's geometry managers to wx's sizers even
though I learned sizers first.

You seem to be very enamored with wxPython. What have you found in
wxPython that's not available with the latest versions of Tkinter/ttk
other than an AUI equivalent and better support for RTL languages?

Malcolm

 

[flebber]

I speak up.  







I don't think Tkinter was in there for "large" programming. Tkinter is
crufty and probably should be moved out. For whipping up quick gui
things to scratch an itch it is good.

I lurk more on the Tcl side of things. When the mention of "separating"
Tcl and Tk development, I fall on the side of separating them. Tcl,
like Python should stand on its own. Widget frameworks are extras to
me. One way the Tcl community has "stagnated" has been its insistence
on Tk. There was a wxTcl project...it died. That would have been good
for the Tcl community. Luckily there is a GTk framework (Gnocl) that is
really good. But it still doesn't get the props that it deserves. The
second way the Tcl community irks me is the "not invented here"
attitude. I like the syntax of Tcl and I like the community. They are
some good folks. Try asking "I want to build a Nagios clone in Tcl"
type question and invariably you get "Why? There is already Nagios?".
That stems from the "glue" language roots I think but to me that is the
wrong attitude. You want people to take a look at a language (any
language), you build stuff with it that people want to use. Ruby would
not be as big as it is if Rails hadn't come along.

Nuff of that...  ;-)







wxPython is really good. The downside is that is shows (or did show)
its C++ roots.

Nokia is making a run with PySide (their version of the PyQt framework)
and since it has a company behind it might go pretty far. Qt can be
used for a lot of problem domains.

Anyway, I wasn't meaning to be rough with you. Just trying to figure
out where you were coming from. I am acquianted with Kevin Walzer and
he is a good guy.

I thank this thread for putting me onto Pyside +1

 

[Adam Skutt]

Of course a tiny widget set like this is not going to handle extensive
GUI coding, thats a no brainer.

No, it's not going to handle any GUI coding except notepad.exe.
That's already been written, so we're left with no new application
that can be written with this proposed minimal widget set. Why do you
think Tix exists? Why do you think there are Python bindings for it
in the standard library (to say nothing of a bunch of other additional
Tk controls)?

But currently that is EXACTLY what we
have to work with in the stdlib. Sure you have TIX and a few other
extensions but they will never compare to the vast features of
wxPython. Have you even aquinted yourself with wxPython Adam?

It is nothing of the sort even if you erroneously believe it is. Have
you looked at Tix? The fact you dismiss it away as some "extension"
like it is a leper really betrays your argument. Others (not you)
have already described the legitimate deficiencies at length, I will
defer to them.

 What i (and others) are proposing is to replace the existing Tkinter
library with a matching wxPython libray. Then allocate the remaining
wxPython library (which is ginormous btw!) into a 3rd party module
available for download. My argument is that because wxPython is soooo
feature rich. We will break the glass ceiling that exist now with
Tkinter.

And what I pointed out is that wxWidgets (and Qt, and Swing, and Tk+Tix
+whatever, and every other GUI toolkit in existence) is so feature
rich for a reason: you actually need all of that stuff in order to
build rich, functional, useful GUI applications. I think you'll find
that it's very hard to cut any functionality, even functionality
Python more or less entirely replicates (e.g., wxNet, wxODBC). Why?
Because useful widgets rely on such low-level functionality (blame C+
+'s rather anemic standard library).

Moreover, even if you find things to cut, coming to a consensus about
what belongs outside of the stdlib will be difficult, if not
impossible; plus, it's considerable work for very little gain: I still
need a full install of wxwidgets to even build your useless minimal
set. There's definitely no point in minimizing the python side of
things if it doesn't minimize the native code side of things. Note
how the divisions with the Tk bindings follow the divisions of the
native libraries.

Agreed! We need at least the same capability that Tkinter offers in
the stdlib. Why would we sacrifice?

I don't know, but a sacrifice is precisely what you proposed.

Thats not true. Yes all projects have faults of some kind. I am not
suggesting that wxPython is some sort of "miracle" library. However
anyone of average intelligence can do a side by side comparison and
agree that wx is far superior to TclTk in many, many ways. If you have
a valid argument as to how Tkinter is better feel free to share this
information with us.

From this claim I've forced to conclude you are not of average
intelligence, because you haven't managed yet to do an actual, factual
side-by-side comparison of wxWidgets and Tk. Here is one to start: the
native footprint of Tk has fewer dependencies than the native
footprint of wxWidgets.

Adam, Adam. I feel you are desperately trying to inject negative
energy into what is now the very beginnings of a healthy and positive
community discussion on the future of Python's GUI library.

There's nothing positive about this discussion, since it's being
spearheaded by arrogance and ignorance. It's highly improbable, in
fact, for this discussion to ever be healthy and positive without a
desperate attitude and behavior chance on your part.

Seriously, given that widget set you listed, what applications am I
supposed to write? I can't write a web browser. I can't write an
audio player. I can't write a terminal. I can't write an IM client.
I can't write a social media client/application/mashup. I can't write
a web browser. I can't write a game community client/launcher. I
can't write office productivity applications. So what can I write?

The fact your proposal shows you're entirely disconnected with reality
isn't my fault in the least, nor does it mean I'm "trying to inject
negative energy", nor that I'm "resorting to these wasteful and
vengeful tactics."

You want to be told your proposal isn't disconnected with reality?
Then propose ideas that actually have technical merit and that can be
actually accomplished, instead of proposing things that plainly lack
merit to anyone who's ever written a complicated GUI application
before and/or that are flat-out impossible. Calling a bad proposal a
bad proposal is a positive thing, like it or not. If you can't accept
that, you should consider a pastime that involves less criticism.

If you do care about Python's future then you should get involved with this
discussion in a positive way.

I have, I told you what you want to do isn't possible. The fact you
don't want to nor like to hear that doesn't mean it is not positive.
A pure Python GUI toolkit isn't really possible. Even if we agreed
that "pure" means something akin to AWT, it's still a really awful
idea (again, for really obvious reasons). Building something like WPF
would be worthwhile, but won't free you from needing a traditional GUI
library for quite some time, so you're still right back where we
started.

Replacing TkInter with some sort of minimized wxwidgets is a dumb idea
for some very obvious reasons, reasons that are obvious if you simply
look at a widget gallery and then the applications you run on your own
computer. Quite honestly, if you're not capable of that, there's
little reason to believe you'll ever be able to bring forth a
coherent, cogent proposal.

Adam

 

[Robert]

You're the one who wants to re-write Nagios in Tcl, the Tcl community are
perfectly happy using the existing Nagios instead of re-inventing the
wheel, and you accuse *them* of suffering from NIH syndrome.

Oh the irony.

No, that was just an example! My goodness....

 

[Antoine Pitrou]

You're the one who wants to re-write Nagios in Tcl, the Tcl community are
perfectly happy using the existing Nagios instead of re-inventing the
wheel, and you accuse *them* of suffering from NIH syndrome.

Well, I don't know about Tcl but Nagios was re-written in Python:
http://www.shinken-monitoring.org/features/

Regards

Antoine.

 

[Robert]

Well, I don't know about Tcl but Nagios was re-written in Python:
http://www.shinken-monitoring.org/features/

Regards

Antoine.

It was forked to be written in Python, yes. The whole point (and it
wasn't a Nagios port to Tcl) was that the Tcl community (and I like the
Tcl community a lot) has a strange fixation with not reinventing the
wheel, even when the wheel would be in Tcl and it might give Tcl more
exposure. It is what it is though.

 

[rantingrick]

Ok, at this point i am not going to respond to the last few posts that
where directed at me. What i am going to do is to restate my
intentions at the time i started this thread.

First and foremost i want everyone to know that i have tons of GUI
code that utilizes the Tkinter module and feel very confident crating
GUI's with Tkinter. I am not some novice who tried to write up a hello
world GUI, got aggravated, and then decided to vent about it. Quite to
the contrary...

I actually like Tkinter's simplistic API. I especially love Tkinter
geometry management! However i realize that TclTk is lacking and
because of that fact we will always be at the mercy of another
community. This bothers me, and it should also bother you. Tk has a
glass ceiling that cannot be broken by you, or me, or anyone in the
Python community. If we are to have a GUI library it should be one
that is up to date and feature rich. In the latter case there may
still be a glass ceiling but it is so high they we will never notice
anyway!

However be aware that GUI's libraries are large beasts. You cannot
cram everything into the stdlib. So what should go into the stdlib
then? Well only a very limited subset of widgets. Some might say that
you will be limited with a limited subset, well i must agree with
argument . Some might also say that a glass half full is also half
empty, duh!

Everyone needs to realize that the only reason for having ANY GUI in
the Python stdlib is for ease of learning and also for "batteries
included". We just want the basics of a GUI with an extension library
available for download. There are two major advantages to this
setup...

1. The basics never change. So the Python "stdlib GUI module" becomes
a "set it and forget it" module. The Python "GUI extension library"
can change all it wants and Python remain backwards compatible.

2. By relegating the bloat to an external download the stdlib is kept
as small as possible.

.... These two talking points are the main idea behind this whole damn
discussion i initiated. We need to look beyond our own selfish needs
and think about the community first. Anyone who truly cares about
Python's stability and future will agree with these two points.

I'll repeat... TclTk has had a whole decade to become a 21st century
GUI library. I really don't think the motivation is there. Some will
argue that ttk brings in the new widgets necessary to compete with a
full featured GUI like wxPython -- and they could not be more wrong!

There is no real Tk::Grid. Sure as someone suggested you can mimic a
grid with another widget, it's just lipstick on a pig really. Go and
check out the wx::Grid with all its wonderful capabilities and then
you shall be enlightened!

This is also no real support for a true Listview widget. Again go
check out wx::ListView with all it's capabilities and ye shall be
further enlightened.

Wx is by far the best choice for Python. A small subset of wx widgets
in the stdlib and ONE (and only one!) downloadable extension library.
Yes the stdlib widgets are only going to cover the most minimal of
GUIs -- for learning purposes, utilities, or just simply toys) If you
plan to do professional GUI work than package the extension library.
It's very simple really.

Geesh! Now i know how the early scientist felt when trying to convince
the lemmings that the earth is not flat!

Flatearther said: """You heritic!. If the earth were round we would
fall off the bottom!"""

 

[Adam Skutt]

I actually like Tkinter's simplistic API. I especially love Tkinter
geometry management! However i realize that TclTk is lacking and
because of that fact we will always be at the mercy of another
community. This bothers me, and it should also bother you.

It's true of any widget library out there. It's inescapable. Python
bindings to the native widgets are still at the mercy of MS and Apple
(and GTK+ or Qt, whomever you pick for UNIX ). We've seen how much
Apple cares about 3rd-party developers, and while MS at least cares,
you never know when or how they'll implement something. Look at the
mess with the ribbon, for example. There's the Office version, an MFC/
Win32/COM version, and a WPF version. Not only do all three have
slightly different APIs, they all behave slightly differently too
w.r.t the end-user.

Even a "pure python" GUI library cannot get rid of this problem
entirely. Witness that Xlib is (slowly) being deprecated for XCB[1].
It's possible, though unlikely, that MS will eventually stop providing
new functionality through Win32 and/or make radical changes. It's
also possible, though unlikely, that Apple will eventually pull
another stunt on the level of deprecating Carbon and rip apart
Quartz. Any of those changes would require drastic implementation
changes on the part of the python GUI library.

It's inescapable, so it's generally best not to worry about it.

However be aware that GUI's libraries are large beasts. You cannot
cram everything into the stdlib.

Who says? Java does. Android does. Microsoft does. Apple does.

So what should go into the stdlib then?
Well only a very limited subset of widgets. Some might say that
you will be limited with a limited subset, well i must agree with
argument . Some might also say that a glass half full is also half
empty, duh!

No, not 'duh'. You have to explain what the utility of doing such a
thing is, as the utility is not apparent in the least. You also need
to explain how this is actually accomplished. I don't see it as a
trivial task, especially if the implementation path is to wrap
something else. What we have now is about as minimal as things are
going to get.

Everyone needs to realize that the only reason for having ANY GUI in
the Python stdlib is for ease of learning and also for "batteries
included". We just want the basics of a GUI with an extension library
available for download. There are two major advantages to this
setup...

1. The basics never change. So the Python "stdlib GUI module" becomes
a "set it and forget it" module. The Python "GUI extension library"
can change all it wants and Python remain backwards compatible.

No, I don't see how this follows in the least, especially if the
implementation path is, "wrap something else". But even in the pure
Python case, most (nearly all) GUI applications will rely on the
extension library, so it will not be able to change all it wants.

2. By relegating the bloat to an external download the stdlib is kept
as small as possible.

It's not apparent why this is desirable to me. Even if we take it as
a tautology, you need to show the value and means for splitting up a
GUI library. Your cutting may result in their being more value by not
including a GUI at all. Trivial proof: if everyone ends up needing to
download the extension library anyway, you incur no cost for anyone
and make the standard library smaller by not including any GUI
functionality.

So go on, show us a minimized, functional widget set and what we can
do with it. We're all pretty eagerly awaiting such a thing.

There is no real Tk::Grid. Sure as someone suggested you can mimic a
grid with another widget, it's just lipstick on a pig really. Go and
check out the wx::Grid with all its wonderful capabilities and then
you shall be enlightened!

TkTable seems to do everything wx::Grid[sic] can do. I didn't check
fully, as it's your claim, so your responsibility to show the
inadequacies, especially since you don't even seem to be aware of
TkTable's existence. The biggest missing feature seems to be DnD
support, AFAICT. BFD to me, since I've never actually encounterd DnD
support worth a damn ever and have always ended up doing it manually.

Wx is by far the best choice for Python. A small subset of wx widgets
in the stdlib and ONE (and only one!) downloadable extension library.
Yes the stdlib widgets are only going to cover the most minimal of
GUIs -- for learning purposes, utilities, or just simply toys) If you
plan to do professional GUI work than package the extension library.
It's very simple really.

Why split it, if you use wx[sic]? All that saves you is a few .py/.c
files in the stdlib. You still need the full wxWidgets install to
build even the "minimal set", which is pointless and stupid. The
costly part with wxWidgets is depending on the native library, not the
amount of code in the stdlib.

Again, do you think the various Tk bindings fall along library lines
just for fun, or that there just possibly might be a method to the
madness?

Geesh! Now i know how the early scientist felt when trying to convince
the lemmings that the earth is not flat!

Flatearther said: """You heritic!. If the earth were round we would
fall off the bottom!"""

You can pretend you're being persecuted all you want, but it really
only furthers the opinion that you're completely and fully
disconnected from reality. The torches you see are entirely of your
own imagination.

Adam

[1] In the case of X, you could write your own protocol library, but
then when the protocol changes...

 

[CM]

Rantingrick,

Find a closet in your home, go inside, turn off the lights, and shout
into a thermos; that will likely have a similar result as these posts
on the state of GUI libraries in Python. There is something admirable
about the FOSS philosophy of "You want it? You make it".

And I don't see this as a problem anyway. I wanted to do GUI
programming in Python, so I read a bit, chose wxPython, downloaded it,
and started learning it. Done.

 

[rantingrick]

And I don't see this as a problem anyway.  I wanted to do GUI
programming in Python, so I read a bit, chose wxPython, downloaded it,
and started learning it.  Done.

I, I, I...Me,Me,Me.

Seems you are only concerned about yourself CM. However this a
community discussion. You must put your wants and needs in the
backseat before you can see what is best for the Python community as a
whole.

 

[Tim Chase]

I, I, I...Me,Me,Me.

Seems you are only concerned about yourself CM. However this a
community discussion. You must put your wants and needs in the
backseat before you can see what is best for the Python community as a
whole.

Pot? Meet Kettle...

Given that the community response has largely been an
overwhelming "meh, show me some code" rather than an "I
whole-heartedly agree with rantingrick", your use of "we" in your
emails sounds more like a "royal we"[1] than a community-based
concern.

"best for the Python community" seems to be something that
doesn't break backwards compat. with existing code-bases, works
across a multitude of platforms, has a minimal install footprint,
and a proven track-record of meeting those needs. Tkinter and wx
both seem to satisfy most of those requirements, except that wx
seems to have a larger footprint and not have been
production-ready at the time a decision needed to be made for
inclusion of a gui-library in Python. (I also don't know if
there are licensing concerns with wx vs. tk and their interplay
with the Python license).

-tkc


[1]
http://en.wikipedia.org/wiki/Royal_we

 

[CM]

I, I, I...Me,Me,Me.

Seems you are only concerned about yourself CM. However this a
community discussion. You must put your wants and needs in the
backseat before you can see what is best for the Python community as a
whole.

Must have been too many holiday baked goods that made me even try...