Re: Tkinter: The good, the bad, and the ugly!
Katie T
>
> Then and only then will Python be truly what GvR intended. I want
> everyone here to consider what i am proposing and offer some opinions
> because it is time for change.
What's your opinion of the other gui toolkits with Python bindings
like PyQt and PyGtk?
Katie
--
CoderStack
http://www.coderstack.co.uk/perl-jobs
The Software Developer Job Board
Alexander Kapps
>
> Tkinter: The good, the bad, and the ugly!
> -----------------------------------------
> An expose by rantingrick
You are seriously starting to sound like Xah Lee.
> our beloved dictator (Mr. Van Rossum) had the foresight to include a simplistic GUI toolkit that we call Tkinter
> into the stdlib. And he saw that it was great, and that it was good, and so he rested.
For a technocrat (and that's an insult, in my book), you have a
really annoying bible-style type of speech (or do you just play too
much WoW?).
Would you please stop to consider your own, what 4 or 5, years of
programming experience to be enough to judge on such reasons?
Some thought-food for you: What other GUI toolkit even just *could*
had been included by Pan, Jesus, Mohammed, Budda, or God herself?
(it's *your* wording that makes me include such names)
> The answer is simple. We need a 100% Python GUI.
How many times did you say that now? Have you done anything to
archive that goal? Have you even tried to support existing projects?
I'm going to bet my right arm, that you haven't.
> Then and only then will Python be truly what GvR intended.
I must admit, you keep true with yourself and even advance on that.
Now you not only claim to speech for the whole Python community, but
for Guide himself.
Sorry, but how megalomaniac are you?
Gerry Reno
like smartphones.
Also, what do you think about frameworks such as pyjamas? It lets you
write in python and compiles everything down to Javascript so it can be
used across the Web as well as on the desktop.
Octavian Rasnita
> Back in the early days of Python --when this simplistic beauty of
> programming bliss we enjoy today was just a tiny glimmer of hope in a
> archaic world plagued by dark forest of braces and jagged caverns of
> cryptic syntaxes-- our beloved dictator (Mr. Van Rossum) had the
> foresight to include a simplistic GUI toolkit that we call Tkinter
> into the stdlib. And he saw that it was great, and that it was good,
> and so he rested.
Yes, for that time it was good.
> Life was good, people were happy...but darkness loomed on the
> horizon...
Not all the people were happy because the darkness disappeared partially for some of them and more and more blind people started to use a computer, and discovered that the Tk interfaces are absolutely inaccessible for them.
> The answer is simple. We need a 100% Python GUI. A GUI coded in Python
> from top to bottom. A GUI that is cross platform to the big three
> (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but
> also a GUI that can be manipulated by the average python programmer. A
> GUI that not only teaches the fundamentals of using a GUI, but also a
> GUI that teaches how a GUI works under the hood
So it should be a kind of SWING library made in Python, right?
It is a good idea, but it should not have the problems of SWING and in that case it would be very hard to do.
First, the interface should look exactly as the native interfaces for each system named, and it should provide the same features, because otherwise the interface would look strange for all the users on all the operating systems.
And of course, it should not only look OK, but it should also follow the accessibility standards for beeing accessible for screen readers also.
WxPython is the best GUI because it is fast, even though it is bloated, it uses the native GUI elements on all those 3 operating systems and a relatively good accessibility for screen readers.
But WxPython still have problems because not all operating systems native GUIS offer the same widgets and features and those features custom-made don't respect the accessibility standards.
WxPython is fast because it is made in C - it uses the native GUI elements of the OS which are also made in C. Would a Python - only GUI have the same speed? If yes, it would be great.
Octavian
Octavian Rasnita
> What's your opinion of the other gui toolkits with Python bindings
> like PyQt and PyGtk?
>
> Katie
> --
They are not accessible at all for screen readers, so the programs that still use them won't be accessible to all potential users.
Octavian
Hank Fay
2) I don't consider JSONRpc to be a deal-breaker, and since that's what pyjamas uses naturally, and since it's incredibly easy to use the Python middleware of your choice for the JSONRpc server, running in different browsers is unlikely to be an issue.
3) I don't think legacy apps should be a consideration in deciding what tooling is going to be built today: building for all the yesterdays is a recipe for stagnation. Besides, the legacy apps have their own toolsets for maintenance: if they are to be converted, converting them to a form that can run anywhere (using, e.g., PhoneGap to access native UI hooks) seems to me the best choice.
That said, pyjamas has only the beginnings of a visual designer (pyjsglade at http://sourceforge.net/projects/pyjsglade/). It's being written in Python, too, which should please you (as it does me -- so much so that I volunteered to be a documenter for the project).
I think pyjamas combined with pyjsglade could be the foundation for a pythonic ui development environment that could carry us forward for many years to come, unlike those available today in Python.
Hank
PS: At first I thought you were going to do a riff on "The Plan" from years ago. I had broken 5 ribs in multiple places in a bicycling accident 2 days before when a friend faxed it to me (it was that far back): I can't tell you how much it hurt to laugh so hard. <s> But this isn't a laughing matter: I see it as the main impediment to opening up Python to the kinds of programmers who used Access, VB6 and VFP to build the kinds of domain-knowledge-specific apps that continue to enhance many workplaces.
Hank Fay
Steven D'Aprano
> Tkinter: The good, the bad, and the ugly!
> -----------------------------------------
> An expose by rantingrick
Your ideas are intriguing to me and I wish to subscribe to your
newsletter.
> The answer is simple. We need a 100% Python GUI. A GUI coded in Python
> from top to bottom. A GUI that is cross platform to the big three
> (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but
> also a GUI that can be manipulated by the average python programmer. A
> GUI that not only teaches the fundamentals of using a GUI, but also a
> GUI that teaches how a GUI works under the hood
I look forward to seeing this software of yours. Let us know when you've
got some code, and not just empty talk.
--
Steven
Adam Skutt
> First, the interface should look exactly as the native interfaces for each system named, and it should provide the same features, because otherwise the interface would look strange for all the users on all the operating systems.
> And of course, it should not only look OK, but it should also follow the accessibility standards for beeing accessible for screen readers also.
>
Which is where the contradiction comes into play: to use the actual
native widgets, you have to write some C (or Objective-C). Of course,
on Windows, people have faked the native widgets so many times that
you could probably get away with it if you made a really good fake,
though there are still a lot of gotchas that go with that
(accessibility and all that "other stuff"). On Linux, it's not like
there's really a standard anyway. That leaves OS X as the really
troublesome one.
>WxPython is fast because it is made in C - it uses the native GUI elements of the OS which are also made in C. Would a Python - only GUI have the same speed? If yes, it would be great.
>
Speed is not even on the list of things I'd be worried about first.
Adam
Kevin Walzer
> The answer is simple. We need a 100% Python GUI. A GUI coded in Python
> from top to bottom. A GUI that is cross platform to the big three
> (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but
> also a GUI that can be manipulated by the average python programmer. A
> GUI that not only teaches the fundamentals of using a GUI, but also a
> GUI that teaches how a GUI works under the hood
Any GUI framework is going to require at least some heavy lifting in C,
C++ or Objective-C (depending on the platform). A pure-Python approach
to GUI development is technically infeasible.
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Hank Fay
> Any GUI framework is going to require at least some heavy lifting in C,
> C++ or Objective-C (depending on the platform). A pure-Python approach
> to GUI development is technically infeasible.
>
> --
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com
So I thought. Then I came across a framework (Cappucinno.org) and a Visual Designer (280Atlas.com) written entirely in JavaScript (well, Objective-J which gets compiled to JavaScript). Check out 280Slides.com or http://githubissues.heroku.com/#280north/cappuccino for examples of what can be done using JavaScript, and 280Atlas.com for a video of their visual designer. If that designer can be written in JavasScript (it runs on the web, BTW, and only as an after-thought as a desktop app), then it can be done in Python.
Having worked for 20 years in a windows-based development tool that painted controls (giving them fake hwnd's) to get enough speed to run on Windows, this was a real game-changer for me.
Hank
Kevin Walzer
> learning a language like C --which is hugely useful in many
> contexts!-- than to waste one second of my time on a domain specific
> language like TCl which is created only for drawing GUIs using Tk. I
> think everyone can agree that learning C is of benefit far more
> benefit to anyone in the programming field. Also one could argue that
> C and Python are very similar. However Python and Tcl are like night
> and day.
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, and surpasses Python in some respects.
>
> This monkey on our back (TclTk) is dead weight. We need to free
> ourselves of this GUI prison and bring Python into the 21st century.
> Tk is old and ugly. Tk is slow. Tk is incomplete and it will never be
> complete or extensible within our community.
In 2010, Tk only lacks two major features common to GUI toolkits:
1. A cross-platform printing API. This is mainly an issue on Windows,
which lacks a rich command-line printing framework. The canvas widget
can generate PostScript, and the text widget can export its contents to
a text file, and then "lpr" can handle the rest on Unix systems
(including the Mac). Still, if you want native dialogs and full
integration with a platform-specific printing API, you will have to
utilize one of several, incompatible, platform-specific extensions.
2. A robust widget for HTML display. The old TkHTML widget (authored by
D. Richard Hipp, the author of SQLite) works, but it's very dated (last
updated in 2002) and lacks modern features like CSS support. An effort
to produce a next-generation HTML widget, TkHTML 3, yielded an
alpha-quality widget that is enormously complex, somewhat buggy, and
little used.
These days, Tkinter has pretty much everything that other GUI toolkits
have: tree views, multi-column listboxes, plus all the basics, available
through the core widget, the themed ttk widgets, or extension packages.
Today, there's no excuse for developing an ugly Tk GUI--if a new Tk app
is ugly, that's a reflection on the developer, not the toolkit.
>
> There is no OpenGL canvas readily available. Sure you can use Togl (as
> i have successfully!) however Togl is old and unmaintained. Any GUI
> library in this day and age must support opengl out of the box!
Togl is still developed. One of its maintainers, Greg Couch, is a
developer on the UCSF Chimera project (a Python-Tkinter based molecule
viewer).
> Look, losing Tkinter will be very painful for me as i have tons of
> code written already. However the more i learn about Tkinter the more
> i realize how Tkinter is a dead end street. Why let a rotting dinosaur
> stagnate in the stdlib? Anybody that has foresight knows Tkinter is
> dying and cannot be revived. It is time to move on. Tkinter served us
> well for a time but we must let go and evolve -- lest we wither and
> die ourselves!
>
I have nothing against other toolkits, and if one happens to catch on,
fine. But your assertions that Tkinter/Tk is dying have no basis in
fact. I'm an active developer in Tk with both Tcl and Python, and the
reason I have stayed with the toolkit is precisely because it isn't
dying. Check out the screenshots at my website--all those GUI's are
developed in Tk. Here's one in Tkinter/Python:
http://www.codebykevin.com/phynchronicity-running.png
--Kevin
Stefan Behnel
> So what should we do?
> ------------------------
> The answer is simple. We need a 100% Python GUI. A GUI coded in Python
> from top to bottom. A GUI that is cross platform to the big three
> (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but
> also a GUI that can be manipulated by the average python programmer. A
> GUI that not only teaches the fundamentals of using a GUI, but also a
> GUI that teaches how a GUI works under the hood
I hope you invested as much time into writing this "expose" as you did
searching the web before writing it.
http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/
(the site is currently broken for me, you can use the following instead:
Stefan
Kevin Walzer
running inside a browser. It's not a desktop app.
Kevin Walzer
This library isn't much different from other Python GUI toolkits--it's
dependent on underlying, rather large, platform-specific
implementations--but it provides an even higher level of abstraction. On
the Mac, it is dependent on PyObjC; on Windows, pywin32; and on X11,
pygtk. In short, it's a wrapper over other wrappers.
Stefan Behnel
> On Dec 30, 9:52 am, Stefan Behnel wrote:
>
>> I hope you invested as much time into writing this "expose" as you did
>> searching the web before writing it.
>
>
> """However i need to stress that my intention is towards a 100% Python
> GUI. Not a binding, not a wrapping (except for OS calls!) but a *real*
> Python GUI. The only thing that i know of at this point is pyGUI
> although there are probably others."""
Sure, fine, just making sure you know the terrain. If that's not enough for
you, you should follow Steven's advice to get started implementing
something, because this may become a lengthy undertaking.
Stefan
pyt...@bdurham.com
have: tree views, multi-column listboxes, plus all the basics, available
through the core widget, the themed ttk widgets, or extension packages.
***Today, there's no excuse for developing an ugly Tk GUI--if a new Tk
app is ugly, that's a reflection on the developer, not the toolkit***
+1 (emphasis added)
Other tk/ttk benefits:
- Very stable
- Cross platform (w/native look and feel via Python 2.7/3.1 ttk)
- Light weight
- Easy to distribute
- Extensible
Regarding lack of print support: All GUI frameworks suck in this regard.
The best approach is to use a technology designed for generating hard
copy output - something like PDF, TeX, or RTF library.
Malcolm
pyt...@bdurham.com
> Not all the people were happy because the darkness disappeared partially for some of them and more and more blind people started to use a computer, and discovered that the Tk interfaces are absolutely inaccessible for them.
Might this package help? (I have no experience with this project)
Tka11y 0.1.1 - accessibility-aware Tkinter
http://pypi.python.org/pypi/Tka11y
Another idea: Use Tkinters <Enter> events to speak TTS descriptions of
the current control and/or its contents?
I would love to hear from anyone using either of techniques ... or other
techniques or screen reader products ... to make their Tkinter
applications accessible to low vision/blind users.
Malcolm
Hank Fay
Octavian Rasnita
Subject: Tkinter accessability options (was Re: Tkinter: The good, the bad, and the ugly!)
Thank you very much for those projects! I will test them.
Unfortunately they are not a solution because if I want to create an accessible app I can do it using an accessible library, but if the other programmers of the world use a non-accessible by default GUI, than their programs won't be accessible, or they will offer a limited accessibility like Java Access Bridge offers to SWING-based apps.
If Tkinter would use that project that should offer the accessibility by default, that would be a real solution.
Octavian
Steven D'Aprano
> Also one could argue that C and Python are very similar.
One could also argue that black is white, that diamond is softer than
chalk, and that bananas are a type of spaceship. Doesn't make it so.
How to add two numbers in C:
#include <stdio.h>
int main()
{
int a, b;
scanf("%d%d", &a, &b);
printf("%d\n", a + b);
return 0;
}
And in Python:
a, b = input().split() # use raw_input in Python 2
print(int(a) + int(b))
And in Tcl:
scan [gets stdin] "%d %d" x y
puts [expr {$x + $y}]
None of the three are exactly clones of each other, but it seems to me
that Tcl and Python are quite close in spirit, if not syntax.
--
Steven
Terry Reedy
> In 2010, Tk only lacks two major features common to GUI toolkits:
>
> 1. A cross-platform printing API. This is mainly an issue on Windows,
> which lacks a rich command-line printing framework. The canvas widget
> can generate PostScript,
Uh.
1. Postscript is somewhat obsolete; being superseded somewhat by svg.
2. It is not as useful on Windows as it seems to be on *nux and macs --
not easy to either view or print.
3. The files it calls '.eps' are not readable by OOo. They can be read
by Photoshop, which can then write a file, supposedly the same but
actually not, that *can* be read by OOo. There was a thread on this list
about the issue.
I do not know whether tk is too sloppy in what it writes (and the file I
look for a trivial drawing did look sloppy, with lots of near
repetition) or whether OOo is too strict. But clearly, TK *could* write
better .eps files (like Photoshop does). And the current output is
clearly limited for my purposes.
--
Terry Jan Reedy
Mel
They both have the interpreter spirit. Very different under the hood; Tcl
is the LISP of strings. They could have called it STRP.
Mel.
Kevin Walzer
> On Dec 30, 9:51 am, Kevin Walzer<k...@codebykevin.com> 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,
>
> however what separates fantasy from reality is evidence of these
> "theories". Or rather, Illusions of grandeur!
You can build web servers, database tools, FTP clients, test
suite/automation tools, chat clients, and drivers of other CLI tools
with Tcl, just to name a few. In terms of what can be done with the
language, I'm not aware of anything that can be done in Python that
can't be done in Tcl.
The size of Python's community and its large standard library are an
advantage over Tcl. While Tcl is technically capable of many things,
it's often easier to find a Python library already coded for specific
functions--for instance, while Tcl has XML parsing and can parse RSS, it
doesn't have a rich library like feedparser all wrapped up and ready to go.
>
>> 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.
I find that Tcl's "everything is a string" representation offers a more
flexible and expressive approach in certain contexts. Tcl's "exec"
function makes interacting with external tools simpler than os.popen and
subprocess--I can get the output of a command with less code.
Of course, this is partly a matter of taste.
Arndt Roger Schneider
> On Dec 29, 6:41 pm, Gerry Reno <gr...@verizon.net> wrote:
>
>>wxPython looks good but I don't see anyone developing support for things
>>like smartphones.
>
>
> No wx is not the answer to our problems
>
Rather: ... to *your* problem...
>
>>Also, what do you think about frameworks such as pyjamas? It lets you
>>write in python and compiles everything down to Javascript so it can be
>>used across the Web as well as on the desktop.
>
>
> Hmm, this is like two double edged swords smashing one another in
> battle.
>
> Sword One: On one hand web frameworks are going to be really big soon
> -- however legacy GUI's are not going away any time soon!
There are enough out there in the wild,
they will last quite for awhile indeed;
but it's time for them to die.
>
> Sword Two: On the other hand web frameworks provide awesome cross
> platform ability that is surly only going to get better as time goes
> -- however i utterly hate JavaScript (although much worse web
> languages exist!). And sending requests back and forth between Python,
> JavaScript,
Apparently the authors do know that, too:
MessageID:<mailman.1298.1290672...@python.org>,
*sigh* no svg.
BTW: Look in comp.lang.javascript:
javascript is framework/toolkit resistent.
and BrowserX is also a real PITA. Because even though
> everyone knows this is coming all the major browsers are trying to
> insert their API into the mix. So that Joe Scripter has to write code
> that is compatible between many browsers. Until the world agrees on a
> unified API --AND IMPLEMENTS IT SERIOUSLY-- we are at the mercy of
> drunken sailors at the helm.
svg: opera, chrome, safari(including ios), ie9, firefox.
Although svg is missing under webkit/android
--Apple kept the hardware accelerated part to themeselves.
Goolge is currently implementing hardware acceleration for svg in
chrome/webkit, likewise Microsoft/ie.
Lets wait and see when svg becomes available in android, too.
Although smil is quiet another subject.
>
> I believe pyjamas has a bright future in the web playground, however
> we still need to focus our community efforts towards a Python based
> GUI. I can see a pythonGUI and pyjamas existing side by side in mutual
> harmony for many years.
>
pyjamas: Perhaps without javascript.
-roger
Kevin Walzer
> Ok, thats swell. But do you have any real examples, links, or some
> evidence of this? Or are we witnessing more wishful thinking?
http://tcl.apache.org/rivet/
http://www.amsn-project.net/
http://thecoccinella.org/
http://personal5.iddeo.es/andresgarci/tclcurl/english/
http://openacs.org/
http://www.aolserver.com/
http://www.macports.org/
http://www.nist.gov/el/msid/expect.cfm
http://www.simulistics.com/
http://personal5.iddeo.es/andresgarci/getleft/english/
http://model.com/
http://sqlitestudio.one.pl/index.rvt
http://www.speech.kth.se/wavesurfer/
http://www.ellogon.org/
http://moodss.sourceforge.net/
http://www.projectforum.com/
http://www.eggheads.org/
http://brlcad.org/
http://www.muonics.com/
Robert
> On Dec 30, 10:02 am, Kevin Walzer <k...@codebykevin.com> wrote:
>
>>> http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/
>
>> This library isn't much different from other Python GUI toolkits--it's
>> dependent on underlying, rather large, platform-specific
>> implementations--but it provides an even higher level of abstraction. On
>> the Mac, it is dependent on PyObjC; on Windows, pywin32; and on X11,
>> pygtk. In short, it's a wrapper over other wrappers.
>
>
> hmm. And what is Tkinter exactly? And more importantly how is it
> better than pyGUI (design wise)? And even more importanly, how will it
> be better in the long run? Is this just more FUD Kevin "Gates"?
I am sorry, are you always an inconsiderate idiot? That is exactly what
you are coming across as.
--
Robert
Robert
> On Dec 30, 9:52 am, Stefan Behnel <stefan...@behnel.de> wrote:
>
>> I hope you invested as much time into writing this "expose" as you did
>> searching the web before writing it.
>
> And ditto to you. If you would have followed the thread so far, in my
> second post i said...
>
> """However i need to stress that my intention is towards a 100% Python
> GUI. Not a binding, not a wrapping (except for OS calls!) but a *real*
> Python GUI. The only thing that i know of at this point is pyGUI
> although there are probably others."""[198:203]
Good luck with that.
--
Robert
Robert
> On Dec 30, 1:51 pm, Steven D'Aprano <steve
> +comp.lang.pyt...@pearwood.info> wrote:
>> How to add two numbers in C:
>>
>> [...snip code example...]
>>
>> None of the three are exactly clones of each other, but it seems to me
>> that Tcl and Python are quite close in spirit, if not syntax.
>
> Yes i'll agree to that if you also agree that Python and Perl are the
> same. Then i "maybe" your "suggestion" holds water, maybe. But you
> forgot to comment on the other big point which is... What language
> would you rather spend your time learning if you only had C and Tcl to
> choose from? If you answer Tcl you are either foolish or just trying
> to win the argument by playing devils advocate, and in that case
> you're even more foolish!
>
> The moral is that C and Python are far more useful to any programmer
> than Tcl will ever be -- whether you consider them together or apart
> does not matter. Tcl is too limited whereas Python and especially C
> are far more useful in various situations.
I'll bite. Exactly how is Tcl too limited in your view?
--
Robert
Gerry Reno
http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong
Essentially, there is nothing "wrong" with Tcl and Tkinter. They are
part of a long evolutionary chain of how we got to where we are today.
They deserve to be respected for the contributions that they have made.
The question now is whether Python needs to evolve its own GUI toolset.
Regards,
Gerry
Katie T
>
> However i need to stress that my intention is towards a 100% Python
> GUI. Not a binding, not a wrapping (except for OS calls!) but a *real*
> Python GUI. The only thing that i know of at this point is pyGUI
> programmer the ability to read OS specific calls written in Python
> would not only benefit their GUI knowledge, but also there knowledge
> of OS's in general.
It's very hard to write a good gui framework, very very few people
have managed to do it well. Microsoft, Sun and Google have all had the
resources to hire very good developers and designers to dedicate to
the task and still haven't managed to do it well.
There's not the expertise or the investment in the Python community to
build a strong Python GUI solution. From an educational viewpoint I
see that there could be value in having a pure Python solution, but in
terms of having a GUI solution that people will actually want to use
in their apps, I'm dubious that it's achievable.
Katie
--
CoderStack
http://www.coderstack.co.uk/perl-jobs
The Software Developer Job Board
Robert
You mean outside of wxPython or PySide/PyQt? I don't see the need really.
--
Robert
Robert
> On Dec 30, 6:32 pm, Robert <sigz...@gmail.com> wrote:
>> Exactly how is Tcl too limited in your view?
>
> Well Robert if have explain to you why C and Python make Tcl look
> limited by comparison then explaining will probably do neither of us
> any good. But if you think Tcl is so great by all means go spend the
> next couple of years writing legacy code until you realize one day it
> was all for nothing.
You make a big assumption. That I program in Tcl. I do not. I am
simply curious why you are being such a non-gentleman. If I was going
to program in Tcl, I would use Gnocl (a GTk binding) and not Tk. Tcl
and C will get anyone just as far as Python and C or you suck as a
programmer.
Just to clarify...I like Python. I am learning it at the moment.
>
> But let's get back on topic here shall we. I have some questions
> specifically for you Robert...
>
> 1. Have you ever used Tkinter?
Yes...nothing big though.
> 2. If so, explain what you created with it in detail?
Simple utilities is all. Simple meaning ~500-1000 LOC. I have done a
few of those just to scratch an itch.
> 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. I am not a huge fan of Tk as it is.
> 4. How long should we keep Tkinter in the stdlib?
See the last answer. I would yank it.
> 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.
> 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.
>
> I will be really surprised if you answer any of these questions. And
> sorry, but i did not have time to spec out a multiple choice Q&A for
> you. So take your time Robert. :)
Hey, there you go. At least I have real answers. :-)
--
Robert
Gerry Reno
>
> Hmm, wxPython is starting to look like the answer to all our problems.
> WxPython already has an IDE so there is no need to rewrite IDLE
> completely. What do we have to loose by integrating wx into the
> stdlib, really?
>
>
In the spirit of "batteries included", Python needs to have "something"
in the stdlib as far as gui. But it cannot be overwhelming.
The problem with wx is that it is BIG. And so if we want something like
wx to be in the stdlib then it would have to be refactored so that there
was a small basic wx that was part of stdlib and then import
wx-the-whole-enchilada if you need heavy gui artillery.
Robert
>
>
> What is your opinion (or anyone) on wxPython?
Ok, I am curious again. Have you even tried wxPython or PySide/PyQt?
--
Robert
Robert
It's BIG.
The question really is, do we need a GUI toolkit in the stdlib. I would
say "no". In wxPython's case it is a no-brainer to install (even as a
second package). I am not sure if PySide is "that easy" but it could be.
--
Robert
Robert
> On Dec 30, 8:41 pm, Robert <sigz...@gmail.com> 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
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.
--
Steven
Adam Skutt
>
> > 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.
>
> 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
Owen Jacobson
> On Dec 30, 9:51 am, Kevin Walzer <k...@codebykevin.com> 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
Owen Jacobson
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
pyt...@bdurham.com
> 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
> On 2010-12-30 22:28:39 -0500, rantingrick said:
>
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
No, that was just an example! My goodness....
--
Robert
Antoine Pitrou
Well, I don't know about Tcl but Nagios was re-written in Python:
http://www.shinken-monitoring.org/features/
Regards
Antoine.
Robert
> On 31 Dec 2010 04:20:59 GMT
> Steven D'Aprano <steve+comp....@pearwood.info> wrote:
> 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.
--
Robert
Adam Skutt
> 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.
>
> --
Perhaps because they'd rather do something useful with the tool they've created instead of trying to win some sort of nonexistent popularity contest? What value would there be in that?
Not trying to reinvent the wheel whenever feasible is both good programming and good engineering most of the time. Unfortunately, the fact you see this as irksome only paints you in a negative light.
Adam
Adam Skutt
> 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.
>
> --
Perhaps because they'd rather do something useful with the tool they've created instead of trying to win some sort of nonexistent popularity contest? What value would there be in that?
Robert
Right, just because you say it paints me in a negative light. Look at
every language out there and look within the groups. Everyone is trying
to revinvent the wheel to (in their view) make it better. Your argument
is sad to me.
--
Robert
Adam Skutt
>
> Right, just because you say it paints me in a negative light. Look at
> every language out there and look within the groups. Everyone is trying
> to revinvent the wheel to (in their view) make it better.
"Everyone" is doing nothing of the sort, hence why Tcl "irks" you. Or are you so forgetful that you can't even remember what you said a few days ago?
> Your argument is sad to me.
At least I've made an argument, whereas you've done nothing of the sort. Just because you take wheel reinvention == good as a tautology doesn't mean everyone else does. Again, what point is there in attempting to win a non-existent popularity contest?
Adam
Adam Skutt
>
> every language out there and look within the groups. Everyone is trying
> to revinvent the wheel to (in their view) make it better.
"Everyone" is doing nothing of the sort, hence why Tcl "irks" you. Or are you so forgetful that you can't even remember what you said a few days ago?
> Your argument is sad to me.
At least I've made an argument, whereas you've done nothing of the sort. Just because you take wheel reinvention == good as a tautology doesn't mean everyone else does. Again, what point is there in attempting to win a non-existent popularity contest?
Adam
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...
Robert
> On Saturday, January 1, 2011 10:00:06 AM UTC-5, Robert H wrote:
>>
>> Right, just because you say it paints me in a negative light. Look at
>> every language out there and look within the groups. Everyone is trying
>> to revinvent the wheel to (in their view) make it better.
>
> "Everyone" is doing nothing of the sort, hence why Tcl "irks" you. Or
> are you so forgetful that you can't even remember what you said a few
> days ago?
Really? How many templating systems does Python have? More than one?
Why is that? How many web frameworks does Perl have? More than one? Why
is that?
Why *was* Nagios forked and re-written in Python?
There are too many examples to count.
>
>> Your argument is sad to me.
>
> At least I've made an argument, whereas you've done nothing of the
> sort. Just because you take wheel reinvention == good as a tautology
> doesn't mean everyone else does. Again, what point is there in
> attempting to win a non-existent popularity contest?
>
> Adam
Just gave you a bunch. You have totally missed the whole point of the
original argument. Nice job. Done with you now.
--
Robert
Robert
I want to apologize for my part. We just aren't going to see the same
side of this.
--
Robert
CM
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.
Adam Skutt
>
> Really? How many templating systems does Python have? More than one?
> Why is that? How many web frameworks does Perl have? More than one? Why
> is that?
>
> Why *was* Nagios forked and re-written in Python?
>
> There are too many examples to count.
>
You're missing the point: you've yet to provide any sort of argument
whatsoever. It's not automatically true that rewriting Nagios in Tcl
would gain the Tcl community more exposure, nor is it automatically
true that more exposure is a good or desirable thing.
You first have to show how rewriting Nagios in Tcl would gain them
more exposure. Then you have to show that the exposure would be a
good thing. Until you've done both, you're arguing with very
fundamental and conventional engineering wisdom; and you have not
actually presented an argument just tautologies.
Neither will be easy to prove, by and by large, most people don't give
a shit what language their applications are written in and rightly so.
> Just gave you a bunch.
No, you've given me examples of wheel reinvention. Just because the
people reinventing the wheel thought it was a good thing doesn't
actually make it so. You personally have to present the case as to
why it is a good thing.
> I want to apologize for my part. We just aren't going to see the same
> side of this.
You can apologize, but I don't accept it. You want to actually
apologize? Admit you were wrong and retract, or act like an adult and
present an actual argument instead of wasting time.
Adam
CM
> On Jan 1, 5:39 pm, CM <cmpyt...@gmail.com> wrote:
>
> > 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.
>
>
> 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...
Tim Chase
>> programming in Python, so I read a bit, chose wxPython, downloaded it,
>> and started learning it. Done.
>
>
> 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
Albert van der Horst
Adam Skutt <ask...@gmail.com> wrote:
<SNIP>
>
>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
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
geremy condra
> On Dec 29, 6:41 pm, Gerry Reno <gr...@verizon.net> wrote:
>> Also, what do you think about frameworks such as pyjamas? It lets you
>> write in python and compiles everything down to Javascript so it can be
>> used across the Web as well as on the desktop.
>
> 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
Zeissmann
> 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
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.
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'.
--
Terry Jan Reedy
Adam Skutt
wrote:
>
> 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
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
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
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.
--
Terry Jan Reedy
Kevin Walzer
> On Jan 16, 11:39 am, Kevin Walzer<k...@codebykevin.com> wrote:
>
> 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.
Steven D'Aprano
[...]
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.
--
Steven
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.
--
Terry Jan Reedy
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."
>
>> 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"
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.
Adam Skutt
+comp.lang.pyt...@pearwood.info> wrote:
> > 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.
>
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..
> > 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.
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