5,705
edits
Changes
Jump to navigation
Jump to search
Line 23:
Line 23: − + − + − + − * why don't treat activities as a regular sugar(Journal) objects+ − What sugar can do to fix these issues:+ − + − + − + − + − + − * 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+ + +
User:Alsroot/trash/Activity as a regular Journal Object (view source)
Revision as of 17:11, 27 November 2009
, 17:11, 27 November 2009→Detailed Description
== Detailed Description ==
== Detailed Description ==
The problems that 0.84 has in case of activity versions are:
The major reason for this feature is eliminating confusion when:
* it can't upgrade activities if they were pre-installed from native packages; it makes process of upgrading activities from .xo impossible
* theres are activities(in Home view) and activity bundles(in Journal)
* sugar can have only one activity version installed at the same time i.e. 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)
* user can remove bundle from Journal and activity will be preserved(and vise versa)
* activities could not have bundles in journal(were deleted or its a system wide activity), so user can't copy activity(e.g. to share it via USB stick) using regular shell workflow(Journal) and should be aware of stuff like Terminal
Feature declares:
* 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)
* every activity which is accessible in sugar has Journal entry
* 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)
** for activity came from bundles, entry will have .xo's metadata(timestamp, title etc)
* at the and sugar has all activities/activity-versions in Journal, there could be two types of activities:
** for system wide activities, based of /usr directory properties
** pre-installed activities represented by Journal entry
* there is strong linkage between activity in Home view and journal entry, removing activity in one place, removes it from another
** activities installed from [[Features/Object_Bundles|object bundles]]
** in fact, Home view could be treated as a predefined set(with query terms to show only activities) of Journal entries which is viewed in Home [[Features/Journal Plugins|plugin]]
* reflect on system wide activities update, Journal entry's metadata will be changed with keeping only one object per activity
* reflect on uploading to Journal new .xo version of existed activity, could be:
** follow the same forkflow like with system activities, remove previous .xo from Journal or even do not store uploaded .xo at all, on upload, unzip it to ~/Activities and follow system activities way(entry which represent activity)
** storing in Journal several versions of the same activity(including system) and on clicking on particular version in Journal, if it its not installed, ask user to upgrade/downgrade activity(to ~/Activities directory) and then start
== Benefit to Sugar ==
== Benefit to Sugar ==