re pygui as a standard gui api for python

Re: PyGUI as a standard GUI API for Python?

Source: http://coding.derkeiler.com/Archive/Python/comp.lang.python/2008−10/msg01302.html

From: lkcl <luke.leighton@xxxxxxxxxxxxxx>• Date: Sat, 11 Oct 2008 02:19:24 −0700 (PDT)•

On Sep 3, 4:34 pm, Michael Palmer <m_palme...@xxxxxxxx> wrote:

So far, development of PyGUI seems to be a one−man effort, and it maybe slowed down by the attempt to develop the API and theimplementations concurrently. Could it be useful to uncouple the two,such that the API would be specified ahead of the implementation?

michael, i went back to the beginning of this thread, to reply to yourquestion, because i have some insights to share with you from myfailed attempts on porting pyjamas to the desktop − which you cancollect here: http://lkcl.net/pyjamas−desktop

there, you will find an IronPython−GtkSharp port; a pyqt4 port and apygtk2 port. they were each failures in their own unique and specialways.

to explain: pyjamas is a widget set api that looks desktop−like; youwrite code in python, it's compiled to javascript; the DOM.py moduleactually does things like document.getElementById() etc. etc. and inthis way you end up completely manipulating the DOM model, turning thebrowser into just a giant desktop−like canvas.

in fact, the pyjamas widget set api is _so_ similar to a desktop apithat i decided to have a go at porting it _to_ the desktop.eventually i succeeded.

the first attempt was with ironpython. i actually got a long way withthis one − i chewed through the pyjamas examples in about a day. ihad a small stumbling block implementing the HTML() widget, butGtkSharp.HTML came to the rescue, there, and i was off again.i then ran into a wall i decided not to bash my head against at suchan early stage (36 hours) − an implementation of XMLHTTPRequest(remember − i was implementing every single bit of functionality thata DOM model has access to).

so, i decided to port the ironpython port to pygtk2. unfortunately,


Re: PyGUI as a standard GUI API for Python? 1

http://coding.derkeiler.com/Archive/Python/comp.lang.python/2008-10/msg01302.html

mailto:[email protected]

http://lkcl.net/pyjamas-desktop

whilst i got a lot further and managed to implement all of theexamples, there was no equivalent of HTML(). GTK itself totally lacksa rich media content widget. there is python−gtkhtml2 which is good,but not good enough. the much better gtkhtml3 library doesn't havepython bindings around it, and i wasn't in the mood to write any (andhadn't at the time any experience with pygtk codegen.py).

also i heard that gtkhtml2 had been abandoned, and gtkhtml3 wasn'tgoing to be followed up on, and that there were rumours about webkit.

crucially − much more importantly − gtkhtml 2 and 3 have absolutely no"automatic" resizing of the HTML content within them. so, unless youspecify both the width and the height of the widget container, you endup with a flatlined widget. by that i mean a widget of say 200 pixelsin width but ZERO pixels in height! and, as you may well know, if youspecify a width and height on a gtk widget, that's it: it's entirelyfixed. there's no going back. you're screwed.

this was an absolute killer.

with no foresight in the design of gtk or gtkhtml2 to make even a_guess_ at the width and height of the content, the port was screwed.i made half−hearted attempts to not specify width/height at all, butall that that resulted in was piss−poor layout, and when you shrankthe app to small size, all the text disappeared because there was amargin defaulting to 5px or so and all but the top left corner of thetext boxes would disappear!

so, there was no point in me attempting to make python bindings aroundgtkhtml3, even though it has a system for inserting widgets into HTML(using span ids).

and, even though there's python−gtkmozembed wrappers which would haveallowed me to embed flash plugins etc. into my application, thusneatly emulating the way that html allows you to do that.

so − sadly − on to pyqt4.

well, i say sadly, but it was actually quite fun. i'm doing acomplete comprehensive test of absolutely every single feature of themajor widget sets out there, crawling every single corner of theirfunctionality in order to map concepts one−for−one, and finding thatthey don't really cope.

pyqt4. again, i got a long long way. the rich media support of qt4allowed me to do widgets that looked reasonable. i even had, by thattime, a non−asynchronous version of XMLHTTPRequest. then i got to theimplementation of Grid() and FlexTable(). this is where it started togo wrong.

pyqt4 has the concept of layouts. a layout can be a horizontal



layout, vertical, grid, and you can even specify the percentage orratio of the width (or height) that individual cells can use. youattach a layout to a widget; you can attach layouts to layouts. youcan remove layouts from widgets. what you _can't_ do is _remove_layouts from layouts.

disappointingly, this was the killer, for me. it was just getting...too complicated. i had already encountered advice that, in order toimplement the means to move widgets around, i should remove*everything* and redo the layout. it just... wasn't happening.

plus, i think also that there are problems, again, with the HTMLlayout: you can't _entirely_ stop text−squashing. so, although pyqt4was _better_, it still wasn't _enough_.

so, i was _almost_ ready to give up, entirely, when i'd heard aboutwebkit − http://webkit.org − and this looked _perfect_. the only down−side: it didn't have python bindings. a quick search showedpywebkitgtk.

so, i decided to try something absolutely awful: wrap the_javascript_! i augmented pywebkitgtk, thanks to some assistance fromthe author of midori i borrowed some of his code and made it possiblefor pywebkitgtk to execute javascript code−fragments (equivalent ofeval and exec). except, immediately i ran into a problem: how to passin function call arguments. i decided against doing func_codegrunginess and creation of variable scope management to emulate pythonlocal function call context (!!!) and instead... insanely...

.... dived straight into adding glib bindings around webkit, with aview to then doing python−bindings around the glib bindings, usingpygtk2's "codegen.py". ... cue piped elevator music and such−like, tosubstitute for two weeks of intensive programming, involving python, c++, perl, c ... suffice to say: it worked. it actually bloody worked.

very very quickly, i was able, once i had the glib bindings, to portpyjamas to webkit. i had my first succesful hello world within underan hour; i had most of the examples done within 18 hours orthereabouts; the entire port was completed within about five days,because i had to go back and add extra functionality such as eventhandling and XMLHTTPRequest.

when i say "done" i mean that you can do eeevvverrryything thateveryone keeps lamenting about that pygtk2 and pyqt4 lack. completeand full support for CSS stylesheets. complete and full support forembedded plugins (such as adobe). complete and full support for HTMLsyntax. _proper_ HTML, not a subset. you even get the added bonus ofbeing able to execute javascript fragments, if you're feelingparticularly obtuse.

and, with a few days extra work on the glib bindings, you'd even be



http://webkit.org

able to run SVG canvas from python (whereas at the moment, you'd haveto do it as javascript fragments).

the moral of the story is that web browser technology makes for a hellof a lot better widget set than a desktop−designed widget set does. a_lot_ better. there's been far more effort put into it, for a start.browsers are designed to make the content look "readable" in far morecircumstances − hostile and conflicting circumstances − than desktopapps are. we stare at browsers far more than we do at desktop apps,for the most part.

and so, you get things like text flowing neatly around, and evenwidgets flowing neatly. _properly_. you can even specify, thanks toCSS styling, whether you want the "flowing" to be vertical−first orhorizontal−first.

imagine trying to implement that with GTK2 or QT4 − it'd be a_nightmare_ gone wrong. yet, browsers have been doing text−flowingand div−flowing for... forever.

now, at this point, having got what i wanted, i didn't want to spendtime on wxWidgets, but i can imagine that there would be similarlimitations.

the issue with implementing a widget set is that there is a veryspecific set of functionality that is absolutely absolutely required,and without every single bit of functionality, you are entirelywasting your time to make the port. threading. timers. rich text(aka HTML). event handling including window resize, onload, mouseover, in, out, move; keyboard handling; asynchronous externalcommunication with the rest of the world. embedded plugins. layoutmanagement, including horizontal, vertical, grid and flow, with_decent_ cell proportion subdivision of available space, and respectfor minimum widths / heights as well as fixed widths / heights.

without _all_ of these things, done properly, you're hosed before youeven begin to create your widget set "wrapper".

GTK lacks flow−layout, rich text support and proportion subdivision oflayouts, making every GTK application in existence look utterly...shit. scuse my french. fortunately, someone's come to the rescuewith a gtk theme engine which allows you to customise gtk with CSSstylesheets, but it is early days yet.

_other_ than these significant failings, GTK is technically prettydamn good and provides everything else you'd need − includingembedding flash and other plugins by leveraging mozplugger − in aneasy−to−use and well−documented fashion.

QT4 lacks crucial layout management (layouts not being deletable fromlayouts), flow−layout, and variable−sized rich text. they _do_ have



proportional subdivision of layouts (allowing you to specify a fixedwidth on one cell and a percentage width on others) but it is veryclumsy.

other than those failings, which are less than those of GTK2 but asequally significant, QT4 _looks_ better than GTK2 but ... it's stillnot good _enough_.

when you've written an app with pyjamas−desktop, and it looks good nomatter whether you resize the window to 1200x800 or down to 320x800,because you cater for onResize events and reformat the layout, _then_you know you're on to a winner [my first ever pyjamas app was my ownweb site − http://lkcl.net/site_code − see the onWindowResizefunction, which adapts the site layout. _yes_ my web site runs underpyjd as a desktop app :) ]

and − this is the kicker: the pyjamas API itself, as long as you stickto it, you know that the same application will run − unmodified − in a_real_ web browser, by being compiled to javascript.

now all i have to do is investigate pydom and pyxpcomext, because −again, porting pyjamas to utilise pydom i believe will be utterlytrivial. if i hadn't had to cater for some of glib's foibles, withsilly naming conventions, i reckon i'd be done in about 16 hours flat(i'll let you know how i get on, when i have 16 hours of timeavailable to _try_!).

oh − one last thing. glib != gtk. therefore, the possibility existsto do a pywebkitqt4, a pywebkit/wxWidgets, and, also, thanks to googlechrome's use of webkit, what google have done is write their OWNdrawing library (!!!) making ANOTHER graphics−port of webkit that iscompletely independent of and having nothing to do with gtk2, qt4 orwxWidgets. then what they have done is provide accelerated driversfor ARM−embedded devices (in android) and another one for windows.ripping that library (i forget its name) out of the clutches of themonster 450mb hairy tarball that is called "google chrome" should begiven some high priority.

anyway − the reason i mention it is because with a tiny bit of messingabout, you can get a pywebkit−<anything> that is entirely and whollyindependent of the underlying "helper−widget−set" on which it sits.the only real reason why, then, you would want to use a particularpywebkit−<xxx> − e.g. pywebkit−qt4 with bindings to the DOM model −would be because you wanted to embed the webkit engine into anexisting pyqt4 application.

in this way, i hope that i have highlighted that the pyjamas API isentirely independent of the "underlying" widget set which it uses todraw on−screen, making it a proper "cross−widget−set" API, even thoughat the moment there is only widget set that it's been ported to(pywebkitgtk).



http://lkcl.net/site_code

the summary: doing a decent cross−widget−set API that is also cross−platform, cross−desktop, cross−browser is damn hard − but it _can_ bedone, and _has_ been done, albeit in a very roundabout and obscurefashion. http://pyjs.org and http://pyjd.org

l..



http://pyjs.org

http://pyjd.org

re pygui as a standard gui api for python

Documents