From: lkcl on
[ye gods, i think this is the largest thread i've ever seen, but i
still feel compelled to wind back to the beginning and spew forth

On Jun 6, 2:22 am, ant <shi...(a)> wrote:

> I get the strong feeling that nobody is really happy with the state of
> Python GUIs.

yep. that's why i ported pyjamas, which was a web-only/browser-only
UI toolkit, to the desktop. it's a _real_ eye-opener to try to use
the "failed" ports of pyjamas to both pygtk2 and pyqt4, which you can
still get at - see pyjd-pyqt4
and pyjd-pygtk2

these failed ports give you the clearest and bluntest indication of
the failings of pyqt4 and pygtk2. after using those two "top"
mainstream python GUI widget sets, i didn't try any others.

> Whether or not we like graphics programming, it's not going to go
> away.

no you're right, it's not.

... but as web browser technology development continues to
accelerate, the top mainstream GUI technology (not just python GUI
technology) is going to look more and more archaic in comparison.

> I ask the group; should we try to create a new GUI for Python, with
> the following
> properties?:
> - Pythonic
> - The default GUI (so it replaces Tkinter)
> - It has the support of the majority of the Python community
> - Simple and obvious to use for simple things
> - Comprehensive, for complicated things
> - Cross-platform
> - Looks good (to be defined)
> - As small as possible in its default form

i invite anyone considering starting a new python GUI project to
consider these questions:

* how much effort has been and is being spent, right now, on
developing and debugging each of the python GUI widget sets, as
compared to the efforts on web browser technology (MSHTML, KHTML ok
maybe not kHTML, WebKit, XulRunner)? (put another way: how long have
web browsers existed and how much user-market-share do web browsers
have, compared to GUI and python GUI widget sets?)

* are python GUI widget sets easy to compile cross-platform, as
compared to web browser technology which is _definitely_ cross-

* how easy is it to extend the existing python GUI widget sets with
"new" or "custom" widgets, as compared to web browser technology where
you can manipulate bits of DOM? if you're not sure of how simple/
complex each task is, read and compare these:

* how easy is it, using the "new" or "custom" widget extension
methodology of existing python GUI widget sets, to extend that widget
set to "keep up" with modern GUI advancements and user expectations,
as compared to enhancing web browser technology?

actually, this is a deliberately misleading question, but it at
least illustrates that it's damn hard for GUI widget set developers to
"keep up". in fact, many GUI widget set developers are actually
embedding web browser technology as a widget in order to avoid the
problem! (pywebkitgtk, pyqtwebkit etc.)

* better question: how much time and money by large corporations with
their associated vested interests is being invested into python GUI
widget sets, as compared to how much by those same corporations into
the W3C DOM Standards process and the resultant improvements and
advances in web browser technology?

* final question: how easy is it to create python "wrappers" around
DOM browser technology, thus leveraging and riding on the back of the
_vast_ amounts of effort and money being poured into web browser

answer for MSHTML (aka Trident Layout Engine): using python-comtypes
- 3 weeks.

answer for WebKit: using glib/gobject and pygobject "codegen" to
augment pywebkitgtk - 12 weeks

answer for XulRunner: using python-hulahop and python-xpcom - 2

answer for Opera's engine: unknown, because the developer hasn't
responded yet. (it's qt-based, so it would be estimated around 12
weeks, if they haven't already done the work).

so can you see where this is at? and that's why pyjamas/pyjamas-
desktop exists. a _completely_ non-corporate-funded, _tiny_ team is
riding on the back of the vast amounts of money and resources
available to google, apple, nokia, microsoft, mozilla foundation and
so on, and we're sitting back and offering it as free software to
people to create applications that are as powerful as the underlying
web technology on which the pyjamas UI toolkit is based.

and with the addition of WebGL (3D SVG) and HTML5 (Video etc.), web
technology is becoming pretty powerful.

so this is why it can be claimed that pyjamas competes with
silverlight and with adobe AIR/Flash, and it's not to do with pyjamas
"per se": pyjamas is just a "leveraging" technology to get at the
underlying power of the web engines. (the claim _does_ however grate
against a lot of egos, somewhat understandably, and with a non-
existent "marketing dept" there's not a lot that can be done about

so let me go over these points again, now wrt pyjs/pyjd "in the frame"
so to speak.

> - Pythonic

yep it is. definitely. part of the reason why pyjamas is 1/10th the
size of GWT is thanks to the dynamic nature of python.

another reason is that we simply left out vast tracts of GWT code
(such as thousands of lines of GWT "internationalisation" support) but
that's another story.

> - The default GUI (so it replaces Tkinter)

can't answer that one.

> - It has the support of the majority of the Python community

_definitely_ can't answer that one :) but i'm betting that, without
reading them, a good 80% of the 222-long discussion so far is in
response to this point :)

> - Simple and obvious to use for simple things

pyjamas is blindingly so. helloworld in 5-6 lines, just like pygtk.
async event handling and well-defined event-receiving functions. etc.

> - Comprehensive, for complicated things

yep. you only have to look at the GWTCanvas examples or the GChart
2D graph/barchart source code (19,000 lines!) to see how "simple" DOM
manipulation can turn into comprehensive applications.

> - Cross-platform

definitely. cross-platform, cross-widget-set _and_ cross-browser,
because, last resort, if users refuse to install pyjamas-desktop, you
can always compile the exact same application to javascript and run it
in every single major modern web browser.

... can pygtk2, pyqt4, TkInter or wxWidgets claim to be cross-
browser? can you recompile a pygtk2 or pyqt4 application and run it
in a web browser, as javascript (actually, there _is_ a
reimplementation of pygtk2 for pyjamas, it was a GSoC 2007 experiment
- about 20-30% completed port of pygtk2 widgets, but it proved the

> - Looks good (to be defined)

that's up to, and entirely under the control of, the developer.

i.e. it's up to the developer to make use of CSS styles and in some
instances bits of HTML to "prettify" the application, and perhaps
makes use of some of the more decorative panels (DecoratorPanel,
CaptionPanel) in combination with some round-curved images and
associated CSS stylesheet.

other than that, the application "looks as good as" the underlying web
browser engine "default" styles. which can be pretty boring, but
that's life, and it's why CSS stylesheets exist. which normal desktop
GUI widget sets of course can't make use of.

> - As small as possible in its default form

pyjamas is pretty damn small, and it's pure python. there's no c
code involved in the actual pyjamas codebase [and probably never will

the main UI library used to be one 4,000-line file: i got fed up with
that and split it into 70 separate modules (one per widget/class) and
the repetition of the license text increased it to 6,500 lines (!).
since that time, about a year ago, the UI code has expanded to about
9,000 lines, with the addition of some GWT-ported widgets, contributed
by users as GWT itself has developed.

the pyjd DOM "wrapper" technology (which is responsible for creating
a window and firing up the users' app under each of the three pyjd
ports) is a total of 4,000 lines, but you don't need to know anything
about that: it's just a "tool". i mention it out of sheer fascination/
horror as to how to leash and tame a behemoth (such as a W3C DOM
compliant browser engine).

the pyjs compiler used to be 1200 lines, and is now 4,000 - but
again, it's a specialist "tool" that has _nothing_ to do with the UI
toolkit itself: you just use it, just as you use "gcc" and don't
include "gcc" itself as part of your application.

so, i hope that i'm steering you away from considering creating yet
another python GUI widget set, and i leave you with this irony: the
pyjamas desktop ports, thanks to their browser engines, actually use
"raw" Win32 GDI in the case of the MSHTML port; GTK in the case of the
xulrunner port; and GTK again in the case of the pywebkitgtk port.
there _is_ a pywebkitqt4 experimental port as well but the DOM
bindings to pywebkitqt4 are virtually non-existent: you have to
actually use and execute javascript code-fragments (from python
*shudder*, *quiver*) and try to prise the resultant bit of DOM out of
the JS engine's cold, dead fingers, and create a proxy class to
nurture it back to life in the python world. but, as far as pyjamas
developers are concerned, all that is completely irrelevant: you just
"get on with it".


p.s. come along to 19-24 july 2010, birmingham,
From: lkcl on
On Jun 6, 10:49 pm, Kevin Walzer <k...(a)> wrote:
> > - Pythonic
> > - The default GUI (so it replaces Tkinter)
> > - It has the support of the majority of the Python community
> > - Simple and obvious to use for simple things
> > - Comprehensive, for complicated things
> > - Cross-platform
> > - Looks good (to be defined)
> > - As small as possible in its default form
> These goals are not all complementary. In fact, some of them, such as
> "small" and "comprehensive," are mutually exclusive.

that's not quite true - you can create a simple core which is easily
extensible with third party contributions to create more comprehensive

in the GWT arena, you have gwt-g3d, gwt-incubator, gwt-gchart and so
on, all of which were created very easily thanks to the power of the
underlying GWT core codebase, _none_ of which are actually included
into GWT by default, _all_ of which can be installed by users and
simply "imported" just like the core.

now s/GWT/pyjamas and you have the exact same thing, and all the
satisfiable requirements are met.

From: lkcl on
On Jun 6, 10:55 pm, ant <shi...(a)> wrote:
> On Jun 6, 2:22 pm, ant <shi...(a)> wrote:> I get the strong feeling that nobody is really happy with the state of
> > Python GUIs.
> <snip...>
> What an interesting set of responses I got!
> And - even more interesting - how few of them actually seem to think
> there is a problem, let
> alone make any attempt to move the situation forward.
> I appreciate that there are proponents of many different GUIs. I am
> asking that all step back
> from their particular interests and - for example - try to see the
> situation from the viewpoint of
> - say - a Python newbie, or an organisation that is thinking of
> switching from (example only!) Visual Basic.
> I obviously didn't make my main point clearly enough; I'll restate it
> with a different emphasis:
> The default GUI shipped with Python is Tkinter.
> Few people seem to like it much. This has several consequences.
> - It has not blossomed, like Python has.
> - There are not hundreds of talented programmers making rapid and
> impressive improvements to it.
> - Books about Python use it in examples (because it IS the default),
> but imply that one should move on.
> The result that our hypothetical new recruit has to make a choice for
> the new, big project. Remember that
> GUIs have hundreds (sometimes thousands) of classes, functions and
> constants. Let alone idioms and design
> patterns. That is what I meant by 'Our resources are being
> dissipated'; the effort of learning, remembering
> and relearning a workable subset of these is substantial.
> So it would be good to be able to use One Right Way, not try several
> (as I have - I will admit I didn't try PyQt;
> GUI fatigue was setting in by then).
> If we are to make progress, I can see two obvious approaches:
> 1) Improve Tkinter to the point where it is supportable and supported
> by a good fraction of Python programmers
> or
> 2) Drop Tkinter as the default and use something else.
> If we choose 2) then we have a new set of possibilities:
> 2a) Use one of the 'major' GUIs, pretty much as is, but presumably
> with a lot more people supporting it if it is the default.
> 2b) Use one of the 'minor' GUIs, and get a lot of people working on it
> to make it really good.
> 2c) Start from scratch. With a project supported by the Community as a
> whole, with the agreed objective of being the default.
> None of these is easy. All require strong leadership and great
> committment.
> What surprises me is the apparent willingness of the Python community
> to let this issue slide.

ah - i think... i believe you may be confusing realism with
fatalism. experienced python developers are also experienced,
specialist c programmers (amongst other things) and experienced
software engineers. they've been around a while (10+ years). they
_know_ how much effort is involved in creating a major project such as
a GUI widget set (and you can get a wildly-wrong but nevertheless
useful answer from statistics, by going to
for example)

so, spec'ing it out, we _know_ that to create a decent GUI widget
set, from scratch, in c (to make it fast enough) would be... ye
gods... 50 man-years of effort, minimum? you _might_ be able to
reduce that by using somebody else's library (libcairo, libpango)
but... just... _why_??

so this was why i went "f*** that!" and "leveraged" web browser
technology, jumping from virtually nothing (an abandoned python-to-
javascript compiler project) to a world-class GUI toolkit, in under 18
months of _part time_ effort.

> My concern is simple: I think that Python is doomed to remain a minor
> language unless we crack this problem.

ah. take a look at that chart that keeps cropping up every now and
then: python is _not_ a minor programming language. most likely due
to django, it's rated about 7th with about ... i think it was 6%
share. perl is now _under_ 4%!

so i don't believe there are any concerns there: python has enough
alternate uses other than as a GUI toolkit to keep it going :)

From: lkcl on
On Jun 7, 9:25 pm, Arndt Roger Schneider <>
> Terry Reedy schrieb:
> Forget postscript!
> Generate SVG from  a tk canvas or --better-- from tkpath.
> Jeszra (from me) generates SVG. There is also a SVG export

... orr, you use a modern web browser engine such as XulRunner 1.9
(the engine behind FF 3+), or webkit (the engine behind arora, midori,
safari, android, chrome, palm's webos, adobe AIR, iphone, ipad,
appcelerator, nokia S60 browser, the IE chrome plugin, blackberry 4
OS's web browser, and god knows what else).

and you create python bindings to that modern web browser engine, and
you can then use DOM manipulation (like javascript, only in python) to
get at those SVG functions, and much much more.

... how does that sound?

> Will any big GUI-Framework work on those devises?
> No!

yes. called a web browser. most likely a modern webkit-based

> Will SVG run on thoses devices?

yes. in the webkit-based web browser. or the "opera mini" browser.
etc. etc.

From: Kevin Walzer on
On 6/12/10 9:44 AM, lkcl wrote:
> that's not quite true - you can create a simple core which is easily
> extensible with third party contributions to create more comprehensive
> widgets.

That's exactly the design philosophy of Tk: a small core widget set
(recently expanded somewhat with the ttk widgets) and an API that is
easily extensible, either at the script level (megawidgets, cf. using an
entry widget and a listbox to build a combobox) or at the C level (more
complex, but hardly impossible).

I've used a browser-based app before (Adobe AIR app running in IE) and
while it wasn't horrible, I certainly did not prefer it to a native
desktop app: I got sick of waiting for the app to reload because of a
slow network connection.

Kevin Walzer
Code by Kevin