GUIs - A Modest Proposal

[rantingrick]

I can't see any things about the tcl language that make
it especially good for describing GUIs,

And neither can i. And thats because Tcl's syntax is great for
obfuscation and really nothing more.

Anyone who thinks differently i encourage you to put a Tkinter and
TclTk script of the same GUI side by side and you'll see exactly what
i mean. It's like night and day! Sure Python does make you type a lot
more text but in the end (when maintenance time comes around) which
would YOU rather debug?

And just think, if the balance of the world ever came down to a thumb
wrestling contest. Well then all that finger exercise will pay off
enormously! ;-)

 

[Lie Ryan]

However I don't think that x11 represents that majority (just a gut
feeling I have no data to back this claim up) of gui users, so an equal
solution should be found for windows and macs.

I do think it is technically possible to have your own window manager in
python on x11 but I have no idea if you have equal possibilities on mac

Doesn't Mac uses an X server as well?

 

[Chris Rebert]

Doesn't Mac uses an X server as well?

Nope, it uses Quartz: http://en.wikipedia.org/wiki/Quartz_(graphics_layer)
Apple does offer X11.app though, but that just runs on top of Quartz
and is there to let you run *nix GUI programs.

Cheers,
Chris

 

[Adam Tauno Williams]

* IronPython relies on the .Net environment for everything
Since .Net (effectively) depends on Windows,

100% False; not "effectively" true at all. I run [and develop] .NET
applications on LINUX every day. IL and the CLR are standards.

Fine, then they can ship it with Linux too,

Uhm... they do. At least in every major distro: openSUSE, Ubuntu, ..

just for you. My point stands.

No, you are wrong, factually,

 

[geremy condra]

On Tue, 2010-06-08 at 18:12 -0700, geremy condra wrote:
* IronPython relies on the .Net environment for everything
Since .Net (effectively) depends on Windows,
100% False;  not "effectively" true at all.  I run [and develop] .NET
applications on LINUX every day.  IL and the CLR are standards.

Fine, then they can ship it with Linux too,

Uhm... they do.  At least in every major distro: openSUSE, Ubuntu, ..

Reread my original statement. The point was that IronPython would
ship with Windows (or Linux....) attached to it, not the other way
around.

Geremy Condra

 

[ant]

Since I started this thread, I feel a sense of responsibility for it,
in some bizarre way.
Not to prolong its existence, which is clearly a troubling one for
some, but to try to steer it towards some kind of consensus that will
irritate the least number of people. Or better, that will gain some
kind of support and momentum so that something happens.
And since I have neither a reputation to lose, nor any great fondness
for most of the proposed solutions, I will try to summarise some of
the points made as impartially as I can. And I will add my own
opinions; but a group as sophisticated as
this will be able to spot them...

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.
It may be all right for small projects, but once things get
bigger, you have to throw away what you've done
and use something else.
Not many people use it anyway, so why bother?

2 Most people who have used a GUI have some investment in it. So
arguments about which one is best tend to be
partial and not wonderfully constructive.
Indeed, about the only common thread that comes out seems to be a
general dislike of Tkinter.

3 There is a surprising number of people who think that Python
shouldn't have any 'favoured' association with a
GUI at all. I find that surprising because of my own experience: I
have written a few hundred Python programs
over the last few years, mostly small and almost entirely for my own
benefit. Most of those don't use a GUI. 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?

4 Some think that including any sort of GUI is 'bad'. People can
choose the one they want from the large list available.
I certainly don't want to stop people doing what they want. However
many people have neither the time or the
expertise to decide, and the experience of choosing the wrong one is
a real turn-off.
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.

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

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

And who are the beginning programmers going to turn into? If we do our
stuff right, Python programmers. If not,
Java or PHP or Visual Basic programmers. Or website designers. Or
worse (is there a worse?).

So, to summarise the summary: I reiterate my call. Somebody has to get
Tkinter out of the distribution and replaced
by something that - as a minimum - doesn't get slagged off by nearly
everyone.

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

 

[Adam Tauno Williams]

Since I started this thread, I feel a sense of responsibility for it,
in some bizarre way.
Not to prolong its existence, which is clearly a troubling one for
some, but to try to steer it towards some kind of consensus that will
irritate the least number of people. Or better, that will gain some
kind of support and momentum so that something happens.

The way to build "support and momentum" is to create a project, commit
some code, and demonstrate that it solves the proposed problem. If it
does, and the problem is real, then it will get support.

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.

+1, for whatever "standard" means.

So I think comments like "the system doesn't work like that - nothing
happens till code is working" miss the point.

No. that *is* the point.

We are not talking about some vital but complex module or library here

Yes, you are. A GUI toolkit is at least complex, inherently. Doubly so
[exponentially so?] if you are talking about a cross-platform toolkit
that is in anyway "comprehensive".

So, to summarise the summary: I reiterate my call. Somebody has to get
Tkinter out of the distribution and replaced
by something that - as a minimum - doesn't get slagged off by nearly
everyone.
It can't be me - I don't have the clout

You get "clout", whatever that means, by writing code. This isn't the
senate, it is Open Source.

 

[Jean-Michel Pichavant]

Most of those don't use a GUI. 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?

In the industry, most of the people knows how to use a comand line. In
my company, 99% of the applications written in python have no GUI at
all. 1% being web interfaces anyway.
Developing & maintining a GUI has a tremendous cost compared to the
command line, for a small benifit.

JM

 

[D'Arcy J.M. Cain]

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

"Hitler would have loved Tkinter!"

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

 

[Martin P. Hellwig]

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

How about a meta/meta reference if the poster would apologize now with
'Ich habe es nicht gewusst' ?

 

[Mark Roseman]

I'll venture to say that the path of least resistance (which includes
little or modest development effort) would be for Python to retain
Tkinter in the way it does now, but have Tkinter GUI's magically appear
less horrid.

Guess what? That's already happened. Newer versions of Tk (which
Tkinter uses internally of course) do look much better.

But, there are a few small API changes you'd need to make to Tkinter
programs to see that improvement.

You can find these changes and improvements talked about at
http://www.tkdocs.com

I can pretty much guarantee that continuing to share information about
these new things in Tkinter, and keeping up with modern versions of Tk,
is a whole lot less work than the massive engineering efforts people are
talking about as alternatives.

(Not to say the end results, if they were ever completed, wouldn't be
better going a different way...)

Mark

 

[Mark Roseman]

Is the Tcl intepreter really need to use this GUI? Why not:
(Pyton ->) Tkinter-API -> Xlib ?

The Tk library was not built as a straight C/C++ library that interfaces
to Xlib (or the Windows or Mac libraries), with a Tcl binding on top of
that.

Tk was built expressly as a GUI toolkit for Tcl, and it uses Tcl very
extensively throughout its implementation. While there is a C API, it
does not expose anywhere close to everything you'd need without making
calls to the Tcl interpreter. Whether you consider this a good or bad
thing, that's the way it is.

So removing Tcl from the Tk library is not by any means practical. Of
the dozens of dynamic languages with Tk bindings, almost all interface
to Tk through the Tcl interface.

The one notable exception is PerlTk, which went out of its way to
extract Tcl from Tk, a herculean effort. Though they managed,
maintaining it was virtually impossible, so they are stuck with a 15+
year old version of Tk, taking into account none of the improvements
made during that time. The preferred Perl interface to Tk is a newer
one called pTk, which wraps Tk's Tcl API, meaning it can easily keep up
to date with improvements in Tk. And the wrapper code itself is
frighteningly small, what amounts to an exceedingly clever but minor
engineering effort.

I hope this explains why trying to have Tkinter work without Tcl would
be a non-starter.

Mark

 

[Ethan Furman]

In any case, Python doesn't ship with Tcl and Tk. They are dependencies
*only if you use Tkinter*. It's not compulsory.

So what do you call a fact with quark-like attributes? A quack?

Tcl/Tk do, in fact, ship with the Windows versions. Good reminder that
they may not be there on other platforms, though.

~Ethan~


P.S.
Now that I think about it, actually installing them is optional...

 

[Ethan Furman]

I don't see how the dependencies could be regarded as "complex".
There's more or less only one on each platform, and they're
pretty standard accessories for the platform concerned. You could
say there are two on Linux if you count gtk itself, but you almost
certainly already have it these days if you're running any
kind of desktop at all.

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

~Ethan~

 

[rantingrick]

Since I started this thread, I feel a sense of responsibility for it,
in some bizarre way.
Not to prolong its existence, which is clearly a troubling one for
some, but to try to steer it towards some kind of consensus that will
irritate the least number of people.

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.

Or better, that will gain some
kind of support and momentum so that something happens.

Exactly. Thats the very point that the naysayers miss. Pythons
community is no "field of dreams". Just because you build it, doesn't
mean they'll come. Even if what you build is better, they still
probably won't come, or even give a flying fig.

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 don't think it was an accident. Guido forged the path of Tkinter's
inclusion in Python. From what i understand he wrote most of Tkinter
and IDLE himself! (albeit a very long time ago). This all stems from
"Computer Programming For Everyone". 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.

    It may be all right for small projects, but once things get
bigger, you have to throw away what you've done
    and use something else.
    Not many people use it anyway, so why bother?

The GUI that Python includes will never (AND SHOULD NEVER) be for
winning "GUI of the year" contests. The sheer size of wx or others
prevents their inclusion and rightly so. People need to stop using
this argument because it is a moot point. The GUI must be small,
pythonic, and cross platform. Used only for utility and learning
purposes.

2 Most people who have used a GUI have some investment in it. So
arguments about which one is best tend to be
  partial and not wonderfully constructive.
  Indeed, about the only common thread that comes out seems to be a
general dislike of Tkinter.

And the cycle continues...

# DONT RUN THIS CODE ;-)

import itertools
state = itertools.cycle(['But Tkinter Sucks!', 'So Fix Tkinter!'])
while arguing:

.... print state.next()
# DONT RUN THIS CODE ;-)

3 There is a surprising number of people who think that Python
shouldn't have any 'favoured' association with a
  GUI at all. I find that surprising because of my own experience: I
have written a few hundred Python programs
  over the last few years, mostly small and almost entirely for my own
benefit. Most of those don't use a GUI. 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?

These people are the ones who cannot change with the times. You know
what they say. """ Change with the times or get left behind""". They
would rather hack together a curses front-end than to drop into a GUI,
yes really. You old timers need to get with the program, GUI is here
to stay until wet-ware interfaces take over. So drag yourself into the
21st century (kicking and screaming if necessary)

4 Some think that including any sort of GUI is 'bad'. People can
choose the one they want from the large list available.
  I certainly don't want to stop people doing what they want. However
many people have neither the time or the
  expertise to decide, and the experience of choosing the wrong one is
a real turn-off.
  That, in my opinion, is where a replacement for Tkinter should be
aimed: the beginning graphics programmer.

Tkinter is aimed at the newbie and i would think that was Guido's
original vision. And it's not the worst GUI by far. But we need to fix
it, or abandon it.

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

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.

Writing code guarantee's NOTHING! That is the whole point of threads
like this one. First do research and then write code. Not the other
way round lest you have time to waste.

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

So I think comments like "the system doesn't work like that - nothing
happens till code is working" miss the point.

Exactly! see my last answer.

So, to summarise the summary: I reiterate my call. Somebody has to get
Tkinter out of the distribution and replaced
by something that - as a minimum - doesn't get slagged off by nearly
everyone.

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

Yes we need a leader. Someone who is not afraid of the naysayers.
Someone with Guido's vision. When the leader emerges, the people will
rally.

 

[Brian Blais]

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
Not many people use it anyway, so why bother?

2 Most people who have used a GUI have some investment in it. So
arguments about which one is best tend to be
partial and not wonderfully constructive.

In this whole discussion, I haven't seen anyone mention wax (http://
zephyrfalcon.org/labs/wax_primer.html)

I know that it is not being supported anymore, but the philosophy is
something we can get behind. I have done a fair amount of GUI
programming, and from my personal experience tkinter seems a bit
clunky, and there are some really annoying things (like running a
program from the commandline in OS X which launches a GUI has the
window appear *behind* the terminal program) which make it
impractical for my personal use. Up until recently Qt had odd
license issues, so I leaned toward wx which does not have a very nice
python interface. Much of wax, however, is a thin wrapper around wx,
and is usable even now and is much easier and much more pythonic.

The nice thing about it is that, being a thin wrapper, you can have
all of the power of wx if you want to. From a work-flow standpoint I
often find myself doing everything in wax and then running into a
part of wx that hasn't been wrapped, so I use the ugly wx code within
my wax code for a while and later make the wrapper clean.

I wonder if that sort of philosophy would work: a really nice and
clear, pythonic wrapper around a sophisticated, complex, and complete
GUI framework. It should be thin enough that the underlying GUI
library can be called directly, however, or its usefulness will be
greatly diminished. Depending on how it is designed, it might even
be possible to have a multi-framework wrapping, so that someone could
have a Qt-based wrapper, and another using the same module choose to
have it wrap wx.

I think the codebase for wax would be a very nice start to the
discussion, because it is already almost usable. It is already very
close to what I would consider an ideal GUI framework.

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 guess that answers that one!


bb

 

[Adam Tauno Williams]

The GUI must be small, pythonic, and cross platform.

And how many times have I heard that? I develop GUIs... good luck.
Come back in ten years when you have some working code.

Tkinter is aimed at the newbie and i would think that was Guido's
original vision. And it's not the worst GUI by far. But we need to fix
it, or abandon it.

Or just use a different one. Simple enough.

Writing code guarantee's NOTHING!

NOT writing code does guarantee NOTHING!!

That is the whole point of threads
like this one. First do research and then write code. Not the other
way round lest you have time to waste.
Exactly! see my last answer.

A point cannot miss itself, that doesn't make sense. "code is working"
*is* the point, the whole point, and there is no other point.

Or not, whatever.

Yes we need a leader.

Or we don't.

 

[rantingrick]

In this whole discussion, I haven't seen anyone mention wax (http://
zephyrfalcon.org/labs/wax_primer.html)

I myself would not be opposed to a thin Wx, i think it would be a step
in the right direction. The project looks very interesting although i
have not tried the thing out yet so i can only speak to the idea of
it. The beauty is that at least you're investing your time into
something that scales into professional level GUI building. Wx has a
very large and up to date widget set. With Tkinter you get so far and
then bang, brick wall! Your confined by even TclTk so there is no hope
of escape!

+1 wax

 

[rantingrick]

Or just use a different one.  Simple enough.

Thats not even valid to this argument. Everyone IS free to choose
another GUI already. Please re-read this entire thread, absorb the
contents therein, ponder extensively the pros and cons, and then
formulate an intelligent response. I for one would love to hear some
real input from you.

NOT writing code does guarantee NOTHING!!

just argumentative.

A point cannot miss itself, that doesn't make sense.  "code is working"
*is* the point, the whole point, and there is no other point.

just argumentative.

Or not, whatever.

just really argumentative.

Or we don't.

just more of the same.

Can you give us some real explanations as to why you think Tkinter...

A. should be included
B. should be replaced
C. should be improved

....that are more than just argumentative bile?

 

[Martin v. Loewis]

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

if (objproc) {
register SCM data = TCLOBJDATA((SCM) Tcl_GetObjResult(interp));
res = data ? STk_convert_tcl_list_to_scheme(data) : NIL;
}
else {
register char *s = interp->result;
res = (*s) ? STk_convert_Tcl_string2list(s) : NIL;
}
Tcl_ResetResult(interp);

return res;
}

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.

Regards,
Martin