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

[geremy condra]

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

Seriously, get off of WoW and go write some code. If you'd spent the
last year programming instead of doing your best Xah Lee impression
you might have actually made some progress on this.

Geremy Condra

 

[Albert van der Horst]

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.

I really don't follow that. You need a tremendous set to write gimp.
Obviously you won't write gimp in Python.

Now you want to jot together three cooperating screens to specify
some properties for say bluetooth. The proposed set is ample for
that, no?
Such things make up a substantial part of the applications
as far as numbers is concerned. They are probably written by
people who don't want to dive very deeply into GUI.
(Maybe they are more bluetooth experts than GUI-experts, what
would you say?)

Adam

Groetjes Albert

 

[Zeissmann]

Seriously, get off of WoW and go write some code. If you'd spent the

last year programming instead of doing your best Xah Lee impression you
might have actually made some progress on this.

I'm curious, is Xah Lee some sort of a Usenet meme? Cause this is not the
first time I see his name in the context of a lightweight invective.

 

[Mel]

I'm curious, is Xah Lee some sort of a Usenet meme? Cause this is not the
first time I see his name in the context of a lightweight invective.

AFAIK he's just a guy who thinks Usenet is his blog, and kicks off big
rambling threads, cross-posted to infinity that mathematically have
probability 0.0 of being on topic in any of the groups they're in.

Mel.

 

[rantingrick]

If you'd spent the
last year programming instead of doing your best Xah Lee impression
you might have actually made some progress on this.

Well Geremy the very first step a wise developer employs is to get an
idea of what the masses want and what they don't want. Nobody wants to
waste a second (much less a whole year) developing a wxPython stdlib
module when the powers that be won't even *entertain* the idea of a
wxPython stdlib module. Most every Python programmer (noob to pro)
understands that while Tkinter is a great starter GUI module
eventually you hit the glass ceiling. However for some strange and
quite ridiculous reason they insist on keeping Tkinter alive forever.
I am at a loss here.

Interviewer: So how do you feel about Tkinter?
Python Community: Well Tkinter sucks what more can i say?

Interviewer: Ok so maybe we should replace Tkinter with something
better then?
Python Community: What? Are you stupid? No it sucks but we will keep
it! And that is that! I have spoken!

Interviewer: So let me get this strait fella... You hate Tkinter, and
most of your constituents won't even bother to use it because they
hate it also *however* you just want to let it rot in the stdlib like
some aging hero of boredom and booze?
Python Community: Pretty much. Yea.

Interviewer: Sounds like a Masochistic psychosis to me.
Python Community: ad hominem!, ad hominem!

 

[Terry Reedy]

Well Geremy the very first step a wise developer employs is to get an
idea of what the masses want and what they don't want.

'The masses' have so far been divided on what alternative they might
want. In any case, open source developers are typically scratching their
own itches, which may are may not be influenced by 'the masses'.

Nobody wants to waste a second (much less a whole year)
> developing a wxPython stdlib
module when the powers that be won't even *entertain* the idea of a
wxPython stdlib module.

As far as I know, no one has ever seriously proposed any replacement for
tkinter in at least the last ten years. There has been nothing to
entertain, review, or discuss, let alone approve or reject. (And if you
propose to the PSF that developer X contribute his code, the answer will
be to talk to developer X instead.) 'gui' does not appear in any PEP
title (except as part of 'guide' or 'guideline'.

 

[Adam Skutt]

I really don't follow that. You need a tremendous set to write gimp.
Obviously you won't write gimp in Python.

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.

Now you want to jot together three cooperating screens to specify
some properties for say bluetooth. The proposed set is ample for
that, no?

Yes, but why would I ever do such a thing? Such things are provided
for me by the operating system already, pretty much regardless of
platform. His widget set is quite truly only good for OS utilities,
but I already have those. I generally don't need nor want more of
them. Neither do Python users, because the majority of us aren't
writing OS utilities.

That leaves the logical equivalent of traditional terrible, awful
Visual Basic applications left, and even Microsoft gives them a full
widget set (and "real" programming language) now in VB.NET. The
effort involved in segmentation doesn't make things any easier and
doesn't save them, the library authors, much of anything.

Such things make up a substantial part of the applications
as far as numbers is concerned. They are probably written by
people who don't want to dive very deeply into GUI.
(Maybe they are more bluetooth experts than GUI-experts, what
would you say?)

I could list every application on the my computer and make a table of
which ones would be workable given the list above, but I can already
tell you that the answer is, "Not very many, and most of the ones that
can were written by MS". And I'm entirely ignoring issues like
theming as well. Adding a few additional layout controls would expand
the list a moderate deal, but that's going to be true pretty much
regardless of which 3 or 4 additional widgets you pick.

And this ignores the obvious, "You'd still need a full WxWidgets
install in order to build the minimized set, so all you've saved is a
few .py files" part of the argument, which is just as compelling, if
not more so.

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.

Adam

 

[rantingrick]

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

[...snip incessant rambling...]

Adam your post is so incoherent that i cannot decide if you are FOR or
AGAINST changing the current Tkinter GUI module into a wxPython GUI
module. And this widget set that you keep referring to is a bit vague
also. So i will quote myself because i *think* this may be what "it"
referres to...

#######################
# Start Quote by Rick #
#######################
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".
#####################
# End Quote by Rick #
#####################

If you cannot relize that this is exactly what we have now in Tkinter
then you need to go and read the source for Tkinter. Oh hell, i'd
better do it for you. Watch this...
['StringVar', 'IntVar', 'DoubleVar', 'BooleanVar', 'Tk', 'BaseWidget',
'Widget', 'Toplevel', 'Button', 'Canvas', 'Checkbutton', 'Entry',
'Frame', 'Label', 'Listbox', 'Menu', 'Menubutton', 'Message',
'Radiobutton', 'Scale', 'Scrollbar', 'Text', 'OptionMenu',
'PhotoImage', 'BitmapImage', 'Spinbox', 'LabelFrame', 'PanedWindow',
'Studbutton', 'Tributton']

Now what seems to be missing from my proposed widget set that hampers
you from re-creating every GUI app on your computer? And just in case
you did not notice "my proposed wxPython module" includes the exact
same widget set. Ok, Ok, i let out image support but in my mind PIL
should handle all of that. The IntVar, StringVar, and BooleanVar
classes are non-applicable in a wx GUI. So just for your sake i shall
"lower the bar of comprehension"...

tkclasses = re.findall(r'class (\w+)\(', s)
omit = ['StringVar', 'IntVar', 'DoubleVar', 'BooleanVar', 'Tk', 'BaseWidget', 'Widget', 'Frame', 'Message', 'OptionMenu', 'LabelFrame', 'PanedWindow', 'Studbutton', 'Tributton']
[x for x in tkclasses if x not in omit]

['Toplevel', 'Button', 'Canvas', 'Checkbutton', 'Entry', 'Label',
'Listbox', 'Menu', 'Menubutton', 'Radiobutton', 'Scale', 'Scrollbar',
'Text', 'PhotoImage', 'BitmapImage', 'Spinbox']

There you have it. The same exact widget set we have now. Sure you
cannot re-create every GUI app on your stinking computer however if
you download the 3rd party wxPython extension module not only will you
be able to re-create every GUI app on your stinking computer it will
wipe your backside too! (psst: "it" refers to wxPython)

i hope you learned something from this exercise Adam.

 

[Kevin Walzer]

#######################
# Start Quote by Rick #
#######################
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".

Rick,

So, after all this discussion, your idea (it's not quite a proposal
since you haven't initiated the PEP process for it) boils down to
replacing Tkinter in the stdlib with a very stripped-down subset of
wxPython?

I'm not quite clear on what this accomplishes. Some of these widgets in
Tkinter are ugly, but they have themed (ttk) equivalents (such as label,
entry, button) that wrap native widgets in a manner similar to wxPython.
So there's no real advantage to wx here.

Your suggestion that developers who want a larger widget set can
download the entire wxPython package is, again, answered by the
observation that numerous Tk extensions, with Tkinter wrappers, exist to
expand the standard Tk widget set. And there are pure-Python extension
packages that are not dependent on binary Tk extensions, cf. Python
Megawidgets. Again, no real advantage to wxPython.

Your initial criticism that Python's standard GUI toolkit should not
dependent on the priorities and development schedule of an outside
project (Tcl/Tk) seems to have gone by the wayside here, because
wxPython is an outside project (led by Robin Dunn) that is in turn
dependent on the timeline of yet another outside project--wxWidgets, the
underlying C++ library.

Finally, there are licensing issues to consider. Tcl/Tk's license is
very liberal, BSD-style, and it is quite similar to Python's. wxWidget's
library is basically LGPL with a couple of exceptions to make it
friendlier to proprietary software. Could code under such a license be
gracefully included in the stlib?

--Kevin

 

[rantingrick]

First of all welcome back to the discussion Kevin. You and i both
appreciate and use Tkinter extensively and your input is most welcome
here. You are a smart and level headed fella which makes for good
discussion. Thanks for that! Ok, let the battle begin!

So, after all this discussion, your idea (it's not quite a proposal
since you haven't initiated the PEP process for it)  boils down to
replacing Tkinter in the stdlib with a very stripped-down subset of
wxPython?

Exactly (almost). However I need to stress that nothing will be lost
to the user when this change happens! On the contrary, much will be
gained. You're going to have the same basic capabilities as you have
now in the stdlib with Tkinter HOWEVER, you can download all the
feature rich goodies that only wx can offer.

I'm not quite clear on what this accomplishes. Some of these widgets in
Tkinter are ugly, but they have themed (ttk) equivalents (such as label,
entry, button) that wrap native widgets in a manner similar to wxPython.
So there's no real advantage to wx here.

This statement is uninformed Kevin. Wx needs no themed widgets because
the default widgets where created equal from day one. TclTk has always
been behind in look and feel. Yes we do now FINALLY have themed
widgets however this does not make TclTk equal to wxPython in any
shape or form. Kevin i ask that you and everyone else who may be
interested in this community to download the wxPython demo. This demo
(which is a work of art in it's own right!) will be all you need to
understand the vast differences between TclTk and wxPython. You can
get it here...

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

If for some reason you cannot download this beautiful demo, then at
least look at the awesome screen shots here...

http://www.wxpython.org/screenshots.php

Your suggestion that developers who want a larger widget set can
download the entire wxPython package is, again, answered by the
observation that numerous Tk extensions, with Tkinter wrappers, exist to
expand the standard Tk widget set. And there are pure-Python extension
packages that are not dependent on binary Tk extensions, cf. Python
Megawidgets. Again, no real advantage to wxPython.

Wrong. Even with the hodgepodge of third party downloads and extension
packages Tkinter cannot hold a candle to the professional quality of
wxPython. Again i urge you to at least download the demo and see for
yourself. WxPython is a massive library of almost any widget you can
imagine using in the 21st century. All of the hard work has been done
for you, no need to create your own custom widgets again and again. Do
yourself a favor and download the demo. Here it is again...

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

Your initial criticism that Python's standard GUI toolkit should not
dependent on the priorities and development schedule of an outside
project (Tcl/Tk) seems to have gone by the wayside here, because
wxPython is an outside project (led by Robin Dunn) that is in turn
dependent on the timeline of yet another outside project--wxWidgets, the
underlying C++ library.

Yes, we will always be at the mercy of another development community
unless we build a real Python GUI. Well newsflash, that dream is not
going to happen because we would need to re-invent the wheel many
times over and not to mention the long bug fix time-line. However
let's get back to reality and compare wxPython to TclTk+Tkinter.

First of all wxPython IS a part of the Python community. They DO care
about Python and Python only. Yes WxWidgets IS NOT part of our
community, however the widget set is so mature that we don't need to
worry about version releases. We could live off the current widget set
unchanged for many years to come!! Compare that to TclTk who only
cares about TclTk and the fact that TclTk is not ANYWHERE near the
maturity of wxPython. With Tkinter we WILL need to update as new
widgets and functionality come into being. Oh did i forget to give
you a link to the beautiful wxDemo, ok here it is...

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

Finally, there are licensing issues to consider. Tcl/Tk's license is
very liberal, BSD-style, and it is quite similar to Python's. wxWidget's
library is basically LGPL with a couple of exceptions to make it
friendlier to proprietary software. Could code under such a license be
gracefully included in the stlib?

Well we need the license lawyers to weigh in on that aspect. If
wxPythons license is weighed and found wanting then we must consider
something else. However, i will tell you that nothing else exists that
can match the maturity, cross-platform, and feature rich-ness of wx.
If someone knows of any such package by all means speak up!

In any event, the time to start looking for something more appropriate
to this community in the 21st century has long passed. We have allowed
Tkinter to rot and grow pungent for the sake of people's "feelings".
Yes, big changes alike this are going to piss off a few folks because
it is human nature to fear change. However i must stress that as
Python 3000 was a difficult --but very necessary change-- so too will
the ushering of a new GUI kit be. But in the the end, we will be a
better community and language for it. But we must start the
transformation now, because transformations take such a looong time!
We have dragged our collective feet long enough!

 

[Terry Reedy]

Toplevel
Label
Entry
Button
Radiobutton
Checkbutton
Canvas
Textbox
Listbox
Menu
Scale
Scrollbar
...thats all you need in the std library "widget wise".

Once IDLE is revised to use some of the widgets in ttk that are not in
tk (such as Notebook) the set would need expansion. But the details of
any such set are irrelevant to the main problems of replacement.

 

[Kevin Walzer]

First of all welcome back to the discussion Kevin. You and i both
appreciate and use Tkinter extensively and your input is most welcome
here. You are a smart and level headed fella which makes for good
discussion. Thanks for that! Ok, let the battle begin!

Glad to be back.

Wrong. Even with the hodgepodge of third party downloads and extension
packages Tkinter cannot hold a candle to the professional quality of
wxPython. Again i urge you to at least download the demo and see for
yourself. WxPython is a massive library of almost any widget you can
imagine using in the 21st century. All of the hard work has been done
for you, no need to create your own custom widgets again and again. Do
yourself a favor and download the demo. Here it is again...

I'm quite familiar with the wxPython demo. I've got the latest
incarnation, from 2.9.x, installed on my machine. The latest version is
quite nice, especially with the AUI widgets, and the underlying
wxWidgets libraries are finally up-to-date on my Mac as they access the
Cocoa frameworks, rather than the deprecated Carbon frameworks.

However, wxPython does lack some things on my Mac, which I have been
able to implement in Tk. Specifically:

1. My Tkinter apps can access the Mac's Services menu, which provides a
form of inter-application communication that allows one application to
send data to another and have the target application perform some
manipulation of that data. wxPython does not support this feature of the
Mac.

2. Any wxPython application that attempts to display the filesystem on
the Mac looks out-of-place because wx has no support for displaying
native icons on the Mac, though it can display them in Windows. Tk on
the Mac has a few different ways of displaying icons natively.

3. wxPython applications do not make use of common window flags on the
Mac, such as sheets and drawers. Tk provides native support for some of
this, and extension packages provide further support.

So: while wxPython is quite capable of creating handsome applications,
even on the Mac, there are subtle things about wxPython applications
that make them feel not quite native, regardless of how rich the overall
widget set is.

Part of my preference for Tkinter is that, under the hood, Tk is much,
much easier to extend than wxWidgets. I have written several libraries
in Objective-C, using Tk's C API, that hook into various aspects of
native Mac functionality, such as the Services menu. Once this
functionality is accessible from Tk, it's trivial to write a Python
wrapper for it; it's often as easy as 'root.tk.call', 'nativetclcode here'.

As I understand it, extending wxWidgets requires coding in C++, and then
you'd need to run your code through SWIG in some fashion to be able to
access it from wxPython. In short, there are several more steps, and
it's likely more complicated at each step. For various reasons, the
things I think are missing from wxWidgets (native icons, sheets/drawers,
etc.) are not considered important by the core wxWidget developers, or
implementing them is a low priority.

Well we need the license lawyers to weigh in on that aspect. If
wxPythons license is weighed and found wanting then we must consider
something else. However, i will tell you that nothing else exists that
can match the maturity, cross-platform, and feature rich-ness of wx.
If someone knows of any such package by all means speak up!

Well, PyQt comes to mind. Qt is better at native Mac implementation than
wx in many respects (window flags, accessing native Mac icons), and
overall it is a richer framework (its support for WebKit is amazing),
but PyQt remains licensed under the GPL, which makes it off-limits for
the stdlib. Plus, there are other Python-Qt implementations out there
(PySide) that may claim some of PyQt's mindshare in the future.

--Kevin

 

[rantingrick]

Once IDLE is revised to use some of the widgets in ttk that are not in
tk (such as Notebook) the set would need expansion.

The IDLE library has had a NoteBook widget for ages. They just choose
to call it TabPages instead. And what is a NoteBook exactly? Well a
Notebook is a compound widget consisting of a "main frame that holds
two sub frames -- which are a "tab" frame and "pages" frame. When any
"tab" is clicked the page it is linked to is either *raised-to-the-top-
of-the-stack* OR *made-visible* depending on the design. Each "tab"
within the "tab frame" is a Radiobutton. Technically you could even
consider a RadioButton as a compound widget consisting of a button and
a label widget. And one could even dissect further the components of
any such widget however we must stop at some point. The widgets i
outlined are the highest of the lowest you'd want to consider.

I believe compound widgets have no business in the stdlib. When Guido
included Tkinter in the stdlib it was mainly for ease of introductory
GUI programming to the uninitiaed and for batteries included. However
since we do have a "batteries included" mantra we will need to hash
out which compound widgets should be included in the stdlib -- at a
later time! At this time the discussion needs to focus on defending OR
replacing Tkinter with something better. And my position is that we
cannot keep lugging around this ancient TclTk library.

But the details of
any such set are irrelevant to the main problems of replacement.

Not exactly. Once a library has been chosen we will need to consider a
small subset for inclusion in the stdlib and ONE large extension
library. So these problems are very relevant -- albeit out of
chronological order.

 

[rantingrick]

I'm quite familiar with the wxPython demo. I've got the latest
incarnation, from 2.9.x, installed on my machine. The latest version is
quite nice, especially with the AUI widgets, and the underlying
wxWidgets libraries are finally up-to-date on my Mac as they access the
Cocoa frameworks, rather than the deprecated Carbon frameworks.

Glad to hear that!

However, wxPython does lack some things on my Mac, which I have been
able to implement in Tk. Specifically:

1. My Tkinter apps can access the Mac's Services menu, which provides a
form of inter-application communication that allows one application to
send data to another and have the target application perform some
manipulation of that data. wxPython does not support this feature of the
Mac.

Ok so you're complaining about a "Mac specific" missing functionality?

2. Any wxPython application that attempts to display the filesystem on
the Mac looks out-of-place because wx has no support for displaying
native icons on the Mac, though it can display them in Windows.  Tk on
the Mac has a few different ways of displaying icons natively.

Ok, even if it looks "out of place" this is another "Mac Specific"
problem.

3. wxPython applications do not make use of common window flags on the
Mac, such as sheets and drawers. Tk provides native support for some of
this, and extension packages provide further support.

"Mac Specific"

So: while wxPython is quite capable of creating handsome applications,
even on the Mac, there are subtle things about wxPython applications
that make them feel not quite native, regardless of how rich the overall
widget set is.

I think the moral of this story is simple. Mac decided to implement an
OS that is completely different from the others. Also as you well know
Macs are at the bottom of the stack in terms of popularity. Windows,
Unix, Linix, Mac, in that order. Sure you "may" have the most
pretentious OS on the planet. However you must accept that with a
small user community also comes an equally small developer community.
And even if i give these "minor complaints" 100% merit you still only
have 0.25% of the market you are representing, so you lose the
argument in a big way. Your complaints are but a drop in the
proverbial bucket. But don't fret my friend with wxPython in the
stdlib i'll bet you could persuade or even help to bring Mac support
for these "small" annoyances.

As I understand it, extending wxWidgets requires coding in C++, and then
you'd need to run your code through SWIG in some fashion to be able to
access it from wxPython. In short, there are several more steps, and
it's likely more complicated at each step.  For various reasons, the
things I think are missing from wxWidgets (native icons, sheets/drawers,
etc.) are not considered important by the core wxWidget developers, or
implementing them is a low priority.

Well this is something that you need to attack at the source Kevin.
Specifically i mean for you to join the WxWidgets group and start a
grassroots movement for better mac support. Barking about a few small
"annoyances" with an OS that has a "last ranked" standing is a bit
bombastic to say the least. Yes?

Well, PyQt comes to mind. Qt is better at native Mac implementation than
wx in many respects (window flags, accessing native Mac icons), and
overall it is a richer framework (its support for WebKit is amazing),
but PyQt remains licensed under the GPL, which makes it off-limits for
the stdlib. Plus, there are other Python-Qt implementations out there
(PySide) that may claim some of PyQt's mindshare in the future.

I am willing to support any GUI library that will move us forward and
TclTk is dead weight. I like the feature rich nature of wx however i
will consider others if a "compelling" argument is put forward.

 

[Steven D'Aprano]

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.


[...]

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.

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.

 

[Terry Reedy]

least look at the awesome screen shots here...

http://www.wxpython.org/screenshots.php

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.

Based on this page, wxwidgets would be a regression from tk. 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.

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. There are, however, other problems with wx that I
have and will point out in other posts.

 

[Adam Skutt]

Adam your post is so incoherent that i cannot decide if you are FOR or
AGAINST changing the current Tkinter GUI module into a wxPython GUI
module. And this widget set that you keep referring to is a bit vague
also.

If you found my post incoherent then you shouldn't be attempting to
respond, you should ask me to fucking clarify! Funny how when I ask
you technical questions you refuse to respond, but when you find my
post incoherent you find plenty of time to attempt to twist my words
to support your own mental masturbation.

If you cannot relize that this is exactly what we have now in Tkinter
then you need to go and read the source for Tkinter. Oh hell, i'd
better do it for you. Watch this...

As I already told you, if you think that what's contained only in
TkInter is relevant or interesting, then you're hopelessly lost. In
fact, you're outright trolling. Python's standard library don't only
include TkInter so only talking about TkInter is entirely
disingenuous.

Now what seems to be missing from my proposed widget set that hampers
you from re-creating every GUI app on your computer?

Go download the applications and run them yourself! If you can't
figure it out from a visual examination, you lack the competence to
bring forward your proposal. Being able to identify what widgets are
used to create an application is a fundamental, rudimentary skill. If
you lack that skill, you're tacitly calling all of your credibility
(not that you haven't already done a fine job of demolishing any
assumed credibility on your part) into question.

Ok, Ok, i let out image support but in my mind PIL
should handle all of that.

It fundamentally cannot. That's not how image rendering in native
widgets works.

There you have it. The same exact widget set we have now. Sure you
cannot re-create every GUI app on your stinking computer however if
you download the 3rd party wxPython extension module not only will you
be able to re-create every GUI app on your stinking computer it will
wipe your backside too! (psst: "it" refers to wxPython)

Again, I've already responded to this in detail, in other postings,
posted serious and detailed technical questions, and asked for your
clarifications. So instead of posting the same tired, idiotic tripe,
why don't you go find those postings, read them, and respond to them?
Your refusal and/or inability to do so harms your position immensely.

i hope you learned something from this exercise Adam.

I'm not the one who needs to learn anything.

Adam

 

[Kevin Walzer]

Ok so you're complaining about a "Mac specific" missing functionality?

Um, yes.

Ok, even if it looks "out of place" this is another "Mac Specific"
problem.

Yes, it sure does. "Mac-specific"=="important."

"Mac Specific"
Ditto.


I think the moral of this story is simple. Mac decided to implement an
OS that is completely different from the others. Also as you well know
Macs are at the bottom of the stack in terms of popularity. Windows,
Unix, Linix, Mac, in that order. Sure you "may" have the most
pretentious OS on the planet. However you must accept that with a
small user community also comes an equally small developer community.
And even if i give these "minor complaints" 100% merit you still only
have 0.25% of the market you are representing, so you lose the
argument in a big way. Your complaints are but a drop in the
proverbial bucket. But don't fret my friend with wxPython in the
stdlib i'll bet you could persuade or even help to bring Mac support
for these "small" annoyances.

Rick, your statements here are entirely untroubled by facts. First of
all, Mac OS X *is* Unix, at least according to The Open Group, which
controls the UNIX trademark and is actually in charge of certifying an
OS as valid UNIX. Next, in terms of market share, Apple's machines
exceeded 10% of the U.S. market (placing them third in shipments behind
HP and Dell), and run about 4-5% of the market globally. (See
http://bit.ly/cqxl6L.) In any event, it's a bit more than 0.25%.
(Actually, according to http://bit.ly/c4PBlm, Linux comes in at around
0.77%, while Mac OS X comes int around 5%.)

Well this is something that you need to attack at the source Kevin.
Specifically i mean for you to join the WxWidgets group and start a
grassroots movement for better mac support. Barking about a few small
"annoyances" with an OS that has a "last ranked" standing is a bit
bombastic to say the least. Yes?

I have commit rights to the Tk core, so it's much easier for me to
submit bug fixes and patches there. It's not worth my while to do the
same for wxWidgets.

--Kevin

 

[Adam Skutt]

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.

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; and since rick's proposal involves regressing the
standard library..

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.

First, you can't even build MS Paint from Rick's set / the TkInter set
alone, so you're already way off mark (even ignoring the ribbon in the
latest versions).

Second, relevance? If I cannot ship the application with only 20% of
the functionality, then your point is meaningless. Plus, look at my
list more closely: TweetDeck is really little more than a bunch of
listboxes stuck side by side, but we cannot even construct that
without replicating what would be considered standard widgets (mostlu
layout widgets, but still, that's the hardest stuff to get right and
therefore the most important stuff to include). It is not, from a GUI
L&F perspective, "complicated". Yet, I still need quite a few widgets
in order to assemble it and make it work. And many of those widgets
need fairly rich functionality: buttons must support text and images,
listboxes must support embedding more than text, text controls must
support hyperlinks, the various layout panes must support scrollbars,
sizing, and dynamic updates.

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.

Perhaps, but the drop off isn't relevant till we approach well over 30
widgets, at least, quite arguably more (since GUI toolkits include
both things that are common, and things that absolutely suck to
program, even if they're not used often).

Adam

 

[Adam Skutt]

The IDLE library has had a NoteBook widget for ages. They just choose
to call it TabPages instead. And what is a NoteBook exactly? Well a
Notebook is a compound widget consisting of a "main frame that holds
two sub frames -- which are a "tab" frame and "pages" frame. When any
"tab" is clicked the page it is linked to is either *raised-to-the-top-
of-the-stack* OR *made-visible* depending on the design. Each "tab"
within the "tab frame" is a Radiobutton.

You need an eye exam if you actually believe what you just wrote.
TabLayouts are not just two frames and radiobuttons inside a bigger
frame. To even say that is disingenuous and insulting to every human
who's ever used one.

I believe compound widgets have no business in the stdlib.

All widgets are compound widgets, ergo you believe no widgets should
be in the stdlib.

Adam