On Jun 12, 7:29 pm, Terry Reedy <tjre...@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. -- http://mail.python.org/mailman/listinfo/python-list