Webified: Difference between revisions

(3 intermediate revisions by one other user not shown)

Line 1:

''The results of this project are now in the [[Activities/Browse|Browse]] activity and at [http://git.sugarlabs.org/projects/browse/repos/webified a branch of Browse]. See also complementary work on [[Karma]].''

====About you====

Line 5:

Line 6:

Lucian Branescu Mihaila

* '''What is your email address?'''

lucian dot ~~branescu~~ at gmail dot com

lucian dot braneNOSPAMscu at gmail dot com

* '''What is your Sugar Labs wiki username?'''

lucian

Line 45:

Line 46:

* '''What is the timeline for development of your project? The Summer of Code work period is 7 weeks long, May 23 - August 10; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (July 6-13); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.'''

<br />'''Milestones''':

<br />'''Milestones'''

Legend: - todo, + prototype done, # done

* Webified SSB can load a website (hello world)

: Requires:

:: - getting more familiar with Sugar and Browse code

:: # getting more familiar with Sugar and Browse code

:: - building the Webified SSB.

:: # building the Webified SSB.

: '''Week 1'''

* Both Browse and Webified SSB can use GMail in offline mode (through Gears)

: Requires:

:: - getting the Firefox Gears extension working in Browse and the Webified SSB

:: + getting the Firefox Gears extension working in Browse and the Webified SSB

: '''Week 2, at worst 3'''

* Browse (with its utility extension) can successfully "sugarize" GMail and the resulting activity works.

: Requires:

:: - activity template as host for the Webified SSB

:: # activity template as host for the Webified SSB

::: '''Week 3'''

:: - python tool that packages up activities, using the activity template

:: # python tool that packages up activities, using the activity template

::: '''Week 3, at worst 4'''

:: - button in Browse that uses the python tool

:: # button in Browse that uses the python tool

::: '''Week 4'''

* JavaScript from inside a Webified SSB can call dbus stuff

: Dbus is vital for good integration, but there may not be enough time in GSoC for making a nice JavaScript-side API. So I will at least provide a javascript-dbus bridge that web developers can build on.

: Requires investigating:

:: - [http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#Gecko_version_notes This] javascript-dbus bridge

:: + [http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#Gecko_version_notes This] javascript-dbus bridge

:: - if that is not appropriate, try marshalling calls to Python with [http://en.wikipedia.org/wiki/JSON-RPC JSON-RPC]

::: - through PyXPCOM (hulahop). almost as good as a direct bridge

Line 77:

Line 79:

* Webified SSB can save and restore its state with the Journal.

: Save & restore the browser state. possibilities:

:: ~~- just save the URL. It may be slower to resume and in fact loses some state, but it should be enough for most cases.~~

:: # Browse does this

~~:: - save the HTML structure. May have trouble with running scripts.~~

~~:: - pickle the WebView. I'm not sure it works, but it may be the easiest way~~

: Save & restore Gears state

:: - do nothing. Gears provides resuming state. The only real drawback is that only the latest version will be available to resume. No actual data would be stored in the Journal.

:: # do nothing. Gears provides resuming state. The only real drawback is that only the latest version will be available to resume. No actual data would be stored in the Journal.

:: - save the entire Gears profile. Could be very slow for large profiles.

:: - save just the sqlite ~~database~~. Could be very slow for large databases (GMail).

:: - save just the sqlite databases. Could be very slow for large databases (GMail).

* Build a JavaScript-side API for basic functionality that cannot be achieved easily with HTML and Gears

: - similar in concept to [http://fluidapp.com/developer/ Fluid's], but tailored for Sugar.

: - similar in concept to [http://fluidapp.com/developer/ Fluid's], but tailored for Sugar. Based on the javascript-dbus bridge

~~: - based~~ on the javascript-dbus bridge

* Webified SSB can run a userscript (GreaseMonkey)

: - should be as easy as injecting some JavaScript in the page

: + should be as easy as injecting some JavaScript in the page

: - a GUI like the one GreaseMonkey has is outside the scope of this project

: - there will be instructions for how to add/remove userscripts

* Webified SSB can use a userstyle (CSS)

: ~~- again, should~~ be ~~just injecting some CSS~~

: # a user stylesheet can be made in data/style.user.css

: ~~- again, no~~ GUI ~~will be provided, just instructions~~

: + there's a GUI for it

Beyond GSoC, I would like to keep working on this.

@@ Line 1: / Line 1: @@
 {{TOCright}}
+''The results of this project are now in the [[Activities/Browse|Browse]] activity and at [http://git.sugarlabs.org/projects/browse/repos/webified a branch of Browse]. See also complementary work on [[Karma]].''
 ====About you====
@@ Line 5: / Line 6: @@
 Lucian Branescu Mihaila
 * '''What is your email address?'''
-lucian dot branescu at gmail dot com
+lucian dot braneNOSPAMscu at gmail dot com
 * '''What is your Sugar Labs wiki username?'''
 lucian
@@ Line 45: / Line 46: @@
 * '''What is the timeline for development of your project? The Summer of Code work period is 7 weeks long, May 23 - August 10; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (July 6-13); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.'''
-<br />'''Milestones''':
+<br />'''Milestones'''
+Legend: - todo, + prototype done, # done
 * Webified SSB can load a website (hello world)
 : Requires:
-:: - getting more familiar with Sugar and Browse code
+:: # getting more familiar with Sugar and Browse code
-:: - building the Webified SSB.
+:: # building the Webified SSB.
 : '''Week 1'''
 * Both Browse and Webified SSB can use GMail in offline mode (through Gears)
 : Requires:
-:: - getting the Firefox Gears extension working in Browse and the Webified SSB
+:: + getting the Firefox Gears extension working in Browse and the Webified SSB
 : '''Week 2, at worst 3'''
 * Browse (with its utility extension) can successfully "sugarize" GMail and the resulting activity works.
 : Requires:
-:: - activity template as host for the Webified SSB
+:: # activity template as host for the Webified SSB
 ::: '''Week 3'''
-:: - python tool that packages up activities, using the activity template
+:: # python tool that packages up activities, using the activity template
 ::: '''Week 3, at worst 4'''
-:: - button in Browse that uses the python tool
+:: # button in Browse that uses the python tool
 ::: '''Week 4'''
 * JavaScript from inside a Webified SSB can call dbus stuff
 : Dbus is vital for good integration, but there may not be enough time in GSoC for making a nice JavaScript-side API. So I will at least provide a javascript-dbus bridge that web developers can build on.
 : Requires investigating:
-:: - [http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#Gecko_version_notes This] javascript-dbus bridge
+:: + [http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#Gecko_version_notes This] javascript-dbus bridge
 :: - if that is not appropriate, try marshalling calls to Python with [http://en.wikipedia.org/wiki/JSON-RPC JSON-RPC]
 ::: - through PyXPCOM (hulahop). almost as good as a direct bridge
@@ Line 77: / Line 79: @@
 * Webified SSB can save and restore its state with the Journal.
 : Save & restore the browser state. possibilities:
-:: - just save the URL. It may be slower to resume and in fact loses some state, but it should be enough for most cases.
+:: # Browse does this
-:: - save the HTML structure. May have trouble with running scripts.
-:: - pickle the WebView. I'm not sure it works, but it may be the easiest way
 : Save & restore Gears state
-:: - do nothing. Gears provides resuming state. The only real drawback is that only the latest version will be available to resume. No actual data would be stored in the Journal.
+:: # do nothing. Gears provides resuming state. The only real drawback is that only the latest version will be available to resume. No actual data would be stored in the Journal.
 :: - save the entire Gears profile. Could be very slow for large profiles.
-:: - save just the sqlite database. Could be very slow for large databases (GMail).
+:: - save just the sqlite databases. Could be very slow for large databases (GMail).
 * Build a JavaScript-side API for basic functionality that cannot be achieved easily with HTML and Gears
-: - similar in concept to [http://fluidapp.com/developer/ Fluid's], but tailored for Sugar.
+: - similar in concept to [http://fluidapp.com/developer/ Fluid's], but tailored for Sugar. Based on the javascript-dbus bridge
-: - based on the javascript-dbus bridge
 * Webified SSB can run a userscript (GreaseMonkey)
-: - should be as easy as injecting some JavaScript in the page
+: + should be as easy as injecting some JavaScript in the page
 : - a GUI like the one GreaseMonkey has is outside the scope of this project
 : - there will be instructions for how to add/remove userscripts
 * Webified SSB can use a userstyle (CSS)
-: - again, should be just injecting some CSS
+: # a user stylesheet can be made in data/style.user.css
-: - again, no GUI will be provided, just instructions
+: + there's a GUI for it
 Beyond GSoC, I would like to keep working on this.