GUIs - A Modest Proposal

[lkcl]

On Jun 12, 7:29 pm, Terry Reedy <tjre... at udel.edu> wrote:
> On 6/12/2010 9:26 AM, lkcl wrote:
>
> > [ye gods, i think this is the largest thread i've ever seen,
>
> For python-list, it is possibly the longest this year, but definitely
> not of all time ;-)

 oh dearie me...

> >   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 athttp://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.
>
> Can you expand on this? In brief, What were the 'failings' and were they
> failings of the wrappers or the underlying toolkits?

 the toolkits themselves. it's related to layout, to presentation, but
most of all to the implementation of the most basic widget - Label!
i actually got quite a long way with the qt4 port, after deciding to
deal with Label some other time, but then... ok, best to read on :)

 * in neither gtk nor qt does there exist an "auto-layout" widget
that's equivalent to putting some <span /> DOM objects into a <div />,
to "flow" widgets that wrap around.  yes, you can put words into a
Label and get them to flow, but not _widgets_.

 * in neither gtk nor qt is HTML properly supported.  qt has a
"RichText" widget but it's drastically limited.

 * if in gtk you use PyGTKHTML2 you cannot expect it to take care of
its own width and height: you *have* to set width and height,
whereupon it immediately defeats the container's layout rules.  (and i
just was not prepared to do "onresize" notification throughout the
entiiire UI wrapper toolkit, explicitly implementing W3C DOM rules in
terms of gtk or qt widgets, examining the size of the HTML text after
it had been drawn once, then... gaah.  _no_.)

 * GTKHTML3 does have "flow" capability, and even allows you to attach
widgets to the layout based on the "id" associated with bits of
HTML... but PyGTKHTML3 was dropped because webkit came along, and
everyone loved that so much they abandoned work on making python
wrappers to GTKHTML3.

 * qt4 "RichText" _also_ fails to set width and height correctly and
requires explicit width and height setting, in pixels, which _again_
defeats container layout rules.

 * in implementing a Pyjamas Grid widget using qt4, qt4's Grid widget
turned out to have a bug where the Layout Container classes could only
be added once.  you're _supposed_ to be able to remove the widgets and
the Layout Containers and be able to re-add and re-lay-out the Grid,
but this failed miserably: the widgets _remained_ in-place and were
drawn _twice_.  whoops.

 * developing containers for both gtk and qt4 (one idea suggested to
solve some of the above problems) requires writing c code, and
adoption of the resultant containers by the respective communities.  i
scratched that idea as unworkable.

 * both gtk and qt4 can use webkit to display HTML.  all i ****ing
wanted was a Label widget to display a word or a sentence, not an
entire whopping 12mb library with a runtime overhead of 6mb per
widget!  so the use of pywebkitqt or pywebkitgtk _just_ to implement
pyjamas.ui.Label was absolutely out of the question.

 * there's no way you can apply CSS stylesheets to gtk or qt4 (and
Qt4's RichText certainly doesn't support CSS).  one developer i spoke
to at the time was working on exactly this, for gtk, but it was an
"afterthought" - and more of a GTK "theme".  you certainly weren't
going to be able to add a CSS style on a per-id basis: only to
"classes" of widgets (Buttons etc.)

 the second thing i had to consider was: how the hell am i going to
implement the embedded object tag, using gtk or qt4?  although it _is_
possible to put ... ohh... what is it... you can embed ... something,
i can't remember what it is, but there's a way to put SWF into gtk
apps... well, i realised i was looking at this entirely the wrong way.

 and that was the point at which i went, well wtf am i doing
considering shoe-horning a square peg into a round hole for, when i
can just use webkit with glib/gobject bindings and then python
bindings on top of that, or xulrunner with python-xpcom for that
matter, and dropped both gtk and qt4 like scalding hot coals and made
a beeline for webkit's source code.  hulahop, the missing piece of the
"xulrunner" puzzle, turned up a few months later; once the dust had
settled from those, MSHTML actually turned out to be a breeze.

 so i apologise if you were expecting a short answer, but gtk2 and qt4
_just_ don't cut the mustard.  to be fair: whilst the pyjamas panels
are _supposed_ to be "stable" and "look the same on all engines", it
has to be said that, like GWT, we're relying on the "underlying
browser engines", and they're not entiiirely the same.  you can't work
round _all_ browser bugs without _some_ significant effort.
fortunately, GWT with the staggering amount of money from google
behind them are focussing on doing exactly that, for GWT 2.0: writing
some layout panels which they will _guarantee_ will put the child
widgets in the right damn places, regardless of the browser engine
used.

... we'll just wait until they've completed that work, and run a java-
to-python language translator on them, to turn them into python :)

> > 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?)
>
> Your point that browser widget sets have gotten a lot of competitive
> commercial development is well taken. HTML5 will be even more
> competitive with desktop. It certainly will be a nicee cross-platform
> platform for. for instance, casual no-install open-source games.

 yes.  six so far.  sudoku, lightout and asteroids.  oh, and i did
three multi-player games: backgammon, rummikub and a generic "card-
playing" game.  basically those three were merely moving tokens
around, no actual "rules" as such.  the multiplayer games i haven't
released: they rely on a server.

 although, there _is_ the possibility of porting that port of Quake
entirely to python - the one that was ported from java to GWT using
GWT-G3D, the wrapper around WebGL, and still ran at 30fps as
_javascript_ for goodness sake.  that would sufficiently rock that i'm
giving it serious consideration.

 i'm also looking forward to doing sound-effects, using the new HTML5
<audio /> tag.  or whatever.


> >    http://www.learningpython.com/2006/07/25/writing-a-custom-widget-usin...
> >    http://pyjd.sourceforge.net/controls_tutorial.html
>
> The latter has a link tohttp://pyjd.sourceforge.net/controls/

 mmmm... maybe http://pyjs.org hmmm must sort that all out.


> 3 Suggestions:
>
> 1. 'type' is a built-in function. Reading a line like the above is
> jarring to me. Use 'etype' for the event type.
>
> 2. I belive the above is equivalent to
>
>      if etype in ("mousedown", "mouseup", "mousemove" "mouseover",
> "mouseout"):

 free bugreporting for pyjamas, yaaaay! :)
 http://code.google.com/p/pyjamas/issues/detail?id=419

 thank you terry.

> which would fit github's (soft) limit and be clearer and faster.
>
> 3. Until you can persuade github to change, with a better explanation of
> the needed change than I can give, keep to their line limit for code you
> expect others to look at.

 i consider that a bug in pyjamas: the lines shouldn't have gone over
79 chars.  thanks for noticing.

> I enjoyed the rest of the post. When I need to do gui stuff, I will
> definitely look at pyjamas as an alternative to desktop-only kits.

 it's not all roses: the free software pyjd dependencies are not
within our control (pywebkitgtk and xpcom+hulahop), but i can still
definitely recommend it. seems to be taking off, too, which is nice.

 l.