Changes

* 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)

* 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)

* 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)

* at the and sugar has all activities/activity-versions in Journal, there could be two types of activities:

** pre-installed activities represented by Journal entry

** activities installed from [[Features/Object_Bundles|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

* 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

* when join request arrived, sugar runs proper version of activity or download(if it doesn't exist) from user or ASLO