Sugar Labs

0.86/Roadmap

< 0.86
Revision as of 22:44, 21 May 2009 by Alsroot (talk | contribs) (→‎Proposal Goals)

Team Home   ·   Join   ·   Contacts   ·   Resources   ·   FAQ   ·   Roadmap   ·   To Do   ·   Meetings

Sucrose Development

Sucrose 0.85.x is an unstable development series intended for testing and development purposes. Sucrose uses odd minor version numbers to indicate development status, so this unstable 0.85.x series will eventually become the 0.86 stable release.

Schedule

Schedule

Date Task Notes
2009 Jun 01 Release goals proposal
Jun 29 New modules proposal
Jul 29 Sucrose 0.85.1 Tarballs Due
Jul 30 Sucrose 0.85.1 Development Release
Sucrose 0.85.2 Tarballs Due
Sucrose 0.85.2 Development Release
Sucrose 0.85.3 Tarballs Due
Sucrose 0.85.3 Development Release
Aug 20 Sucrose 0.85.- Tarballs Due
Aug 21 Sucrose 0.85 Beta 1 (0.85.-) Feature, API, String freeze
Sucrose 0.85.5 Tarballs Due
Sucrose 0.85 Release Candidate 1 (0.83.5)
Sucrose 0.85.6 Tarballs Due
Sucrose 0.85.6 Release Candidate 2 (0.85.6)
Sep 17 Sucrose 0.86 Tarballs Due Hard code freeze
Sep 18 Sucrose 0.86 Final Release!

Glucose Development Team/Release/Modules

Fructose Development Team/Release/Modules

Glucose Dependencies

Fructose Dependencies

  • pyabiword
  • hulahop

Proposal Goals

Switch to a standard compliant window manager (possibly Metacity)

New toolbar widget

Browse

  • tabs support (open popup windows in tabs, saving of tabs history, standard behavior of Browse should not change -> no open tab by default)
  • better naming of files to be uploaded (change temp name to something based on the title)
  • export for offline viewing (Web page - HTML only, Web page - Complete)
  • creating of web pages (highlighting support in Write, Activity with special HTML based features(can happen outside of the official cycle))
    • bookmarks (global bookmarks, at the moment we only have session bookmarks and the autocompletion functionality)

Tags in the Journal

  • auto completion for already existing tags, tag clouds
    • its implemented in Library activity as well

More Accelerators (short cuts)

  • make sure we use the accelerators where possible, get discussion about which modifiers to use for which settings as early as possible going

Printing support

Search in home view

  • the search is recently builds disabled

Collaboration

Flash activities

Groups

  • tagging buddies to build up relations, tagging can happen by a teacher tagging a class or the learner can tag himself

List views

  • in the mesh view a list view of the access points
  • switching to use gtk-tree-view for the lists (journal, activity) - this has accessibility support already

Mesh View

  • use buddy color to seed the position to get a more stable positioning in the mesh view

Ad-hoc networking

  • as an alternative to the mesh

Bindings

Keyboard control panel extension

  • (Sayamindu would prefer to keep it as a seperate module, since everyone may not choose to go with XKB)

Dictionary support in the shell

  • link to email here

CP - Language in native language

  • link to ticket here

TA

  • de-couple the portfolio from the base TA

Library activity Alsroot 16:16, 21 May 2009 (UTC)

API work

  • backwards compability
  • (http://wiki.sugarlabs.org/go/Development_Team/sugar-port will take care for the activities needs for a working activity on 0.82 for example) see "Decoupling of Sucrose" section Alsroot 16:16, 21 May 2009 (UTC)
  • dbus API to resume/open activities
  • dbus API to get core version(at least major version)

Decoupling of Sucrose(move to pure DBus interface) Alsroot 16:14, 21 May 2009 (UTC)

The major idea is to have tough core(with stable release cycle) <=> dbus API <=> unlimited count of activities that uses core functionality by dbus.

It could looks like:

  • core - glucose, six months(or so) release cycle, w/o any activities only dbus API
  • bridge - sugar-port for example, between all(in ideal) already deployed sugars and activities i.e. it provides backwards compatibility(so the same activity code will work on all sugars) and at the same time provides features from newest sugar(so the same activity code will use last sugar's features)
  • world - the rest of sugar world i.e. fructose/honey (but now there is no differences between them) that use core(by dbus) directly, if all deployed sugars have the same API for desired functionality(for example in case of preselected mime type, ObjectsChooser has different API for 0.82-0.86), or use bridge otherwise.
    imho another point to have activities outside of core release cycle - activities have more shorter release cycle then core has

And of course deployers can form any sets from these components

Old items

Proposed modules

Subpages

Retrieved from "https://wiki.sugarlabs.org/index.php?title=0.86/Roadmap&oldid=29571"