158
edits
Changes
no edit summary
The purpose of this toolkit is twofold:<br />
The purpose of this toolkit is twofold:<br />
* it would make it easier "sugarify" web apps (like gmail).<br />
* it would make it easier to "sugarify" web apps (like gmail).<br />
* there are a lot of developers that are familiar with HTML(5), CSS and JavaScript and it would be great to take advantage of their skills.<br />
* there are a lot of developers that are familiar with HTML(5), CSS and JavaScript and it would be great to take advantage of their skills.<br />
As a bonus, some things that are hard to do with native GUI toolkits are very easy to do with HTML, like nicely re-flowing text or embedding video/audio/pdf/flash. Pyjamas Desktop (pyjd.org) was created to take advantage of this.<br /><br />
As a bonus, some things that are hard to do with native GUI toolkits are very easy to do with HTML, like nicely re-flowing text or embedding video/audio/pdf/flash. Pyjamas Desktop (pyjd.org) was created to take advantage of this.<br /><br />
Furthermore, integration of web applications with the desktop is a very useful (and popular) thing to do. Gears, AIR, Prism, HTML 5 and various combinations between them extend the browser with desktop-like abilities: persistent storage, accessing files, desktop icons, running in a separate window/process, etc.<br /><br />
Furthermore, integration of web applications with the desktop is a very useful (and popular) thing to do. Gears, AIR, Prism, HTML 5 and various combinations between them extend the browser with desktop-like abilities: persistent storage, accessing files, desktop icons, running in a separate window/process, etc.<br /><br />
There are two main strategies for implementing this:
There are two main strategies for implementing this:
# Running a standard site specific browser, as light as possible, that has a local webserver written in python (BaseHTTPServer should suffice) as homepage. It would use AJAX or a wrapper on top of that (like jsonrpc) to provide the bridge to python. Also, as much functionality as possible should be on the html+js side, to keep the toolkit easily hackable by web developers. This version would use Sugar APIs over the python-js bridge for storage, other filesystem access and integration.
# Running a standard site specific browser, as light as possible, that has a local webserver written in python (BaseHTTPServer should suffice) as homepage. It would use AJAX or a wrapper on top of that (like jsonrpc) to provide the bridge to python. Also, as much functionality as possible should be on the html+js side, to keep the toolkit easily hackable by web developers. This version would use Sugar APIs over the python-js bridge for storage, other filesystem access and integration. The biggest downside is that this process could not be automated. Some python code would have to be written.
# Embed a browser runtime (preferably with hulahop) that has Gears and move over even more things to the html+js side. The activity would be completely standalone and would not depend on a web server anymore. xulrunner has the advantage of a full javascript-python bridge, PyXPCOM. Dbus access through pyxpcom or [http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#WebKit_.28JavaScriptCore.29_version_notes this]?).<br /><br />
# Embed a browser runtime (preferably with hulahop) that has Gears and move over even more things to the html+js side. The activity would be completely standalone and would not depend on a web server anymore. xulrunner has the advantage of a full javascript-python bridge, PyXPCOM. Dbus access through pyxpcom or [http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#WebKit_.28JavaScriptCore.29_version_notes this]?).<br /><br />
I will be focusing on the second stragety.
I will be focusing on the second stragety.