5,705
edits
Changes
Jump to navigation
Jump to search
Line 23:
Line 23: − + + + + + + + + + + +
User:Alsroot/trash/Activity as a regular Journal Object (view source)
Revision as of 00:07, 28 July 2009
, 00:07, 28 July 2009→Detailed Description
== Detailed Description ==
== Detailed Description ==
''Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better.''
The problems that 0.84 has in case of activity versions are:
* it can't upgrade activities if they were pre-installed from native packages; it makes process of upgrading activities from .xo impossible
* sugar can have only one activity version installed at the same time; at the same time it could be useful to have several versions simultaneously e.g. to start proper version when join request arrived(activity version of arrived request could be different to installed version)
* why not treat activities as a regular sugar(Journal) objects
What sugar can do to fix these issues:
* scan /usr/share/sugar/activities and ~/Activities directories at startup(like it does at present) to get list of pre-installed activities - it makes sense in case of LTSP or when sugar user develops activities(in that case its useful to store them in ~/Activities)
* pre-installed activities could be represented by Journal entry(in fact pre-installed activities and Journal entry could be treated as special case of [[Features/Object_Bundles|object bundles]] with activities)
* at the and sugar has all activities/activity-versions in Journal(pre-installed and installed from object bundles)
* Home view is a subset of Journal(in case of browsing objects) and will let users run last version of particular activity(or selected version); btw we can have in Home view's list not only activity objects but any object
* when join request arrived, sugar runs proper version of activity or download(if it doesn't exist) from user or ASLO
== Benefit to Sugar ==
== Benefit to Sugar ==