[Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88

[Wade Brainerd]

+1 from me for this feature proposal!

Both the under-the-hood and user experience simplifications are clear
improvements.

I would like to see this as a step towards removing the activity list
view, which starts to become redundant once activities can be
uninstalled from the Journal.

I disagree that showing activities in the Journal, in addition to
activity instances and MIME objects, will cause confusion.  Many
activities are more like content.  Activities can be downloaded,
copied, modified, and deleted.  In Sugar terminology, Activities are
intended to be verbs while Journal objects are like proper nouns.  But
if an activity is a verb, the object which performs the activity can
still be a noun.  For example, the word "hammer" is both a noun and a
verb.  The noun in the Journal ("Hammer.xo") is an object which
enables the verb in the Home view ("Hammer Activity").  It's quite
simple.

Best,
-Wade

On Fri, Nov 27, 2009 at 5:16 PM, Aleksey Lim <alsroot at member.fsf.org> wrote:
> Hi all,
>
> While preparing new 0.88 features, I encountered some in consistence in
> "activities vs. activity bundles" case, so I'm going to reveal
> "Activity as regular objects"(see [1] ml thread) feature but make it
> less invasive in case existed user experience.
>
> http://wiki.sugarlabs.org/go/Features/Activity_as_a_regular_Journal_Object
>
> The major reason for this feature is eliminating confusion when:
>
>    * theres are activities(in Home view) and activity bundles(in Journal)
>    * 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:
>
>    * every activity which is accessible in sugar has Journal entry
>          o for activity came from bundles, entry will have .xo's metadata(timestamp, title etc)
>          o for system wide activities, based of /usr directory properties
>    * there is strong linkage between activity in Home view and journal entry, removing activity in one place, removes it from another
>          o 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 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:
>          o 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)
>          o 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
>
>    *  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 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.)
>
> Except opinions about feature itself, I'm especially interested in
> "reflect on uploading to Journal new .xo version of existed activity" part of it
>
> [1] http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06944.html
>
> --
> Aleksey
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>