Changes

Jump to navigation Jump to search
912 bytes added ,  10:50, 31 March 2009
no edit summary
Line 44: Line 44:     
* 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.
 
* 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.
I plan to get Gears integration, dbus access and a nicer js wrapper on top of that done in the first 2-3 weeks. This would create a template for web-based activities, that web developers could already build on. A small utility that generates sugarified web applications would also use that template. <br />The utility and a nice demo of Webified usage could then be made in a few days, two weeks at most. <br /> The integration with the Journal is not meant to be more complex than saving the HTML and Gears state in the Journal.<br />
  −
The remaining time could then be spent on polishing things up and for any eventual emergencies.<br />
  −
Beyond GSoC, I would like to keep working on this.
      
<br />'''Milestones''':
 
<br />'''Milestones''':
 
# Webified SSB can load a website (hello world)
 
# Webified SSB can load a website (hello world)
# Webified SSB can use GMail in offline mode (through Gears)
+
:: Requires:
 +
::: - getting more familiar with Sugar and Browse code
 +
::: - 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
 +
:: '''Week 2, at worst 3'''
 
# Browse (with its utility extension) can successfully "sugarize" GMail and the resulting activity works.
 
# Browse (with its utility extension) can successfully "sugarize" GMail and the resulting activity works.
 +
:: Requires:
 +
::: - activity template as host for the Webified SSB
 +
:::: '''Week 3'''
 +
::: - python tool that packages up activities, using the activity template
 +
:::: '''Week 3, at worst 4'''
 +
::: - 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
 +
::: - if that is not appropriate, try marshalling calls to Python
 +
:::: - through PyXPCOM (hulahop). almost as good as a direct bridge
 +
:::: - through AJAX. sounds like the easiest way, but doing some [http://en.wikipedia.org/wiki/Cross-site_scripting XSS] would be needed
 +
:: '''Week 5'''
 +
 +
The remaining time could then be spent on polishing things up and for any eventual emergencies.
 +
 +
If I have extra time.
 
# Webified SSB can save and resume its state with the Journal.
 
# Webified SSB can save and resume its state with the Journal.
# JavaScript from inside a Webified SSB can call dbus stuff (dbus hello world)
+
# 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.
If I have enough time.
+
: based on the javascript-dbus bridge
# Build a small JavaScript native API similar in concept to [http://fluidapp.com/developer/ Fluid's], but tailored to Sugar
   
# Webified SSB can run a userscript (GreaseMonkey)
 
# Webified SSB can run a userscript (GreaseMonkey)
 +
: 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)
 
# Webified SSB can use a userstyle (CSS)
 +
: again, should be just injecting some CSS
 +
: again, no GUI will be provided, just instructions
 +
 +
Beyond GSoC, I would like to keep working on this.
 +
    
* Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.
 
* Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.
Line 83: Line 113:  
:Python is a tool popular among sysadmins and hackers. It is great tool. But folks who develop web UIs use css, html, javascript, and flash. I highly doubt that will change in the near or distant future. These are people we need to recruit as activity designers.
 
:Python is a tool popular among sysadmins and hackers. It is great tool. But folks who develop web UIs use css, html, javascript, and flash. I highly doubt that will change in the near or distant future. These are people we need to recruit as activity designers.
 
'''Tomeu Vizoso''' [http://lists.sugarlabs.org/archive/iaep/2009-January/003445.html same mailing list thread] <br />
 
'''Tomeu Vizoso''' [http://lists.sugarlabs.org/archive/iaep/2009-January/003445.html same mailing list thread] <br />
: Without needing to get into what is better for our deployments, I do see value in making easier to make Sugar activities using technologies such as HTML, CSS, etc
+
: Without needing to get into what is better for our deployments, I do see value in making easier to make Sugar activities using technologies such as HTML, CSS, etc.
Are you a mentor? Could I please get a paragraph in here from you? Pretty please?
   
* Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?
 
* Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?
 
I'm not familiar with schools near where I live, as I am an international student. [Any suggestions?]
 
I'm not familiar with schools near where I live, as I am an international student. [Any suggestions?]
158

edits

Navigation menu