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/200810/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 oneman effort, and it may be slowed down by the attempt to develop the API and the implementations 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 your question, because i have some insights to share with you from my failed attempts on porting pyjamas to the desktop which you can collect here: http://lkcl.net/pyjamasdesktop there, you will find an IronPythonGtkSharp port; a pyqt4 port and a pygtk2 port. they were each failures in their own unique and special ways. to explain: pyjamas is a widget set api that looks desktoplike; you write code in python, it's compiled to javascript; the DOM.py module actually does things like document.getElementById() etc. etc. and in this way you end up completely manipulating the DOM model, turning the browser into just a giant desktoplike canvas. in fact, the pyjamas widget set api is _so_ similar to a desktop api that 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 with this one i chewed through the pyjamas examples in about a day. i had a small stumbling block implementing the HTML() widget, but GtkSharp.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 such an early stage (36 hours) an implementation of XMLHTTPRequest (remember i was implementing every single bit of functionality that a 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

Re: PyGUI as a standard GUI API for Python? whilst i got a lot further and managed to implement all of the examples, there was no equivalent of HTML(). GTK itself totally lacks a rich media content widget. there is pythongtkhtml2 which is good, but not good enough. the much better gtkhtml3 library doesn't have python bindings around it, and i wasn't in the mood to write any (and hadn't at the time any experience with pygtk codegen.py). also i heard that gtkhtml2 had been abandoned, and gtkhtml3 wasn't going 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 you specify both the width and the height of the widget container, you end up with a flatlined widget. by that i mean a widget of say 200 pixels in width but ZERO pixels in height! and, as you may well know, if you specify a width and height on a gtk widget, that's it: it's entirely fixed. 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 halfhearted attempts to not specify width/height at all, but all that that resulted in was pisspoor layout, and when you shrank the app to small size, all the text disappeared because there was a margin defaulting to 5px or so and all but the top left corner of the text boxes would disappear! so, there was no point in me attempting to make python bindings around gtkhtml3, even though it has a system for inserting widgets into HTML (using span ids). and, even though there's pythongtkmozembed wrappers which would have allowed me to embed flash plugins etc. into my application, thus neatly 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 a complete comprehensive test of absolutely every single feature of the major widget sets out there, crawling every single corner of their functionality in order to map concepts oneforone, and finding that they don't really cope. pyqt4. again, i got a long long way. the rich media support of qt4 allowed me to do widgets that looked reasonable. i even had, by that time, a nonasynchronous version of XMLHTTPRequest. then i got to the implementation of Grid() and FlexTable(). this is where it started to go wrong. pyqt4 has the concept of layouts. a layout can be a horizontal Re: PyGUI as a standard GUI API for Python? 2

Re: PyGUI as a standard GUI API for Python? layout, vertical, grid, and you can even specify the percentage or ratio of the width (or height) that individual cells can use. you attach a layout to a widget; you can attach layouts to layouts. you can 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 to implement 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 HTML layout: you can't _entirely_ stop textsquashing. so, although pyqt4 was _better_, it still wasn't _enough_. so, i was _almost_ ready to give up, entirely, when i'd heard about webkit http://webkit.org and this looked _perfect_. the only down side: it didn't have python bindings. a quick search showed pywebkitgtk. so, i decided to try something absolutely awful: wrap the _javascript_! i augmented pywebkitgtk, thanks to some assistance from the author of midori i borrowed some of his code and made it possible for pywebkitgtk to execute javascript codefragments (equivalent of eval and exec). except, immediately i ran into a problem: how to pass in function call arguments. i decided against doing func_code grunginess and creation of variable scope management to emulate python local function call context (!!!) and instead... insanely... .... dived straight into adding glib bindings around webkit, with a view to then doing pythonbindings around the glib bindings, using pygtk2's "codegen.py". ... cue piped elevator music and suchlike, to substitute 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 port pyjamas to webkit. i had my first succesful hello world within under an hour; i had most of the examples done within 18 hours or thereabouts; the entire port was completed within about five days, because i had to go back and add extra functionality such as event handling and XMLHTTPRequest. when i say "done" i mean that you can do eeevvverrryything that everyone keeps lamenting about that pygtk2 and pyqt4 lack. complete and full support for CSS stylesheets. complete and full support for embedded plugins (such as adobe). complete and full support for HTML syntax. _proper_ HTML, not a subset. you even get the added bonus of being able to execute javascript fragments, if you're feeling particularly obtuse. and, with a few days extra work on the glib bindings, you'd even be Re: PyGUI as a standard GUI API for Python? 3

Re: PyGUI as a standard GUI API for Python? able to run SVG canvas from python (whereas at the moment, you'd have to do it as javascript fragments). the moral of the story is that web browser technology makes for a hell of a lot better widget set than a desktopdesigned 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 more circumstances hostile and conflicting circumstances than desktop apps 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 even widgets flowing neatly. _properly_. you can even specify, thanks to CSS styling, whether you want the "flowing" to be verticalfirst or horizontalfirst. imagine trying to implement that with GTK2 or QT4 it'd be a _nightmare_ gone wrong. yet, browsers have been doing textflowing and divflowing for... forever. now, at this point, having got what i wanted, i didn't want to spend time on wxWidgets, but i can imagine that there would be similar limitations. the issue with implementing a widget set is that there is a very specific set of functionality that is absolutely absolutely required, and without every single bit of functionality, you are entirely wasting your time to make the port. threading. timers. rich text (aka HTML). event handling including window resize, onload, mouse over, in, out, move; keyboard handling; asynchronous external communication with the rest of the world. embedded plugins. layout management, including horizontal, vertical, grid and flow, with _decent_ cell proportion subdivision of available space, and respect for minimum widths / heights as well as fixed widths / heights. without _all_ of these things, done properly, you're hosed before you even begin to create your widget set "wrapper". GTK lacks flowlayout, rich text support and proportion subdivision of layouts, making every GTK application in existence look utterly... shit. scuse my french. fortunately, someone's come to the rescue with a gtk theme engine which allows you to customise gtk with CSS stylesheets, but it is early days yet. _other_ than these significant failings, GTK is technically pretty damn good and provides everything else you'd need including embedding flash and other plugins by leveraging mozplugger in an easytouse and welldocumented fashion. QT4 lacks crucial layout management (layouts not being deletable from layouts), flowlayout, and variablesized rich text. they _do_ have Re: PyGUI as a standard GUI API for Python? 4

Re: PyGUI as a standard GUI API for Python? proportional subdivision of layouts (allowing you to specify a fixed width on one cell and a percentage width on others) but it is very clumsy. other than those failings, which are less than those of GTK2 but as equally significant, QT4 _looks_ better than GTK2 but ... it's still not good _enough_. when you've written an app with pyjamasdesktop, and it looks good no matter 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 own web site http://lkcl.net/site_code see the onWindowResize function, which adapts the site layout. _yes_ my web site runs under pyjd as a desktop app :) ] and this is the kicker: the pyjamas API itself, as long as you stick to 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 utterly trivial. if i hadn't had to cater for some of glib's foibles, with silly 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 time available to _try_!). oh one last thing. glib != gtk. therefore, the possibility exists to do a pywebkitqt4, a pywebkit/wxWidgets, and, also, thanks to google chrome's use of webkit, what google have done is write their OWN drawing library (!!!) making ANOTHER graphicsport of webkit that is completely independent of and having nothing to do with gtk2, qt4 or wxWidgets. then what they have done is provide accelerated drivers for ARMembedded devices (in android) and another one for windows. ripping that library (i forget its name) out of the clutches of the monster 450mb hairy tarball that is called "google chrome" should be given some high priority. anyway the reason i mention it is because with a tiny bit of messing about, you can get a pywebkit<anything> that is entirely and wholly independent of the underlying "helperwidgetset" on which it sits. the only real reason why, then, you would want to use a particular pywebkit<xxx> e.g. pywebkitqt4 with bindings to the DOM model would be because you wanted to embed the webkit engine into an existing pyqt4 application. in this way, i hope that i have highlighted that the pyjamas API is entirely independent of the "underlying" widget set which it uses to draw onscreen, making it a proper "crosswidgetset" API, even though at the moment there is only widget set that it's been ported to (pywebkitgtk). Re: PyGUI as a standard GUI API for Python? 5

Re: PyGUI as a standard GUI API for Python? the summary: doing a decent crosswidgetset API that is also cross platform, crossdesktop, crossbrowser is damn hard but it _can_ be done, and _has_ been done, albeit in a very roundabout and obscure fashion. http://pyjs.org and http://pyjd.org l. .

Re: PyGUI as a standard GUI API for Python?