0.84/Platform

Shell refactoring

People

Owner: Marco Pesenti Gritti

Peers

• Simon Schampijer
• Hemant Goyal

TODO

• Every major UI component like the frame the home view and the control panel, should reside in his own model and be self contained. We will need a way to share a bit of code between modules likely. (marco)
• Cleanup window management. The requirements changed a lot since the code was written and we didn't do enough refactoring. The UI design is now pretty solid. We should document our window management strategy and then refactor the code to simplify and make it more solid. (marco)
• Refactor session management, it's scattered around several components right now. (marco)
• Use gconf as a backend to store the profile. (erikos)

Ideas

• Remove unnecessary abstraction layers. They makes the code harder to debug and affect performance.
• De-gobjectify. For code which is independent from the GNOME platform we should really use plain python objects. One layer less to care about for new comers, avoid the memory leaks associated to cycle reference and signals in pygobject, less bloat. Do we have a substitute for signals? Perhaps we are using them too heavily anyway?
• Extensibility
  • http://trac.edgewall.org/wiki/TracPlugins
  • http://www.djangoproject.com/documentation/forms/
  • http://twistedmatrix.com/projects/core/documentation/howto/plugin.html
  • http://twistedmatrix.com/projects/core/documentation/howto/choosing-reactor.html

Status

• Modularization is being figured out and discussed.

Stable activities API

People

Owner: Marco Pesenti Gritti

Peers:

• Simon Schampijer

TODO

• Figure out an ABI break policy that we can actually sustain.
• Figure out a compatibility strategy. We can't just break API because a lot of activities out there are using it. But we also can't stick with the current one because... it sucks too badly. We can either deprecate gradually or support parallel installation of two different versions. Several trade offs to consider and discuss.
• Full review of all the modules.
• Complete the API documentation and provide an introduction/tutorial.
• Refactor the generic part of the Browse activity code into hulahop (creating a web based activity should be as simple as subclassing hulahop.WebActivity and setting a few properties)

Ideas

• 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.
• 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.
• sugar._sugarext. What should we do with this? It contains several functionalities used only by the shell.
• Toolbar redesign.

Status

• General goals defined, concrete discussion and work can start.