Clone this wiki locally
Canvas Support in webkit-based pyjamas desktop
Pyjamas Desktop allows developers to debug their applications directly in Python, speeding up development process quite a bit (and also allows developers to write a single application that works both in a browser and as a much faster stand-alone desktop application).
Previously the main version of Pyjamas Desktop in Linux was based on XULRunner. Partial functionality was available on Mac OSX via Webkit, and full functionality is available on Windows via MSHTML. Canvas support in Webkit was (and still is) unavailable; MSHTML canvas uses VML, which is pretty slow. Since then Ubuntu completely destroyed the ability to use XULRunner's hulahop, breaking Pyjamas Desktop and several other programs (last working version of XULRunner is 1.9.1 on Ubuntu 9.10), and while I'm not sure if other Linux distributions still run XULRunner-based Pyjamas Desktop, it seems that XULRunner-based PYJD is now obsolete, especially since Webkit version got a lot better, and faster than XULRunner. (lkcl: it's not obsolete, but someone needs to sort out python-xpcom properly, and get it back up-to-date. that would also be a very useful GSoC project in its own right).
Unfortunately, the Webkit version has never supported Canvas, because it requires the addition of an extra 120+ IDL files (at present, only approximately 250 of the 450+ IDL files from Webkit are used).
As a follow-up to this task, getting Webkit-based version of Pyjamas Desktop working on Windows would be fantastic, as this would allow a single Webkit-based Pyjamas Desktop to work on all 3 major operating systems with the same consistent functionality. This 2nd task was tried in the past by Luke, but he wasn't able to get it working: http://groups.google.com/group/pyjamas-dev/browse_thread/thread/dcc574f531c4e91f
The python-webkit page is at http://www.gnu.org/software/pythonwebit. The skills required will involve knowledge of python c modules; a willingness to examine, learn from and translate code that will have been written in perl as well as objective-c (in Webkit); the principles behind IDL files and code-generation; HTML5 + SVG Canvas knowledge itself is not specifically required because there are SVG 2D Canvas tests/examples which have already been demonstrated to work under XulRunner. The absolute most crucial skill required is a willingness to trust the direction being taken, as there is quite a lot of inter-dependence between the various parts, and it will appear in some cases that no progress is being made, until suddenly it all comes together. Also, the student must have a willingness to ask for help from several quarters, such as the Webkit developers, as well as the mentor.
The initial webkit bindings took only 6-8 weeks initially to write, providing glib/gobject bindings and including enhancements to pywebkitgtk to use those glib/gobject bindings; the 2nd set of bindings - direct python bindings - took only about 12 days.
Overall this is quite a challenging task, not because of the amount of time that it would take but because of the very wide and diverse range of programming languages and areas of computer science that are covered.
Most of the pyjamas apps don't work completely as expected with mobile devices such as smartphones or iPad. One of the bigger issues is that the input on these devices is radically different than regular PC. There is no right-click, and there are no keyboard shortcuts. One possible solution is to write special "mobile" versions of KeyboardListener and MouseListener classes that can report a certain key combination (shortcut) or mouse key (right-click, middle-click, scroll wheel) based on the user gesture.
this project is not just an independent and important language translation project, it is strategically very important to the success of the pyjamas project. "partial" automated translation of code such as GWT or GChart has been done by using a very dumb contributed application called "java2py.py". however, java2python can perform fully-automated java to python conversion.
this is important because it saves vast amounts of time in converting GWT projects and GWT itself for use into python, for compilation under pyjs or for use under pyjd. conceivably it might even be possible to take the entire GWT 2.0 codebase, simply run it through java2python and then commit the results to the pyjs source repository. the pyjamas project would then be greatly reduced in scope because almost all bugreports would be submitted to GWT not pyjamas!
tomas's "aparser" work took a slightly different approach from java2python (http://code.google.com/p/java2python) in that it was constructed using a series of "pipes", each of which performed one simple task, to solve one particular issue, by transforming the Abstract Syntax Tree (represented in aparser "Aterm" form) in each case. for example, comments are required to be at the end of a line in python, but can be anywhere inside java. simply adding in a "#" resulted in python syntax errors, and so an "aparser" script was written that moved the AST "comment" node to just before the nearest end-of-line character.
however, the "aparser" language itself is implemented in java, which makes it a triple-whammy as far as usage for pyjamas is concerned. java runtime is 120mb; "aparser" is 140mb; the aparser language is... aparser, not python! so, for the sanity of all involved, it would be best if the work that tomas did was moved into python.
this can be done in several convenient steps, if done carefully, the first of which might involve writing an aparser interpreter in python. or, the student might wish to convert tomas' scripts from aparser into python. there are several approaches, as there are several "link-points" because the translation process is itself a chain (using unix pipes) involving the intermediate and incredibly simple "Aterm" system - conceptually as simple as Lisp syntax - to represent the AST. a python reader/writer for "Aterm" has been written in about 200 lines, not even requiring ply, antlr or other complex lexer.
Current version of pyjamas sees IE9 as a browser based on IE6. As a result it makes several assumptions that hinder IE9 performance. It uses some tweaks to allow pages to render correctly in IE6 that IE9, being much more standards-compliant, no longer needs. It also simulates canvas element via much slower VML that comes standard with IE6-8. Since IE9 now supports canvas natively with same speeds as other modern browsers, this VML feature does more harm than good for IE9, forcing it to use slow (and now obsolete) VML.
The best approach would be to create a new identifier for ie9 similar to current "safari", "mozilla", "ie6" identifiers (could even call it "ie9"), then a new __ie9__ directory inside the library directory where other browser-specific module implementations reside in case ie9 needs any unique tweaks, letting the compiler be aware of it and compiling *.ie9.cache.html version of the website in addition to the current ones
The easiest thing to follow therefore is the GWT codebase, which has itself created a new ie9 platform (as well as an ie8 one, which has been found to be unnecessary in pyjamas, to date, but ie9 brings too many new features and has much more strict and accurate HTML5 compliance than either safari or firefox!)
Web Application Framework
Creating a web application framework on top of pyjs's ui and browser library for making application faster to create and run and looks beautiful. ( css theme, layout, event propogation, secure rpc, project organization, multiple app in one app etc ) ( equivalent to http://en.wikipedia.org/wiki/Vaadin for gwt )
In-browser code execution (implementation of exec and eval)
Whilst the lib2to3 "parser" has been plugged in to pyjs (so that python 2.4 all the way to the latest versions of python2 can be used), nothing else has been. So there is quite a lot that is needed, and it will raise the Official status of pyjamas from "translator" to "interpreter".