[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...@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. -- http://mail.python.org/mailman/listinfo/python-list
