E
Ethan Furman
Stephen said:
Correction: But you gotta be GPL'd to use PyQT. Python doesn't care.
Correction: But you gotta be GPL'd to use PyQT. Python doesn't care.
R
rantingrick
Actually this is a very accurate description of the process, and i
agree. And some modules will do ok in this environment because by
nature they are static. However, i think you'll also agree that GUI
has been (and continues to be) an ever evolving beast. With many,
many, library's to choose from and nobody can agree that *this* or
*that* GUI library is better. As is evidenced by the lack of
development for Tkinter. But with Tkinter there is a larger problem,
TclTk! Even Tk is not a full featured GUI library, much is to be
desired. So with all that in mind i ask you again...
Since GUI's are not as easy to maintain due their inherent fluidity
(unlike other "more static" modules)... and since the process by which
they are maintained is excruciatingly slow... why then include a GUI
at all? Free up pydev and send Tkinter to the bitbucket! But if you
*do* decide to include a GUI, should it not at *least* be based on the
native widgets like PyGUI? I think going native is going to be the
only answer here. When in Rome...
M
Mark Lawrence
On 10/06/2010 22:20, rantingrick wrote:
[snip most of it]
Great idea, but lets take this further. I don't personally like module
xyz, so let's free up pydev and send xyz to the bitbucket because I say
so. To hell with anyone elses' views, and trivial little issues like
keeping backwards compatibility.
Mark Lawrence.
[snip most of it]
Great idea, but lets take this further. I don't personally like module
xyz, so let's free up pydev and send xyz to the bitbucket because I say
so. To hell with anyone elses' views, and trivial little issues like
keeping backwards compatibility.
Mark Lawrence.
G
geremy condra
I mostly agree with you, but as Stephen points out you can't exactly
count on it being present now either, which more or less renders any
guarantee of backwards compatibility moot IMO. Whats the practical
difference between telling somebody that either tkinter works out of
the box or they'll have to satisfy an extra dependency and just telling
them that they'll have to satisfy an additional dependency in the first
place?
Geremy Condra
S
Stephen Hansen
I fail to see how the above statement (which I neither agree nor
disagree with; its loaded and there's multiple separate assertions that
don't really connect the way you want them to) leads to...
... this. I see no logic at all in how somehow this proves the previous
claim.
Tkinter, the Python wrapper, is not "developed" because it is largely
"done". It is an interface to the Tk library, which is indeed developed,
and Python does indeed get regular updates to it. That the Python
wrapper is not terribly "pythonic", and has an implementation detail of
going through TCL: so what? Somehow you think that makes it impure,
dirty, lessens Python. It doesn't.
The API may not be wonderful, but its not anti-Pythonic, either. Its
just sorta 'eh'.
There is no larger problem except in your mind. The additional
dependency of TCL seems no more onerous then the dependency of pywin32,
pyobjc, let alone pygtk, and such... and on linux it seems just as
likely to be either already present or trivially installed as any of those.
And so what, Tk is not a full featured GUI library? Since when did that
matter to you? Your entire argument has been for a non-full-featured
library. Something simple. You can't go from there then put a black mark
against Tkinter for being there already.
Tk has a few very powerful features. And a lot of very easy ones. It
fulfills a lot of people's needs just fine. For those that it doesn't,
well -- they'll soon find wxPython, PyQt, or whatever else is out there
these days.
Tkinter requires basically little or no maintenance, IIUC. There was a
little bit that had to be done in Py2->3, but otherwise-- Martin Leöwis
said he just updated the latest libs when he made a new major release.
He didn't seem to express it was a major burden.
Therefore, your argument that it is somehow a burden fails. With that
failing, there's no reason to remove what is already present: key to the
stdlib is stability, and stability also means that once something is in,
it doesn't go -out- without a -very- good reason: and almost always, a
better replacement ready immediately (and with a very clear upgrade
path). Consider the recent optparse->argparse discussions on python-dev.
Stdlib modules don't get just dumped on a whim.
Native widgets are all fine and dandy, to a point. PyGUI is all fine and
dandy, and when and if it's ready to do everything Tkinter does, if its
dependency situation is more positive then Tkinter's, and it brings some
other positives-- a good pythonic API, maybe some other carrots-- then
maybe talk of replacing Tkinter is appropriate.
As it is, it doesn't seem to me that its there yet. Not that I am deeply
familiar with PyGUI, mind you.
--
Stephen Hansen
... me+list/python (AT) ixokai (DOT) io
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)
iQEcBAEBAgAGBQJMEWU+AAoJEKcbwptVWx/lIX8H/1xF2zhwnZE8qdUnu9AL0nB8
ejlsqJ6ayaVhezJP58bBkKUqB9caLFXdwgeLFDRBrVyUa+EvqNzYAYosl9zk/PuL
W6Th4gVOpB11X0vFm4s+pZ5+7w2AzG6yKGCIsJa4aYfEqBmSs9weFSAyuBwB2m58
5QX+XB+OXh2ZF/8AAt9XceaXRayL00dlihsz3Ouj6Fyqh6AdmQ9mcQ40GBjUUgIx
bZ5oEMGOB9w2zQyCF1Ydvd2YexPiepXgWloOKxg8MRUWSwXZ+WUNeXLt1jJmBJjN
tKgBnqQeQAFnahp9MY5JPDvaIjtKu5izCGqf5kmdHOwM+vfmUIhBs+jIAW9FVJc=
=OFt1
-----END PGP SIGNATURE-----
S
Stephen Hansen
Although that is true in theory, in reality-- In my experience-- You
*can* count on it being there, except on Linux distributions which may
choose to cut it out into an optional install, and where its also
extremely trivial to add back in.
For both Mac and Windows, its basically always there. (Unless you go out
of your way to uncheck it in the windows installer...)
Linux distros may choose to cut up the standard Python library; that's
their business if they wanna do it. But they also make it really easy to
add back in.
--
Stephen Hansen
... me+list/python (AT) ixokai (DOT) io
P.S. Considering I almost never use tkinter, I'm confused how I somehow
suddenly became a Champion of Tkinter Inclusiveness.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)
iQEcBAEBAgAGBQJMEWYgAAoJEKcbwptVWx/lujUH+gIQxjsvxT6DfuRiJMyEG4bs
dQlCdu9f3hFCDbFMUsYDQm3xY9qtQ4fx9jcvKX3bl6QnaUxnfUT4oAnFgjxybRC4
0kTuq18+JDvToZVCTuIMkmLor1kEs0iqdTFQuud9Z2hRX9uhyLOOH+rpEfvBT7zm
gPXZEv6NiSPCpkFY+ARFXGsq+MZq72+Xnuxrm18B4NSSlFiTAuKSFpK/YX8NOfDq
q97aMaPX8LmVtnRNCi2PenaqU0wWur4nfj3fiXPbFc/0mKyhBE4PLpCIN3YPHBS7
kwjSQqgEavXIohuoiZp4mt4gwlcxNZzLuMEJPstlHRVtFzWoYfGjBCgLdivtxKw=
=u6B3
-----END PGP SIGNATURE-----
M
Mark Roseman
rantingrick said:
Please, enough of this nonsense rant already!
Discounting completely and without evidence or reason the considerable
amount of volunteer work that continues to go into Tkinter (and Tk) and
the people who use both does not help you advance your case.
Mark
M
Mark Lawrence
On 10/06/2010 23:24, Stephen Hansen wrote:
[snip]
FWIW I've never used any GUI in Python. I'd see your involvement on
this thread as being more like a Champion of Common Sense. This appears
to be sadly lacking from some other participants.
Kindest regards.
Mark Lawrence.
[snip]
FWIW I've never used any GUI in Python. I'd see your involvement on
this thread as being more like a Champion of Common Sense. This appears
to be sadly lacking from some other participants.
Kindest regards.
Mark Lawrence.
G
geremy condra
Sure, and that's why I said I mostly agree. Having said that,
it seems important to me to place the arguments against
projects like pygui in the context of the the arguments for
tkinter. The fact is that tkinter is not ubiquitous, and will on
some platforms require an additional dependency, forcing
those who aim for portability to take that into account. This
is exactly the same situation in which pygui finds itself, with
the exception that applications developed with pygui look
professional, while those made in tkinter generally look like
refugees from the Isle of Misfit UIs, although I'm told this
has improved markedly in recent years.
Geremy Condra
R
rantingrick
BIG +1
It seems that removing Tkinter from the stdlib will not only benefit
Python, but also Tkinter; due to the fact that Tkinter will not be
confined to Python's release schedules. As we've witnessed so far
almost nothing has changed since Tkinter's addition many years ago.
Heck they only just recently (py30) added a ComboBox widget! This
development cycle is not working for Tkinter, something must change.
Tkinter is just a dead weight we're lugging around for no good
reason.
- lib-tk 755KB
- idlelib 1.18MB
- Tcl 6.57MB (+togl 51.2KB)
All that footprint with such a small capability! There must be a
better option out there!
G
geremy condra
Please don't agree with me, its almost enough to convince me I'm
wrong.
Did you actually read what I wrote? I said nothing at all about
removing tkinter and in fact oppose doing so.
Geremy Condra
K
Kevin Walzer
What's your basis for saying this?
I've used Tk in nearly a dozen small-to-large applications on the Mac,
both in Python and Tcl, and I often compare it to PyQt and wxWidgets, as
well as Cocoa, and I think it comes up short in only a few areas:
1. Printing. Tk lacks a single API for printing documents across
platforms. Its canvas widget can generate PostScript, and under Unix and
OS X it is easy enough to send PostScript and text to the printer via
lpr, but that doesn't work on Windows--and the available printing
extensions for Windows are very different in their implementation. In
this regard, Tk lags behind Qt and wxWidgets, as well as Cocoa.
2. Support for parsing and displaying HTML across platforms. A couple of
different Tk extensions provide support for basic HTML display, but Tk
lacks a binding to a modern HTML engine like WebKit and
Mozilla--something both Qt, wxWidgets and Cocoa have in one form or
another, either as part of the core library or as an extension.
Apart from this, Tk provides, either through its core or numerous
extensions, pretty much everything you'd expect from a full-featured GUI
toolkit--listboxes, buttons, entry fields, the canvas, trees, tables,
plain-and-rich-text display, drag-and-drop, etc. Of course, because of
its small core, you do have to install a lot of library extensions and
search among various packages to find the right mix of widgets (there
are, by my count, at least three major widgets for displaying trees,
tables, and so on): if you want a single API to do these things then
another toolkit might be better.
I develop commercial desktop GUI applications for the Mac, which has the
most discriminating user base of any of the major platforms in terms of
UI polish and consistency, and I use Tk for my user interfaces--and I
have some commercial success. I do not feel that Tk lacks anything
essential, and where it has limitations, the toolkit is flexible enough
to allow me to work around those limitations.
--Kevin
R
rantingrick
Mark,
I am in no way trying to harm your efforts. Please believe me. The
work you have done at tkdocs is wonderful! It covers all four
languages in a beautiful way, and i applaud your contributions. And
lets not forget about Fredrik Lundh and all his great contributions to
Tkinter, PIL, and more.
But don't fear losing Tkinter in the stdlib, oh no. Actually i think
Tkinter would evolve far more quickly "outside" of Python. It will be
a metamorphosis from a cocoon of contempt into an unhindered bliss of
release cycles. Free of the py-version shackles that bind it. Free of
the contempt that haunts it. Free to grow, free to be, but always free
to you and me n form of download.
However, i must defend my statements concerning Tk's lack of a rich
widget set. They are as true as the sky is blue --on sunny days that
is ;-)
S
Steven D'Aprano
Sheesh, whatever drugs you're on, you need to cut back on them. This
reminds me of time-travellers suffering from "time lag" in the wonderful
novel "To Say Nothing Of The Dog" by Connie Willis.
That's not defending, that's merely repeating.
What widgets do you think Tk is missing?
R
rantingrick
The big ones:
- Grid
- ListCtrl
- EditableListCtrl
- glCanvas
I can think of many more useful compound widgets too. And don't try
and tell me these are not important. Yes you could create the first
three yourself, but this should not be necessary in the 21st century.
How long has GUI been with us...?
glCanvas should be standard part of any "non-legacy" GUI. Yes you can
download Togl (a third party module) but that is no excuse. Tk has had
years to improve and we have seen almost nothing!
Wait a minute Steven, are you fighting *for* Tkinter now? I thought
you did not use those "graphical interfaces"?
S
Stephen Hansen
You're starting to become boring, man.
On the one hand, you're arguing for getting rid of Tkinter and replacing
it with something less comprehensive (simple, small, you said). On the
other hand, you blast Tkinter for not being comprehensive.
You can't have it both ways.
Also-- you're just starting to get wrong.
http://docs.python.org/library/tix.html
They don't -call- them the things you are, but between ComboBox, and the
flexibility of HList and TList... it actually offers quite a lot. And
there are extensions you can download if there's more.
And you can make apps with native look and feel-- or close enough to it.
Yeah... no.
OpenGL is one of those things that belongs firmly not in the standard
library.
And I do not use tkinter (usually). People can recognize you're really,
really, really wrong and really, really, really off your rocket without
actually using the module you don't like.
--
Stephen Hansen
... me+list/python (AT) ixokai (DOT) io
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)
iQEcBAEBAgAGBQJMEaGxAAoJEKcbwptVWx/lMn8H/3DG3wXws53Bi3cEEFhJGuMw
eZF9SpwqArcMGdvtn2+R9zboznWTm2jYBzzwjifsR70LZ/859x8dHx5f+gEID9ei
BDqaN0ByUs3g1D1rOPvUOh9Ku6cmVRDNPjYBNDR14hx+A1+QxYMaHD2Np9PUCeA8
V2+xv7lDsuK+KuidA4Zuwze8TaFksWW0D9EjNDxAlH1eTqW+uZtR6h0Cv6G9WALr
VNP3gTSxOLGMpIsCDs813aHrKA4Gs1OhyZsSGUFHix6cH4aEVlN+V1vE25W4tsSS
nUeRHcnKr9Sy6ecy+5xgYlljzNu1P3qC11GZNdxwSFTgqU/veT18oUh0ElYouW0=
=q3Ah
-----END PGP SIGNATURE-----
S
Stephen Hansen
Just as an aside, in case anyone's curious-- to expand on Greg's answer
(as I don't have the original to reply to presently)--
The window manager is Quartz Compositor, which shows up as the
WindowServer process (or something very like it). It handles loading
image buffers in and out of memory and layering them, and doing event
processing (i.e., determining which actual window gets this key event)
and mediating interactions and such things.
It doesn't do PDF-ish stuff; that's the Quartz 2D part, which is the
window rendering subsystem. Then again, all of the different parts of
the graphics layer are just usually called Quartz, and unless you're
working for Apple you don't really care-- so calling Quartz the
rendering engine and window manager and just hand-waving it all together
is perfectly fine
X11.app runs as a regular app on top of all of this. Regular users can't
be allowed to see programs that run under X11. It will alarm and offend
their sensibilities. We macophiles are a touchy bunch about user interface.
--
Stephen Hansen
... me+list/python (AT) ixokai (DOT) io
P.S. As a further aside, Quartz Compositor is GPU-accelerated, the
rendered image gets loaded into the GPU just as a texture surface, and
it lets the GPU compose them together once it decides on their order and
placement and any effects that it wants to apply. Its nice. And some
day, Apple will turn on Quartz 2D Extreme, which moves all the rendering
routines into the GPU too. (I have no idea why they still haven't turned
it on in 10.6)
P.P.S. The above statements are not meant to be 'my platform is better
then yours'; I'm quite certain Windows has all kinds of GPU acceleration
of the basic interface (at least with Aero). And I haven't tried to run
Linux outside of a terminal-only non-GUI context in years to check up on
it. I'm just musing.
P.P.P.S. I am done asiding now. Honest. Back to the endless argument.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)
iQEcBAEBAgAGBQJMEaQ7AAoJEKcbwptVWx/lpqoIAKyTpYEOM1NptT6b/MdWO58k
LLiseAoysuS/07mB1xFCdjZuZFluGGnFTFYvXwh/erVdoOez5z7FOM+8/TKiTM4W
/4Lzjz6A4anMkagoLvZvwKlhuSULquIvYTq4vozTcINPYs/KDUHxn/hbsxdkvMfy
IRp0BI/c4D/gCnPnI6T1GtElOKkaixjzn0g2FVrqcxHyUWBamCnSMPkRezTliG68
MRI4zoLrW14XG79xpdtHtmHfCu7uLdeW8Wu4KBt6YlQXjaY38qtxt81v6Pqr1Ryx
z+qXGy4OuHQnMons7hIN35O6VsDY907a1ttc072lTxlind9U273PNZWlGVGOpQ0=
=BXEw
-----END PGP SIGNATURE-----
R
rantingrick
Urm, do you *know* what a Grid widget is Stephen? (hint: Excel) Do you
*know* what a ListCtrl is Stephen? (Hint: File Browser in report or
iconlabel views) Neither of those widgets exists in the Tix package.
And how do i *know* this? Well because unlike you i have actually
written code with Tix widgets, obviously you have not.
The TList only displays iconlabels in a wrapping column format, not in
any "report mode" ala: Windows Explorer("details mode"). The HList
widget is for showing a tree structure and is NOTHING like either a
ListCtrl or a Grid.
Just scanning the docs of a module (that you know jack about) and then
parroting off some baseless arguments are bound to bite you in the
@ss! *egg on face*
S
Stephen Hansen
Yes, I do now what a Grid and ListCtrl are. I misread the Tabular bit --
my mistake, however: I was led into a false sense of, "Gosh, he's not
even trying" by the previous comments you made about a lack of ComboBox
until Py3, when it is available in tix. And is the only part of tix I've
ever used, yes.
*Yawn*
--
Stephen Hansen
... me+list/python (AT) ixokai (DOT) io
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)
iQEcBAEBAgAGBQJMEbISAAoJEKcbwptVWx/lxqkH/R3I5iWPYC5YNmawIWyRzIVF
Qsjk2T/9Cyhdw3dqP8uD1GPHqTOdiY5ciBFstO+cGYPX3V9JVPurr41USPKjWhq0
XLs7yEc8/cdQ4JR5kxhaDpIb8ac1Uujw5xbVxbnfBHXtPnfsr7LTZMvkX6kaLTgD
DPcHHILBAGWBlRrQVBQ+mB1WIfifpp5RosHJ2aXQyG62z9yWgNuGdz148Dxwhq6+
sUzfI3HibikCNyq+xMQiNaelYfixK4Y7Rz8ZVfsWeDilsy1Zx+11It8YlW9N8s+G
5ryLEEAhe9B/LkubgMviZJHHo/y5WD9DGT/U1bsi8+n/hT655x8nUvBRVGulHCo=
=zd+R
-----END PGP SIGNATURE-----
A
ant
I don't know whether this thread is going backwards, forwards or
sideways. But a lot of useful information is creeping out of the
woodwork.
I like the points about backwards compatibility. Presumably that
reason alone is enough to keep Tkinter in the standard library for a
long while.
But the point has also been made that there are several things there
that are - if not duplicates - at least alternatives.
So would it be so awful to have Tkinter and GUI2 (whatever it is) in
the stdlib, assuming that both had equivalent functionality? That
would be the way to give people the choice.
But it does imply that GUI2 is not too huge, to prevent excessive
bloat (is that a tautology?).
Other interesting comments: licencing. Can anyone give a concise
summary of whether the 'major' GUIs have any insuperable licencing
problems that would rule them out anyway? Programming is hard enough
without lawyers.
sideways. But a lot of useful information is creeping out of the
woodwork.
I like the points about backwards compatibility. Presumably that
reason alone is enough to keep Tkinter in the standard library for a
long while.
But the point has also been made that there are several things there
that are - if not duplicates - at least alternatives.
So would it be so awful to have Tkinter and GUI2 (whatever it is) in
the stdlib, assuming that both had equivalent functionality? That
would be the way to give people the choice.
But it does imply that GUI2 is not too huge, to prevent excessive
bloat (is that a tautology?).
Other interesting comments: licencing. Can anyone give a concise
summary of whether the 'major' GUIs have any insuperable licencing
problems that would rule them out anyway? Programming is hard enough
without lawyers.