607
edits
Changes
Jump to navigation
Jump to search
Line 16:
Line 16: − + Line 26:
Line 26: − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
no edit summary
* Use gconf as a backend to store the profile. '''(erikos)'''
* Use gconf as a backend to store the profile. '''(erikos)'''
== Ideas ==
=== Ideas ===
* Remove unnecessary abstraction layers. They makes the code harder to debug and affect performance.
* Remove unnecessary abstraction layers. They makes the code harder to debug and affect performance.
** http://twistedmatrix.com/projects/core/documentation/howto/choosing-reactor.html
** http://twistedmatrix.com/projects/core/documentation/howto/choosing-reactor.html
== Status ==
=== Status ===
* Modularization is being figured out and discussed.
* Modularization is being figured out and discussed.
== Stable activities API ==
=== People ===
Owner: Marco Pesenti Gritti
Peers:
* Simon Schampijer
=== Goals ===
* 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.