Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Tkinter: The good, the bad, and the ugly!

Reply
Thread Tools

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

 
 
Steven D'Aprano
Guest
Posts: n/a
 
      12-31-2010
On Thu, 30 Dec 2010 23:04:33 -0500, Robert wrote:

> 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.


--
Steven
 
Reply With Quote
 
 
 
 
rantingrick
Guest
Posts: n/a
 
      12-31-2010
On Dec 30, 9:44*pm, Gerry Reno <(E-Mail Removed)> wrote:

> 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.
 
Reply With Quote
 
 
 
 
rantingrick
Guest
Posts: n/a
 
      12-31-2010
On Dec 30, 9:51*pm, Robert <(E-Mail Removed)> wrote:
> 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
 
Reply With Quote
 
Adam Skutt
Guest
Posts: n/a
 
      12-31-2010
On Dec 30, 11:24*pm, rantingrick <(E-Mail Removed)> wrote:
>
> > 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.


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
 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      12-31-2010
On Dec 30, 10:04*pm, Robert <(E-Mail Removed)> wrote:

> 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.

 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      12-31-2010
On Dec 30, 10:41*pm, Adam Skutt <(E-Mail Removed)> wrote:
> On Dec 30, 11:24*pm, rantingrick <(E-Mail Removed)> wrote:
> > 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


> 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?

 
Reply With Quote
 
Owen Jacobson
Guest
Posts: n/a
 
      12-31-2010
On 2010-12-30 12:36:05 -0500, rantingrick said:

> On Dec 30, 9:51*am, Kevin Walzer <(E-Mail Removed)> wrote:
>>
>> Tcl is not a domain-specific language for creating GUI's. Tcl is a
>> full-featured, general-purpose programming language that is a peer to
>> Python in its capabilities,

>
> 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.

>> and surpasses Python in some respects.

>
> 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

 
Reply With Quote
 
Owen Jacobson
Guest
Posts: n/a
 
      12-31-2010
On 2010-12-30 19:43:21 -0500, Gerry Reno said:

> For those that are lurking, this might provide a little background:
>
> http://journal.dedasys.com/2010/03/3...-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

 
Reply With Quote
 
python@bdurham.com
Guest
Posts: n/a
 
      12-31-2010
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
 
Reply With Quote
 
flebber
Guest
Posts: n/a
 
      12-31-2010
On Dec 31, 3:04*pm, Robert <(E-Mail Removed)> wrote:
> On 2010-12-30 22:28:39 -0500, rantingrick said:
>
> > *On Dec 30, 8:41�pm, Robert <(E-Mail Removed)> wrote:
> >> On 2010-12-30 19:46:24 -0500, rantingrick said:
> >> Just to clarify...I like Python. I am learning it at the moment.

>
> > Glad to have you aboard Robert!

>
> Thanks!
>
>
>
> >>> 3. What is your opinion of Tkinter as to it's usefulness within the
> >>> stdlib?

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

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

>
> I speak up. *
>
>
>
>
>
> >>> 5. Should Python even have a GUI in the stdlib?

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

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

>
> 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... *
>
>
>
>
>
> >>> 6. If Python should have a GUI, then what traits would serve our
> >>> community best?

>
> >> This is a good one.

>
> >> It should be:

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

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

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

>
> 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.
>
> --
> Robert


I thank this thread for putting me onto Pyside +1

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
if and and vs if and,and titi VHDL 4 03-11-2007 05:23 AM



Advertisments