GUIs - A Modest Proposal
in [Python]
|
From: lkcl on 12 Jun 2010 09:26 [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...(a)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.
From: lkcl on 12 Jun 2010 09:44 On Jun 6, 10:49 pm, Kevin Walzer <k...(a)codebykevin.com> wrote: > > - 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 > > These goals are not all complementary. In fact, some of them, such as > "small" and "comprehensive," are mutually exclusive. that's not quite true - you can create a simple core which is easily extensible with third party contributions to create more comprehensive widgets. in the GWT arena, you have gwt-g3d, gwt-incubator, gwt-gchart and so on, all of which were created very easily thanks to the power of the underlying GWT core codebase, _none_ of which are actually included into GWT by default, _all_ of which can be installed by users and simply "imported" just like the core. now s/GWT/pyjamas and you have the exact same thing, and all the satisfiable requirements are met. l.
From: lkcl on 12 Jun 2010 09:55 On Jun 6, 10:55 pm, ant <shi...(a)uklinux.net> wrote: > On Jun 6, 2:22 pm, ant <shi...(a)uklinux.net> wrote:> I get the strong feeling that nobody is really happy with the state of > > Python GUIs. > > <snip...> > > What an interesting set of responses I got! > And - even more interesting - how few of them actually seem to think > there is a problem, let > alone make any attempt to move the situation forward. > I appreciate that there are proponents of many different GUIs. I am > asking that all step back > from their particular interests and - for example - try to see the > situation from the viewpoint of > - say - a Python newbie, or an organisation that is thinking of > switching from (example only!) Visual Basic. > > I obviously didn't make my main point clearly enough; I'll restate it > with a different emphasis: > The default GUI shipped with Python is Tkinter. > Few people seem to like it much. This has several consequences. > - It has not blossomed, like Python has. > - There are not hundreds of talented programmers making rapid and > impressive improvements to it. > - Books about Python use it in examples (because it IS the default), > but imply that one should move on. > > The result that our hypothetical new recruit has to make a choice for > the new, big project. Remember that > GUIs have hundreds (sometimes thousands) of classes, functions and > constants. Let alone idioms and design > patterns. That is what I meant by 'Our resources are being > dissipated'; the effort of learning, remembering > and relearning a workable subset of these is substantial. > So it would be good to be able to use One Right Way, not try several > (as I have - I will admit I didn't try PyQt; > GUI fatigue was setting in by then). > > If we are to make progress, I can see two obvious approaches: > 1) Improve Tkinter to the point where it is supportable and supported > by a good fraction of Python programmers > or > 2) Drop Tkinter as the default and use something else. > > If we choose 2) then we have a new set of possibilities: > 2a) Use one of the 'major' GUIs, pretty much as is, but presumably > with a lot more people supporting it if it is the default. > 2b) Use one of the 'minor' GUIs, and get a lot of people working on it > to make it really good. > 2c) Start from scratch. With a project supported by the Community as a > whole, with the agreed objective of being the default. > > None of these is easy. All require strong leadership and great > committment. > > What surprises me is the apparent willingness of the Python community > to let this issue slide. ah - i think... i believe you may be confusing realism with fatalism. experienced python developers are also experienced, specialist c programmers (amongst other things) and experienced software engineers. they've been around a while (10+ years). they _know_ how much effort is involved in creating a major project such as a GUI widget set (and you can get a wildly-wrong but nevertheless useful answer from ohloh.net statistics, by going to http://ohloh.net/p/gtk for example) so, spec'ing it out, we _know_ that to create a decent GUI widget set, from scratch, in c (to make it fast enough) would be... ye gods... 50 man-years of effort, minimum? you _might_ be able to reduce that by using somebody else's library (libcairo, libpango) but... just... _why_?? so this was why i went "f*** that!" and "leveraged" web browser technology, jumping from virtually nothing (an abandoned python-to- javascript compiler project) to a world-class GUI toolkit, in under 18 months of _part time_ effort. > My concern is simple: I think that Python is doomed to remain a minor > language unless we crack this problem. ah. take a look at that chart that keeps cropping up every now and then: python is _not_ a minor programming language. most likely due to django, it's rated about 7th with about ... i think it was 6% share. perl is now _under_ 4%! so i don't believe there are any concerns there: python has enough alternate uses other than as a GUI toolkit to keep it going :) l.
From: lkcl on 12 Jun 2010 10:08 On Jun 7, 9:25 pm, Arndt Roger Schneider <arndt.ro...(a)addcom.de> wrote: > Terry Reedy schrieb: > Forget postscript! > Generate SVG from a tk canvas or --better-- from tkpath. > Jeszra (from me) generates SVG. There is also a SVG export ... orr, you use a modern web browser engine such as XulRunner 1.9 (the engine behind FF 3+), or webkit (the engine behind arora, midori, safari, android, chrome, palm's webos, adobe AIR, iphone, ipad, appcelerator, nokia S60 browser, the IE chrome plugin, blackberry 4 OS's web browser, and god knows what else). and you create python bindings to that modern web browser engine, and you can then use DOM manipulation (like javascript, only in python) to get at those SVG functions, and much much more. ... how does that sound? > Will any big GUI-Framework work on those devises? > > No! yes. called a web browser. most likely a modern webkit-based engine. > Will SVG run on thoses devices? yes. in the webkit-based web browser. or the "opera mini" browser. etc. etc. l.
From: Kevin Walzer on 12 Jun 2010 11:07
On 6/12/10 9:44 AM, lkcl wrote: > that's not quite true - you can create a simple core which is easily > extensible with third party contributions to create more comprehensive > widgets. That's exactly the design philosophy of Tk: a small core widget set (recently expanded somewhat with the ttk widgets) and an API that is easily extensible, either at the script level (megawidgets, cf. using an entry widget and a listbox to build a combobox) or at the C level (more complex, but hardly impossible). I've used a browser-based app before (Adobe AIR app running in IE) and while it wasn't horrible, I certainly did not prefer it to a native desktop app: I got sick of waiting for the app to reload because of a slow network connection. -- Kevin Walzer Code by Kevin http://www.codebykevin.com |