GUIs - A Modest Proposal

[lkcl]

[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
words.]

On Jun 6, 2:22 am, ant <shi... at uklinux.net> 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 http://github.com/lkcl/pyjamas-desktop - 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-
platform?

 * 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:

   http://www.learningpython.com/2006/07/25/writing-a-custom-widget-using-pygtk/
   http://pyjd.sourceforge.net/controls_tutorial.html

 * 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
technology?

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

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

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

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

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

l.

p.s. come along to http://europython.eu 19-24 july 2010, birmingham,
UK.