[Sugar-devel] multiple activity versions installed simultaneously (was Re: [Bugs] #1042 UNSP: cannot install new activity version)

[Aleksey Lim]

On Thu, Aug 13, 2009 at 03:51:43PM +0000, Aleksey Lim wrote:
> On Tue, Aug 11, 2009 at 02:24:46AM +0100, Gary C Martin wrote:
> > On 10 Aug 2009, at 17:24, Daniel Drake wrote:
> > 
> > > 2009/8/10 Martin Dengler <martin at martindengler.com>:
> > >> Learner-generated activity patches, perhaps?  Like, we're under a  
> > >> tree
> > >> and here's my patched Terminal/Pippy/Speak that you may want to try
> > >> but not commit to blowing-away your "official" version...
> > >
> > > Do we have the relevant tools/interfaces/activities to make this
> > > possible and realistic?
> > 
> > It's not so far off...
> > 
> > > What are the user interfaces like when dealing with multiple
> > > activities?
> > 
> > Well, we have this already, it's called the Journal. Just download  
> > Activity bundles and they all live there (and have done as far back as  
> > I can recall)...
> > 
> > > If I click on a new version of an activity in browse, does
> > > it upgrade the one I have or install it in parallel?
> > 
> > It downloads the bundle to Journal and auto unpacks/installs, though  
> > this may have been modified by a very recent patch I haven't poked at  
> > yet:
> > 
> > 	http://dev.sugarlabs.org/ticket/1042
> > 
> > > How do I erase old versions?
> > 
> > Delete the bundle form the Journal
> > 
> > > When I click the activity from the home screen, which version gets  
> > > launched?
> > 
> > The last one that you installed (via either downloading in Browse or  
> > clicking a bundle in Journal).
> > 
> > > Having user-modifiable activities like this is a nice idea, and laying
> > > the groundwork to make it possible could also be sensible, but right
> > > now it seems like we aren't ready and the reason for the introduction
> > > of this code is/was for unrelated reasons.
> > 
> > We would need a button to create an Activity bundle and pop it into  
> > the Journal). So work flow could be:
> > 
> > 1) download some activity via Browse
> > 2) Start it up
> > 3) Click on "Edit Source"  – would be new feature, currently we just  
> > have "View Source", but there is a patch for the view that could be  
> > close if desired, from Lucian http://wiki.sugarlabs.org/go/Development_Team/Almanac#How_do_I_create_a_text_box_for_code_editing.3F
> > 4) Quit, Start, test, goto 3 and repeat
> > 5) Click on "Keep Activity bundle to Journal" – would be new feature  
> > in "Edit Source" toolbar
> > 6) Use "Send to <friend>" to share bundle with others
> > 
> > As long as you kept the original bundle in your Journal, you can click  
> > it to restore the original code, and click a bundle you or a friend  
> > made to hop back in to an edit workflow cycle.
> > 
> > Plenty to polish and smooth workflow, but an editable source view and  
> > a 'make bundle' button don't seem to horrendous to consider if this is  
> > seen as a desired feature to push on.
> > 
> > > I also feel that this
> > > functionality would rarely be used in the field.
> > 
> > 
> > Agreed, but our minority percentage of 'to be geek' learners (we only  
> > need ~0.01% of users to be geeky enough to get us ~1000 new activity  
> > Authors) would be the ones in field to benifit, though clearly it  
> > would allow many more just to tinker with python. I can imagine  
> > starting with a template activity (could be helloworld, could be a  
> > Physics template, Simple game template etc) where folks then modify  
> > and add to it to create their own activity, game, et al, and learn how  
> > to build new activities. Work flow would be basically hack on live  
> > installed version for a while it for a while, bundle it when you want  
> > to keep a snapshot to Journal (version), repeat, rinse, share bundle  
> > once you're happy with it.
> > 
> > Disclaimer, there are likely better ways of doing this but at great  
> > development cost, this is my view of the likely shortest path to  
> > feature.
> > 
> > Regards,
> > --Gary
> 
> +1024
> 
> thats the original idea behind
> http://wiki.sugarlabs.org/go/Features/Activity_Objects
> 
> imho for me "versioning" sounds really dreadful
> lets think about all these activities/clones/versions in more simple way
> 
> kid A created a toy #1 from LEGO bricks(in our case activity), kid B
> decided that it looks cool, "cloned" it and created his own toy #2,
> kid C using the right moment borrowed #1 and #2 toys. Should kids
> track all these relationships between #1 -> cloned-to-#2 -> moved to C? 
> All these toys are unique entities(in our case unique Journal objects).
> 
> At the same time "serious" men(like sugar developers) could do serious
> things(like releasing new versions, applying patches, cloning git repos,
> track all versions in git) but from kids POV incoming new activity
> version is just another object in his Journal which appears after
> running updater from control panel

> (we should provide some way to
> override existed activities but make this process explicit).

In that case we can switch our activity identification scheme
from bundle_id/version to bundle_id/source/version i.e.

* versions of Terminal from native packages is one thread
* versions of Terminal from ASLO is another thread
* hand made versions of Terminal is 3rd thread
* hand made versions of Terminal from my friend is 4th thread

User can upgrade(downgrade?) activity within one thread thus we won't
get many .xo objects in Journal(will have only last one) from ASLO
for example.

-- 
Aleksey