GUIs - A Modest Proposal

[Martin v. Loewis]

But whenever I

write a program that someone else is going to use, it has to have a
GUI. Is that not true for most people?

Most definitely not. Of the programs I recently wrote for other people,
they either:
- were command line scripts, meant to use for sysadmin jobs (and I
wrote them for the sysadmin people around me), or
- were web application, most of them written with Django

I have written 3 GUI applications in the last five years, one in
Tkinter, the other two in Java Swing (one being a Swing reimplementation
of the Tkinter code because the users needed Java).

In addition, I *contributed* to GUI applications that others had
written, mainly IDLE.

That, in my opinion, is where a replacement for Tkinter should be
aimed: the beginning graphics programmer.
But if it is built on the right foundation (which Tkinter seems not
to be), it could be extended to cover
far more useful cases than Tkinter can.

I personally think that Tkinter is excellent for the beginning graphics
programmer.

I don't think so. Even vast libraries of well-written code haven't
become the standard. I seem to remember a
DEC assembler manual from the last century, which said "A standard
doesn't have to be optimal, it just has to be
standard" (Feel free to correct me on that one. The last century
seems like a long time ago).

See, that's exactly because Tkinter is the standard; I see no reason
for that to change (or, rather, no chance).

As a starting point, if Tkinter was replaced, an IDE similar to or
more powerful than IDLE would be needed to replace IDLE.

It can't be me - I don't have the clout.

That's the reason why it won't happen. Everybody asking for change is
not willing to lead the effort. Everybody who would be able and might be
willing to lead the change fails to see the need for change.

Regards,
Martin

 

[Martin v. Loewis]

Am 09.06.2010 19:16, schrieb Ethan Furman:

*Alert* Potentially dumb question following: On the MS Windows platform,
Gtk is not required, just win32?

pywin32, to be precise. To include PyGui into Python, either PythonWin
would have to be included (which would require it to be contributed in
the first place), or the win32 extensions would need to be rewritten,
or PyGui would need to be implemented in terms of ctypes (which then
would prevent its inclusion, because there is a policy that ctypes must
not be used in the standard library).

I would personally prefer the win32 extensions to be rewritten for use
in core Python. I think it should be possible to generate a Win32
wrapper much more automatically (e.g. using Cython, or something like
it), and I think that the separation of pywin32 into modules is somewhat
arbitrary - either there should be a single "windows" module, or the
split should be by DLL (which still is arbitrary, but defined by MS).

That is, of course, all off-topic.

Regards,
Martin

 

[Terry Reedy]

On 6/9/2010 1:16 PM, Ethan Furman wrote:
[re PyGUI]

*Alert* Potentially dumb question following: On the MS Windows platform,
Gtk is not required, just win32?

Correct. A windows distribution probably would not include the gtk (or
cocoa) versions. And Greg hopes to remove the win32 dependency by
calling windows dlls directly with ctypes.

 

[rantingrick]

I would personally prefer the win32 extensions to be rewritten for use
in core Python.
+1

That is, of course, all off-topic.

Not entirely Martin, PyGUI is a real option to consider and PyWin32 is
part of that option. Besides PyWin32 should have already been
included. And PyWin32 should be standard even though Python support is
not standard for Windows sadly. PyWin32 has been around for quite
some time and has proven to be reliable. And yes it should be a single
module "windows" or a "logical" split of sorts.

 

[Grant Edwards]

You keep saying that, but you've given no good reasons for why we should
believe you, or what the nature of this problem supposedly is.

The current situation has broad community support: there's a relatively
lightweight GUI toolkit that ships with Python (Tkinter), even if it's
not beloved by all neither is it especially hated, and an extremely
healthy ecosystem of many alternative GUIs built on top of Qt, wxWindows,
GTK+, and others. Where's the problem?




I think the only way to end this pointless discussion is this:

"Hitler would have loved Tkinter!"

Yup, I'm pretty sure I heard Glenn Beck say that in a clip I saw on
The Daily Show (which is the only time I ever see/hear Glenn Beck).

 

[Grant Edwards]

Am 09.06.2010 01:54, schrieb Grant Edwards:

There was a Scheme implementation called STk that didn't use Tcl.

That's not true. See, for example, Src/tk-glue.c. It contains functions like

static SCM TkResult2Scheme(Tcl_Interp *interp, int objproc) ....
SCM STk_execute_Tcl_lib_cmd(SCM cmd, SCM args, SCM env, int eval_args)
...

This looks *exactly* like the approach taken in _tkinter to me.

One difference seems to be that they include the full source code of
Tcl and Tk with the interpreter, so you don't need to download it
separately.

The other difference apparently is that they expose Tcl commands as
Scheme functions, so that they can write

(Tkack [Tk:frame w.top :relief "raised" :bd 1] :expand #t :fill "both")

However, this still uses a Tcl_Interp object during evaluation.

Of course you're right. I somehow missed the fact that Tcl was
included in the distribution. That and the ability to bind Tk widgets
to Scheme "variables" (you didn't have to get/put values) had somehow
fooled me into thinking there wasn't a Tcl layer.

That said, PerlTk didn't use Tcl did it?

 

[Mark Lawrence]

On 09/06/2010 18:38, rantingrick wrote:

[snip]

Don't worry about irritating people. There are a subset of folks on
this list that await the chance to be offended just so they can spew
bile. Really, don't worry about them. And never allow these minions to
quell your freedom of speech, because they will try.

This comes from the bloke who couldn't be bothered to find out how to
download the fixed version of the Windows compiled help file?

[snip]

Guido had a vision, and he left

that vision in our hands and we utterly failed to maintain it! It has
now fallen into complete ruin. And any motivation to pull ourselves
out of this rut is missing.

Our, we, how much have you ever contributed to core versions of Python,
or any third party libraries for that matter?

[snip rest of crap]

Still waiting for your contributions, but I expect there's as much
chance of you doing anything as there is of all Arab nations keeping the
piece with Israel, or vice versa.

Still chuckling over the Windows compiled help file

Mark Lawrence

 

[rantingrick]

This comes from the bloke who couldn't be bothered to find out how to
download the fixed version of the Windows compiled help file?

Ok, so i was a bit miffed about the docs bug and felt the need to
vent. Don't tell me you've never griped about anything. ;-)

Our, we, how much have you ever contributed to core versions of Python,
or any third party libraries for that matter?

Honestly nothing so far (in the form of code) as it is beyond my skill
set at this time, but not much beyond it! Up to this point i have
contributed by answering questions on this list and other Python
lists. However, i do plan to be a driving force in this community for
a very long time to come. I am not here to spout off empty promises
and produce no results, i will back them up with code soon enough.
Anyone who has followed me over the past few years should know that
while i can be at times theatrical, slightly narcissistic, and
occasionally belligerent. I am always concerned with moving Python
into a better future.

I can see myself releasing "Python Modules" and contributing to bug
fixes on the "non-core" side of Python in the very near future. I
would very much like to be a part of this GUI fix/replacement as it
would be a great learning experience. As for the core, i would love to
contribute if and when my skills reach that level. But my concern at
this point is to contribute where i can. Updating Python's stdlib in a
way that will benefit everyone (including myself). And the first step
is calling for peoples input.

It would be both selfish and unwise for a person to create a module
and expect it to be blindly adopted without considering the many other
people who belong to this community. This is a community and we need
to include as many as we can into the decision process. For the best
results one must get supporting and opposing opinions. From that
dataset we can put our collective heads together to formulate a
solution and finally produce that solution.

I will be a part of this solution. I hope you will join in whatever
capacity your free time will allow. Even a vote of confidence is a
huge step in the right direction. I think you'll agree that Tkinter
"as-is" just ain't cutting it. One thing "we" as a community need to
do more often is combine our individual strengths into a collective
strength that can be harnessed to achieve some long since forgotten
goals. Guido has forged the path, we must strive to improve python
daily lest his and all your hard work be all for naught.

Still waiting for your contributions, but I expect there's as much
chance of you doing anything as there is of all Arab nations keeping the
piece with Israel, or vice versa.

Mark, with those odds you can safely bet on me producing code!! ;-)

 

[Mark Lawrence]

Ok, so i was a bit miffed about the docs bug and felt the need to
vent. Don't tell me you've never griped about anything. ;-)

That's correct. I used to be big headed, but now I'm perfect.

Our, we, how much have you ever contributed to core versions of Python,
or any third party libraries for that matter?

Honestly nothing so far (in the form of code) as it is beyond my skill
set at this time, but not much beyond it!
[snip]

Anyone who has followed me over the past few years should know that
while i can be at times theatrical, slightly narcissistic, and
occasionally belligerent. I am always concerned with moving Python
into a better future.

I can see myself releasing "Python Modules" and contributing to bug
fixes on the "non-core" side of Python in the very near future. I
would very much like to be a part of this GUI fix/replacement as it
would be a great learning experience. As for the core, i would love to
contribute if and when my skills reach that level. But my concern at
this point is to contribute where i can. Updating Python's stdlib in a
way that will benefit everyone (including myself). And the first step
is calling for peoples input.

It would be both selfish and unwise for a person to create a module
and expect it to be blindly adopted without considering the many other
people who belong to this community. This is a community and we need
to include as many as we can into the decision process. For the best
results one must get supporting and opposing opinions. From that
dataset we can put our collective heads together to formulate a
solution and finally produce that solution.

I will be a part of this solution. I hope you will join in whatever
capacity your free time will allow. Even a vote of confidence is a
huge step in the right direction. I think you'll agree that Tkinter
"as-is" just ain't cutting it. One thing "we" as a community need to
do more often is combine our individual strengths into a collective
strength that can be harnessed to achieve some long since forgotten
goals. Guido has forged the path, we must strive to improve python
daily lest his and all your hard work be all for naught.

The above is certainly brilliant for being so beautifully contradictory,
forget programming, move into politics.

As an aside, I couldn't care one hoot about the standard Python GUI, let
alone two, but it strikes me that you have conveniently ignored Mark
Roseman's comments earlier in this thread regarding Tk. I've no idea
how much work would be involved for the Python core volunteers in
introducing newer versions of Tk, and just maybe they've got more
important things to work on, which you might realise if you were to
follow the Python bug tracker mailing list.

Blast, peace not piece.

Mark, with those odds you can safely bet on me producing code!! ;-)

After several years I should bloody well hope so. More coding in an IDE
and less typing on mailing lists might help. And I'm now laughing over
the Windows compiled help file.

Mark Lawrence.

 

[Steven D'Aprano]

Sorry, "Quirk's Exception" to Godwin's Law says that you can't invoke
Godwin's Law on purpose.

I think I need a Downfall video of Hitler discovering Quirk's Exception.

 

[rantingrick]

After several years I should bloody well hope so.  More coding in an IDE
and less typing on mailing lists might help.  And I'm now laughing over
the Windows compiled help file.

Oh Mark really, is that windows compiled help file thing the best you
can come up with? Come on man! There have been far more embarrassing
moments than that! I mean, with my record a bing search could have
produced better results.

Now i'm laughing

 

[Martin v. Loewis]

As an aside, I couldn't care one hoot about the standard Python GUI, let

alone two, but it strikes me that you have conveniently ignored Mark
Roseman's comments earlier in this thread regarding Tk. I've no idea how
much work would be involved for the Python core volunteers in
introducing newer versions of Tk, and just maybe they've got more
important things to work on, which you might realise if you were to
follow the Python bug tracker mailing list.

For the record, Python *does* include newer versions of Tk all the time.
Tkinter builds with about any Tk version you pick at compile time, so
the Linux distributions typically ship Tkinter being bound to recent Tk
versions. The same holds for the Windows releases provided on
python.org; I update Tk for these for every major Python release (but
not for bugfix releases). For OSX, the issue is a little more tricky;
you have the choice of either using the Apple-provided Tk version (which
gets upgraded with OSX releases), or to install a newer Tk version
separately.

Regards,
Martin

 

[Martin v. Loewis]

As an aside, I couldn't care one hoot about the standard Python GUI, let

alone two, but it strikes me that you have conveniently ignored Mark
Roseman's comments earlier in this thread regarding Tk. I've no idea how
much work would be involved for the Python core volunteers in
introducing newer versions of Tk, and just maybe they've got more
important things to work on, which you might realise if you were to
follow the Python bug tracker mailing list.

For the record, Python *does* include newer versions of Tk all the time.
Tkinter builds with about any Tk version you pick at compile time, so
the Linux distributions typically ship Tkinter being bound to recent Tk
versions. The same holds for the Windows releases provided on
python.org; I update Tk for these for every major Python release (but
not for bugfix releases). For OSX, the issue is a little more tricky;
you have the choice of either using the Apple-provided Tk version (which
gets upgraded with OSX releases), or to install a newer Tk version
separately.

Regards,
Martin

 

[Mark Roseman]

For the record, Python *does* include newer versions of Tk all the time.

Martin, just to reinforce the point... developers using Tkinter need to
make some fairly minor changes to their application code to truly take
advantage of the improvements in recent versions of Tk. Without those
app changes, they're not going to see any difference.

To quote from the first section of the tutorial at http://www.tkdocs.com

This tutorial is designed to help people get up to speed quickly with
building mainstream desktop graphical user interfaces with Tk, and in
particular Tk 8.5, which is an incredibly significant milestone release.

The downside is that unless you know one or two particular things, it's
actually not that significant a release; For backwards compatibility reasons,
unless existing programs make a few simple changes, they won't look all that
much different. So while this tutorial will certainly benefit newcomers to
Tk, it will also help existing Tk developers bring their knowledge right up
to date.

Mark

 

[Steven D'Aprano]

1 Although a few advocates of Tkinter have spoken in favour of it, most
seem to think that:
It's not particularly elegant, either in its use or its
implementation with Tcl/Tk
If we didn't have a GUI in the distribution, we wouldn't choose
Tkinter now; it seems like its inclusion
is a sort of historical accident.

I'm not so sure about that. If we didn't have a GUI, what would we
include? There are many alternatives, of course, but nothing that stands
out as "the" obvious choice for the standard library. It seems to me that
the odds are good that Tkinter *would* be choosen today. Particularly
since modern versions of Tk use native widgets and so look better.

It's easy to dump on Tkinter, and I've done so myself, but it's not that
bad all things considering.


[...]

whenever I
write a program that someone else is going to use, it has to have a
GUI. Is that not true for most people?

No. Most Python development is for either the web or the command line.

5 I should stop pontificating, and write code. If it's better than the
existing, people will use it and it will
become the standard.
I don't think so. Even vast libraries of well-written code haven't
become the standard.

Not everything needs to be "the standard". I believe GUIs are like that.
The requirements and complexity of GUI toolkits are difficult enough that
having choice between three or four "world-class" toolkits (which slowly
converge on equivalent functionality, if not equivalent APIs) is a good
thing.

So I think comments like "the system doesn't work like that - nothing
happens till code is working" miss the point. We are not talking about
some vital but complex module or library here - it's more important than
that.

No, it *is* the point. This is Open Source. Code walks the walk, and
everything else is just chat. *If* you inspire somebody to take up the
challenge, then great, but otherwise this is just wasted electrons.

If writing the code is too much for you, write a PEP explaining why you
think Tkinter must go and what features you expect in the replacement. Or
do a comprehensive survey of what GUIs are available, and what it would
take to make them part of the standard library.

Even a comprehensive comparison of cost/benefits for GUI toolkits would
be a start. You might find that, when looking at what *actually* exists,
and how high the bar is even for an entry-level toolkit, Tkinter starts
looking better and better. Or not. Who knows? Until somebody does the
work, it's all just opinion, and unjustified opinion at that.

We are talking about the thing that the rest of the world sees as
Python's biggest missing piece - the thing that beginning programmers
look for and don't find - a decent, well- supported and elegant GUI.

I disagree. It's not 1995 any more. As much as it pains me to acknowledge
it, the world has moved on and the cutting edge is in the browser, not
the desktop. That's not to say that desktop apps aren't important, they
are, but the web is where all the action is.

 

[Martin v. Loewis]

Martin, just to reinforce the point... developers using Tkinter need to

make some fairly minor changes to their application code to truly take
advantage of the improvements in recent versions of Tk. Without those
app changes, they're not going to see any difference.

To quote from the first section of the tutorial at http://www.tkdocs.com

Unfortunately, neither that tutorial nor your postings are really
specific on what those changes might be. So I'm skeptical that they
actually exist, or, if they exist, that Tkinter needs to change at all
to accomodate them.

Regards,
Martin

 

[Kevin Walzer]

Unfortunately, neither that tutorial nor your postings are really
specific on what those changes might be. So I'm skeptical that they
actually exist, or, if they exist, that Tkinter needs to change at all
to accomodate them.

The changes that need to be made are to incorporate the new themed Tk
(ttk) widgets into your Tkinter application--based on Guilherme Polo's
work integrating the new widgets into the stdlib.

 

[Mark Roseman]

Unfortunately, neither that tutorial nor your postings are really
specific on what those changes might be. So I'm skeptical that they
actually exist, or, if they exist, that Tkinter needs to change at all
to accomodate them.

Ok, take a look at the last section on this page then:
http://www.tkdocs.com/resources/backgrounder.html

The change is the new so-called 'themed' widget set (ttk), which
complements but does not replace the standard widgets. And yes, Tkinter
would have to change a bit to use that widget set.

Luckily enough, that work has also long been done (thanks to Guilherme
Polo) and is a standard part of Tkinter as bundled with Python.

As for the changes that need to be made to Python application programs
to use these 'ttk' widgets instead of the classic Tk ones, the TkDocs
tutorial describes that in detail.

I trust that spending a few additional minutes with this material (or
doing a Google search on 'ttk widgets') will help address your
skepticism that changes were in fact made, and that these changes are
being used everyday by developers working with Tk in Python, Ruby, Perl,
Tcl and more.

No question that awareness of these significant changes is far too low,
and that perhaps some of the energy devoted to anxiety about Tkinter's
shortcomings could be better spent learning about or communicating this
information to developers who might easily benefit.

Mark

 

[bart.c]

I'm not so sure about that. If we didn't have a GUI, what would we
include?

Is the Tkinter GUI also the basic way that Python handles a graphics
display? (I've never tried it.)

If it is, then perhaps it's possible to split the purely graphical drawing
stuff (which is simple) from the dialog/widget stuff (which is not so
simple).

A library for graphical display, plus basic user-input, should be
straightforward to implement. And can be used to produce crude (non-native)
GUIs.

 

[Gregory Ewing]

Doesn't Mac uses an X server as well?

You can run one optionally if you want, but its native
graphics system is *not* based on X11. It has a window
server, but the protocol is completely different. The
details are shrouded in mysteries known only to Apple,
but I gather it's based on PDF drawing operations.

As far as I know, there is no separate "window manager"
process -- the window server itself takes care of
drawing and managing the window decorations, and there
is no published way of overriding how it does that.