GUIs - A Modest Proposal

[Kevin Walzer]

<snip>

Of course i was just being theatrical alex, i hope your last post was
in the same manner. However your right about everything you said
except your accusations that i am not willing to help bring this into
reality -- i just need to find the right base... and i may have just
found it in PyGUI!!

http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

My first impression of PyGUI is very good because it looks promising,
and of course has a native look and feel. Just grazing over the docs i
was very impressed. Greg has outlined some simple and clear goals
which are exactly what Python needs in a GUI. He has the vision and
quite a bit a code already written. Heck he even has an OpenGL hashed
already. From what i can see so far the API very Pythonic. I think
it's love at first sight really. I encourage others to take a look at
PyGUI and see what they think. Judge for yourself.

I have no opinion on the merits of PyGUI itself, but after taking a
quick look at the site and the docs, it seems to be an abstraction API
over three different, platform-specific GUI toolkits--PyObjC (Mac),
PyGtk (X11) and Windows (pywin32). That means that, whatever its other
virtues, it certainly is *not* a lightweight GUI toolkit that could
easily be incorporated into the Python core library--it instead has
rather complex dependencies on both other GUI toolkits and Python
wrappers of those toolkits. (A wrapper of a wrapper of a wrapper....)

In my view, any original, Python-native implementation of a GUI toolkit
that is small enough to be included in the standard library will wind up
looking much like Tk. Tk implements its own API on each of the major
platforms, interfacing directly with the platform primitives at a low
level (Xlib, Carbon or Cocoa, and win32); it uses native widgets if they
map to its API and implements its own widgets in other cases. Because it
sticks to a limited widget set, it's able to to be small.

Since Tk already provides a basic GUI toolset, and Python can interface
with it more directly than it can with other toolkits (PyGui -> PyGtk ->
Gtk -> Xlib), it's not clear to me what is gained by starting from
scratch here. (Is it the presence of the Tcl interpreter? I know Tcl is
not to everyone's taste, but it is an amazing language...)

--Kevin

 

[Adam Tauno Williams]

Since Tk already provides a basic GUI toolset, and Python can interface
with it more directly than it can with other toolkits (PyGui -> PyGtk ->
Gtk -> Xlib),

"Python can interface with it more directly"

This statement is devoid of meaning.

 

[Grant Edwards]

Since Tk already provides a basic GUI toolset, and Python can interface
with it more directly than it can with other toolkits
(PyGui -> PyGtk -> Gtk -> Xlib),

Compare that to this:

TkInter -> Tcl -> Tk -> Xlib

it's not clear to me what is gained by starting from scratch here.
(Is it the presence of the Tcl interpreter? I know Tcl is not to
everyone's taste, but it is an amazing language...)

It's not clear to me that Tk is any more "direct" than any of the
other options.

 

[bart.c]

Compare that to this:

TkInter -> Tcl -> Tk -> Xlib

Is the Tcl intepreter really need to use this GUI? Why not:

(Pyton ->) Tkinter-API -> Xlib ?

Most of the work of designing a GUI is, well, designing it. That's already
been done for Tkinter so why not just implement the same spec in Python
(with whatever lower-level code is needed). Then extending it should be
simpler.

Some people aren't interested in the amazing language. Only the graphics API
that goes with it.

 

[David King]

My concern is simple: I think that Python is doomed to remain a minor

language unless we crack this problem.

But making *another* "one true GUI library" just fragments it further.

Nobody designs a GUI library intending it to suck.

 

[Terry Reedy]

Terry Reedy schrieb:

That was it! Be aware only tk canvas elements are exported to SVG by this
package.

That is all I need at the moment, with no embedded controls, just lines,
fills, and a few text labels.

> Jeszra on the other hand converts an entire GUI into SVG.

I had the impression, without diving deeply into the doc, that jeszra is
not something I can call from a Python program but is a stand-alone app
for designing guis, with one of the output possibilities being svg and
another tkinter-based classes that could be used in a Python program.

I will look into it further when I need that.

I don't have any experience with this python package--for obvious reasons.
What you should look after is how raster images are included in the
generated SVG; and try each of the 12 different arrow shapes for tk line.

Thanks for the hint.

Terry Jan Reedy

 

[Grant Edwards]

Is the Tcl intepreter really need to use this GUI?

Technically, no. But, that's what the maintainers have chosen to do
in order to reduce the amount of work needed.

Why not: (Pyton ->) Tkinter-API -> Xlib ?

Because maintain a set of Python bindings for Tk would be a lot more
work.

Most of the work of designing a GUI is, well, designing it. That's
already been done for Tkinter so why not just implement the same spec
in Python (with whatever lower-level code is needed). Then extending
it should be simpler.

I'm not sure what you're asking. Are you asking why not develop
Python bindings for the Tk library the way other languages (e.g.
Scheme) did instead of having Tcl as a glue layer?

Some people aren't interested in the amazing language. Only the
graphics API that goes with it.

Some of us think is a crappy language. I wrote one small app in Tcl.
When I tried to write something a bit more sophistacated it was quite
clear that Tcl is a glue language, not a real application development
language. I switched to Scheme (which had Tk bindings) and later to
Python.

 

[Carl Banks]

Because maintain a set of Python bindings for Tk would be a lot more
work.

That would be Tk-API.

Tkinter-API means write a GUI toolkit that has the same API as
Tkinter, which is s Python module. So he suggests a native Python
toolkit (written as Python code or a C extension or both), that can
serve as a drop-in replacement for Tk-inter, that bypasses Tcl and Tk
altogether.

In the absense of other factors, it probably is better for an
interpreter for a language that claims to be a powerful for general-
purpose applications not to run another general-purpose interpreter to
do a common task like GUI. Those other factors aren't absent though.


Carl Banks

 

[Martin v. Loewis]

TkInter -> Tcl -> Tk -> Xlib

Is the Tcl intepreter really need to use this GUI? Why not:

(Pyton ->) Tkinter-API -> Xlib ?

Even if this was possible (which it is not), then you still would need
the Tcl interpreter: significant parts of Tk are written in Tcl, so
Tk won't work without the Tcl interpreter.

However, the Tk API doesn't provide all functionality that Tkinter
exposes; many features can only be invoked through Tcl.

Regards,
Martin

 

[Grant Edwards]

Even if this was possible (which it is not)

Why is it not possible? It seems to have been done for other
languages.

then you still would need the Tcl interpreter: significant parts of
Tk are written in Tcl, so Tk won't work without the Tcl interpreter.

However, the Tk API doesn't provide all functionality that Tkinter
exposes; many features can only be invoked through Tcl.

True. Were Tcl removed from the equation, then some feautures would
have to be re-implemented in Python.

 

[Ethan Furman]

Why is it not possible? It seems to have been done for other
languages.


True. Were Tcl removed from the equation, then some feautures would
have to be re-implemented in Python.

So what functionality is available from Tk alone? From the very cursory
glance at the source files (mostly the readmes), it seems pretty
entwined with Tcl.

~Ethan~

 

[Kevin Walzer]

Some people aren't interested in the amazing language. Only the graphics
API that goes with it.

The Perl folks have stripped the Tk API away from Tcl with the Perl-Tk
GUI package: the result is no embedded Tcl interpreter, but it's also
hard to maintain. In fact, Perl-Tk has never been updated to run
natively on the Mac because of this. There are other Perl/Tk bindings
that do integrate the Tcl interpreter, and it makes it much easier for
the Perl/Tk bindings to evolve as Tk itself evolves.

 

[Lie Ryan]

Is the Tcl intepreter really need to use this GUI? Why not:

(Pyton ->) Tkinter-API -> Xlib ?

Most of the work of designing a GUI is, well, designing it. That's
already been done for Tkinter so why not just implement the same spec in
Python (with whatever lower-level code is needed). Then extending it
should be simpler.


Some people aren't interested in the amazing language. Only the graphics
API that goes with it.

How about shifting the viewpoint a little bit. Tcl is like regular
expression engine and the Tk is like the re API.

Much like regex a DSL for matching text, Tcl/Tk is pretty much a DSL for
creating GUI (anyone knows any real program fully written in
non-embedded Tcl?).

Nobody complains that python included a regular expression engine in its
standard distribution; so why complain that python included a Tcl
expression engine in its standard distribution.

 

[Martin P. Hellwig]

<cut>
Yes indeed, however gp forgot another step:
tkinter > tcl > tk > xlib/xcb > x server
There are already some more or less usable (though they look abandoned)
experiments that do this:
https://launchpad.net/twisted-x11
http://python-xlib.sourceforge.net/

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
and windows (for example to define your own window decoration).
Though considering tk does just that I would guess this to be the case.

 

[geremy condra]

How about shifting the viewpoint a little bit. Tcl is like regular
expression engine and the Tk is like the re API.

Much like regex a DSL for matching text, Tcl/Tk is pretty much a DSL for
creating GUI (anyone knows any real program fully written in
non-embedded Tcl?).

Nobody complains that python included a regular expression engine in its
standard distribution; so why complain that python included a Tcl
expression engine in its standard distribution.

This is a silly argument.

REs are not full programming languages, even from a theoretical point
of view, aMSN is written in Tcl, as wikipedia would have told you, and
having to depend on the tools of another language to get commonly
desired functionality is not a good thing for a programming language.

Geremy Condra

 

[Martin v. Loewis]

Am 08.06.2010 20:15, schrieb Grant Edwards:

Why is it not possible? It seems to have been done for other
languages.

So you don't know for sure? Which implementation specifically
do you think of?

True. Were Tcl removed from the equation, then some feautures would
have to be re-implemented in Python.

You mean, like the key bindings of all the widgets, and the ttk widget
set.

Regards,
Martin

 

[Kevin Walzer]

Much like regex a DSL for matching text, Tcl/Tk is pretty much a DSL for
creating GUI (anyone knows any real program fully written in
non-embedded Tcl?).

http://www.amsn-project.net/
http://snackamp.sourceforge.net/
http://www.svi.nl/
http://installbuilder.bitrock.com/
http://www.gidhome.com/
http://www.ellogon.org/

etc.

 

[Steven D'Aprano]

This is a silly argument.

REs are not full programming languages, even from a theoretical point of
view,

True, but some theoretical extension to REs could be. If I've understood
correctly, Perl's regexes aren't actually regular expressions any more
(they're a superset) and might even be Turing Complete.

In any case, the point is not that you can or can't write your entire
application using a RE. The point is that regexes are a mini-language, a
DSL, not written directly in Python.

aMSN is written in Tcl, as wikipedia would have told you, and
having to depend on the tools of another language to get commonly
desired functionality is not a good thing for a programming language.

I don't see why you think so. Python is specifically designed to be a
glue language, to bring together functionality from disparate components
written in other languages and provide a user-friendly language around
them. Fundamentally, what's the difference between these?

* CPython relies on Tk/Tcl for a GUI

* CPython relies on a C library for regular expressions

* IronPython relies on the .Net environment for everything

* Jython relies on Java libraries for many things

I don't see why that first one is so much worse than the others. Sure, it
adds an extra dependency to installing Python for GUI programming, but
that's no different to any other GUI toolkit: PyQt has Qt as a
dependency, PyGtk has Gtk as a dependency, etc. (I trust you're not
suggesting that every language needs to create its own fully-independent
GUI toolkit that talks directly to the hardware!)

What does it matter that Tk is Turing Complete and Qt or Gtk aren't?

In any case, if you consider Tkinter is harmful, don't use it. It isn't
like GUI programming in Python relies on it, there are alternatives.

 

[Kevin Walzer]

http://www.amsn-project.net/
http://snackamp.sourceforge.net/
http://www.svi.nl/
http://installbuilder.bitrock.com/
http://www.gidhome.com/
http://www.ellogon.org/

etc.

and:

http://www.courseforum.com/
http://www.installjammer.com/
http://www.muonics.com/
http://moodss.sourceforge.net/
http://www.inivis.com/
http://www.codebykevin.com/portauthority.html

etc.

 

[Grant Edwards]

Am 08.06.2010 20:15, schrieb Grant Edwards:

So you don't know for sure? Which implementation specifically
do you think of?

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