[sugar] Sugar 1.0 roadmap

[Marco Pesenti Gritti]

Hello,

I spent some time writing down the goals and the minimum requirements
for a stable Sugar release. It's a work in progress and I'm looking
forward for everyone's feedback!

Marco

---

1.0 (Draft 1)

== General goals ==

* Implement the essential UI features, sufficient to provide a good user
  experience and to show off the innovative aspects of the design.
* Ensure quality by extensive community testing, mandatory code reviews,
  automatic code checking and testing.
* Provide a stable API to activity authors, which make it easy to interact with
  the system services and to write HIG compliant activities.
* Define and document the platform, roll out the plans for the components which
  are not yet available, stable or satisfactory.
* Allow the community to participate to the core development and to write
  activities with a very limited bootstrap effort.

== Performance ==

* Improve startup time down to something between two and three seconds for a
  basic activity.
* Make switching between views instantaneous. The frame and the zoom level
  animations should always be fluid.

== Toolkit ==

* Full review of all the modules, freeze API.
* sugar. Make env activity specify, move the path helpers from sugar.activity in
  here, probably move it inside sugar.activity. Move network inside
  sugar.network, assuming it's still useful. Drop profile, use whatever
  configuration system we adopt instead. Drop wm. Move util in sugar base, drop
  stuff which is not generally useful, split up the module. Ship libsexy python
  bindings instead of our own copy of the entry. Make the key grabber private
  to the shell (or handle keys in matchbox if we switch to mb2).
* sugar.activity. Factor out the helper classes from the activity module. Review
  activityhandle and try to rationalize and clarify the identifiers story. Drop
  the registry, keep the related functionalities exposed as a shell service.
  Factor out bundlebuilder to its own git module.
* sugar.graphics. Use gobject like API consistently, in particular gobject
  properties instead of constructor parameters. Extend the interfaces to match
  the full UI requirements. Do not subclass gtk widgets when not strictly
  necessary, instead work upstream whenever it's possible.
* sugar.presence. Degobjectify and provide asyncronous interfaces. Expose
  wrappers over the DBus service *only* for functionalities which are frequently
  needed by the activities and which are better exposed through a python API.
  Probably rename to sugar.network.
* sugar.clipboard. Make it private to the shell.
* sugar.datastore. Degobectify, factor out the bundle specific bits. Make
  asyncronous where necessary. Expose only the functionalities which are
  relevant for activities and which are better suited by a python API.
* sugar.bundle. Make most of it private to the shell/journal (once they are
  merged in the same process). Move the activity relevant bits in
  sugar.activity.
* Complete the API documentation and provide an introduction/tutorial.

== Development ==

* Maintain packages for the major distributions. Fedora and Ubuntu are being
  worked on. We need to enhance and document our release process, have clear
  modules maintainers, coordinate the core components releases, provide source
  tarballs and release notes.
* Start packaging activities and build them in the Fedora build system. On the
  first run (in a standard distribution), they will be symlinked inside the
  user activities directory, so that they can be managed as xo bundles. Even
  when deleted they should be available from "get more activities...".
* Create a sugar-core git module containing, as submodules, the various
  services, the toolkit and the shell. Provide python scripts to build, run
  and help maintenance of the modules.
* Create a sugar-activities git module containing, as submodules, a set of
  blessed activities. They will be either built and run in the system sugar
  installation or in the one compiled from the sugar-core sources.
* Establish a regular weekly or bi-weekly IRC meeting encouraging the
  participation of contributors and activity authors.
* Open up the UI design team. Get external designers involved, get feedback from
  teachers and kids. Publish mockups and UI ideas early for the community to
  comment and get excited about. Spread our ideas in the free software
  community, particularly GNOME, to ensure the platform evolves in a way that
  is friendly to our User Interface goals.

== Quality Assurance ==

* Document and consolidate the patch review process. Distribute the review
  duties to ensure they are done timely.
* Publish a reference pylint configuration, apply it to the whole codebase and
  fix the reported issues. Require the code to pass pylint before submitting
  it for review.
* Form a community driven bug squad to help with testing and bug triaging, both
  on the XO version of Sugar and on other distributions.

== Platform ==

* Datastore. Lots of work to be done to sanitize interface and implementation.
  Unclear if it would require a full rewrite or if it can be conveniently done
  by refactoring. A list of improvements and required new features, in no
  particular order:
  1 Minimize the copy of files while keeping the API simple and clear for
    activity authors.
  2 Better support for activities which needs to keep the file around during all
    the life cycle of the activity (a media player, for example).
  3 Separation between actions and documents. Actions are the frozen state of
    an activity and can reference one or more documents.
  4 Support for documents versioning, backed by differential storing.

* Choose a configuration system. gconf-dbus or dconf (status?) are possible
  candidates, generally it looks like a service accessed through a DBus
  interface would fit our needs, but see what the security team has to say
  about it.
* Settle on a "free form" graphic toolkit. There are several possibilities.
  1 Turn hippo into a mature canvas, add support for focus and accessibility.
    Make it more friendly to layout-free use cases. Document it properly.
  2 Experiment with goocanvas. See if the layout system can fullfill our needs.
  3 Adopt a web based canvas, either firefox through pyxpcom and javascript, or
    webkit gtk. Can it cover layout-free use cases?
* Provide a better default build system for bundles. It should be independent
  from the toolkit and packaged by distributions (it could also just be an
  extension of distutils or setuptools, possibly). It should support bundling
  of external libraries and native code compilation.

== New Features ==

* Control panel providing essential customization, at minimum expose the
  preferences which are currently supported by the command line version.
* Ability to share journal entries by sending them to a single xo.
* Browse activity. Global bookmarks, address autocompletion, improved
  performance and memory use.

== Usability Improvements ==

* Shell redesign as specified by http://dev.laptop.org/go/Designs (essential
  features, no regressions from Update.1).
* Journal redesign as specified by http://wiki.laptop.org/go/Designs/Journal
  (essential features, no regressions from Update.1).
* Keybindings. Provide accelerators for all the activity toolbar actions. Key
  navigation between activities. Key navigation inside the free form views
  (Journal, Mesh, Groups, Home).

== Bugs ==

* When opening a journal object with a different activity we need to fork and
  use a different activity_id. No good solution in a non-versioned world, since
  even read-only activities might change the state and hence require a copy,
  with the related waste of space.
* Implement session handling, probably by reusing gnome-session (rewrite being
  worked on by Nokia in a branch). Our requirements are very simple but there
  is a lot to gain in reusing the standard X session mechanism (or whatever
  is used in the future by GNOME applications).
* Make activity launching a service so that we can safely allow activities to
  launch other activities.
* Remove the need to set custom X properties to facilitate activity developments
  in other languages and toolkits.