Sugar Labs

User:Alsroot/trash/Activity as a regular Journal Object: Difference between revisions

← Older edit
Godiard (talk | contribs)
628 edits
No edit summary
 
(26 intermediate revisions by 5 users not shown)
Line 1: Line 1:
<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude>
<noinclude>{{GoogleTrans-en}}{{TOCright}}
 
[[Category:FeatureObsoleted|Activity as a regular Journal Object]]</noinclude>
<!-- 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 -->


== Summary ==
== Summary ==
Line 12: Line 8:
== Owner ==
== Owner ==


* Name: ?
* Name: [[User:alsroot| Aleksey Lim]]
* Email: ?
* Email: [[Special:Emailuser/alsroot|send an email]]


== Current status ==
== Current status ==


* Targeted release: ?
* 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)
* why don't treat activities as a regular sugar(Journal) objects
* 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


What sugar can do to fix these issues:
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]]
* 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
* reflect on system wide activities update, Journal entry's metadata will be changed with keeping only one object per activity
* when join request arrived, sugar runs proper version of activity or download(if it doesn't exist) from user or ASLO
* 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 ==


''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?''
* 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
* rework activity registry code in sugar
 
* migrate Home view to Journal code base
== UI Design ==
* code to auto-load proper activity version(while joining) if it doesn't exist
 
Nothing.


== How To Test ==
== How To Test ==
Line 61: Line 63:


== User Experience ==
== User Experience ==
''If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice.''
 
* 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 ==
Line 73: Line 77:
== 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
* 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/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 ==
Line 83: Line 89:
== 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 -->
[[Category:Feature Page Incomplete]]
[[Category:Feature]]
Retrieved from "https://wiki.sugarlabs.org/go/User:Alsroot/trash/Activity_as_a_regular_Journal_Object"