607
edits
Changes
Jump to navigation
Jump to search
Line 45:
Line 45: − * 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) + +
no edit summary
* 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. '''(marco)'''
* 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. '''(marco)'''
* Full review of all the modules. '''(marco)'''
* Full review of all the modules. '''(marco)'''
=== Ideas ===
=== Ideas ===
* 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)
* 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. 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.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.