628
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: − + − + − <!-- All fields on this form are required to be accepted. − We also request that you maintain the same order of sections so that all of the feature pages are uniform. --> − − <!-- The actual name of your feature page should look something like: Features/Your Feature Name. This keeps all features in the same namespace --> Line 17:
Line 13: − + − + − + − + − + − * why not treat activities as a regular sugar(Journal) objects+ − What sugar can do to fix these issues:+ − + − + − + − + − * when join request arrived, sugar runs proper version of activity or download(if it doesn't exist) from user or ASLO+ + + + + − ''What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?''+ + + + − + − * rework activity registry code in sugar+ − * migrate Home view to Journal code base+ − * code to auto-load proper activity version(while joining) if it doesn't exist+ + Line 59:
Line 63: − ''If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice.''+ + + Line 71:
Line 77: − + + + + + Line 79:
Line 89: − − − [[Category:Feature Page Incomplete]] − [[Category:Feature]]
User:Alsroot/trash/Activity as a regular Journal Object (view source)
Revision as of 15:05, 5 November 2013
, 15:05, 5 November 2013no edit summary
<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude>
<noinclude>{{GoogleTrans-en}}{{TOCright}}
[[Category:FeatureObsoleted|Activity as a regular Journal Object]]</noinclude>
== Summary ==
== Summary ==
== Current status ==
== Current status ==
* Targeted release: 0.86
* Targeted release: 0.88
* Last updated: Tue Jul 28 04:32:53 UTC 2009
* Last updated: Fri Nov 27 21:28:31 UTC 2009
* Percentage of completion: 0%
* Percentage of completion: 0%
== 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(pre-installed and installed from object bundles)
** for system wide activities, based of /usr directory properties
* 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
* there is strong linkage between activity in Home view and journal entry, removing activity in one place, removes it from another
** 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 ==
* feature eliminates confusion, e.g. in case of removing activities, when there are activities(in Home view) and .xo bundles in the Journal(that could be absent - .xo deleted, system activity)
* let users, that are not experienced in command line applications, copy existed activity(even system) just by draging Journal(or Home) entry to USB source
* since all activities have Journal representation, keep useful information in entry fields(time of installing activity, additional info in description etc.)
* so, it simplifies situation - user all time has in mind that he is working with the same object(activity) but from different views(Home or Journal)
== Scope ==
== Scope ==
* depends on [[Features/Object Bundles]]
* sugar
== UI Design ==
Nothing.
== How To Test ==
== How To Test ==
== User Experience ==
== User Experience ==
* there is strong linkage between activities in Home view and Journal entries, in fact Home view is just a predefined view [[Features/Journal Plugins|plugin]] to browse activity Journal objects
* user can operate with system activities or activities woth removed .xo bundles(in existed workflow) from Journal, e.g. copy them to USB stick
== Dependencies ==
== Dependencies ==
== Documentation ==
== Documentation ==
* [[Unified Objects#Activities_as_Journal_Objects|Unified Objects]]
* [[User:Alsroot/trash/Unified Objects | Unified Objects#Activities_as_Journal_Objects|Unified Objects]]
* [[Features/Object Bundles]]
* [[Features/Object Bundles]]
* Email threads
** [http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg10708.html Activity as a regular Journal Object request for inclusion to 0.88]
** [http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg07572.html multiple activity versions installed simultaneously]
** [http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06944.html Activity as regular objects proposal]
== Release Notes ==
== Release Notes ==
== Comments and Discussion ==
== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->