[Etoys] Etoys Based Activity - FreeCell Sugar interactions

Bert Freudenberg bert at freudenbergs.de
Mon Jun 1 07:42:53 EDT 2009


On 31.05.2009, at 23:23, Milan Zimmermann wrote:

> Hi Bert,
>
> After 3 weekend delay I got back today to FreeCell. I re-read the  
> email thread and put together high level steps of how FreeCell's  
> statistics state could be managed. I hope the steps are  
> uderstandable, and realize architecturally it is not very nice, but  
> a step..
>
> Below, I am listing base code (additions and patches) that would  
> plugin FreeCell into the workflow so that everything is in place  
> where it's statistics state could be managed, serialized and stored  
> in Datastore. Could you comment if the following would work as a  
> first step to play with the Datastore stuff in FreeCell - Thanks.  
> There are some questions at the end, and I appreciate any  
> suggestions and alternatives :)
>
>
> 1) Patch SugarLauncher>>#startUp to call
> self class allInstances do: [:ea| ea shutdown]. "is this neded?"

It's a safety net, not strictly needed.

> parameters at 'ACTIVITY_ID' ifPresent: [:activityId|
> objectId := "todo get objectId".
> "Make FreeCell and recover statistics from journal"
> FreeCell class startUpInSugarForActivity: activityId object: objectId.
> World windowEventHandler: self.
> ].
>
> (A note: I realize you suggested to use FREECELL_ACTIVITY_ID and  
> FREECELL_OBJECT_ID instead of ACTIVITY_ID and OBJECT_ID and then we  
> would not have to patch SugarLauncher>>#startup, but it seems we  
> probably need to patch some other SugarLauncher methods such as  
> invite anyway, so I thought this could be ok)

No, in that case SugarLauncher would not be used at all, that was what  
I was proposing. Better implement the whole caboodle on your own so  
you know what's happening. Less magic ;) OTOH SugarLauncher is hard- 
wired in some places, like in the SugarNavBar, so some refactoring may  
be needed anyway.

A potential problem is that the FreeCell code gets loaded via  
ProjectLauncher so it depends on ProjectLauncher being started first  
before SugarLauncher:

	AutoStart installedLaunchers


> 2) Add method FreeCell class>>#startUpInSugarForActivity: activityId  
> object: objectId
>
> which would perform the steps currently performed in the FreeCell.st  
> doits:
>
> Project current flapsSurpressed: true.
> World color: Color black.
> FreeCell
> instance
> (recoverStatisticsOnSugarStartUpForActivity: activityId object:  
> objectId)
> openInWorld.
> (... center and zoom to screen extent)

Yes, though objectId may not be present (if this was run the first  
time).

> 3) Add method FreeCell class>>#instance
> FreeCellSingleton := FreeCell new. "just a class var"
> ^ FreeCellSingleton.
>
> 4) Add method FreeCell>>#recoverStatisticsOnSugarStartUpForActivity:  
> activityId object: objectId
> this method is eventually called from patched  
> SugarLauncher>>#startUp, and it would do:
> - use activityId and objectId to read Datastore, and obtain value  
> for key=serialized_statistics

You only need the object id to read from datastore.

> - obtain sessionWins, sessionLosses, totalWins ... etc from  
> serialized_statistics_value
> - set the deserialized values on the FreeCellStatistics members.  
> (This will need a simple setter of the statistics values)
>
> 5) Patch SugarLauncher>>#shutDown as follows:
> activityId := parameters at: ACTIVITY_ID.
> objectId := parameters at: OBJECT_ID.
> freeCell := FreeCell instance.
> freeCell #shutDownInSugarAsActivity: activityId object: objectId.
>
>
> 6) Add method FreeCell>>#shutDownInSugarAsActivity: activityId  
> object: objectId
> which would :
> - serialize sessionWins, sessionLosses, totalWins ... etc to  
> serialized_statistics_value
> - put on Datastore, for activityId and objectId, an entry with  
> key=serialized_statistics, value=serialized_statistics_value
>
> 7) Add method FreeCell>>#quit which would do:
> Sugarlauncher current quit
>
>
> 8) Patch SugarLauncher>>#quit to call
> self leaveSharedActivity. "is this needed?"
> Smalltalk quitPrimitive. "i hope this calls shutDown?"

No, this quits immediately ...

> FreeCell class startUpInSugar.

... meaning you need to do the FreeCell shutdown before quitting.

> 9) Export the changes to FreeCell.st. so it will contain roughtly:
> - patches for:
> - SugarLauncher>>#startUp
> - SugarLauncher>>#shutDown
> - SugarLauncher>>#quit
> - FreeCell>>#quit
>
> I did not run any of this .. this is my next step, but I wanted to  
> run it by you for obvious problems, so:
>
> Questions, comments and doubts:
> =============================
>
> - Would this work in principal? I am especially not sure around  
> handling the shutDown on quit.

In principle it should work, yes.

> - Are there better more elegant/reusable ways if someone else wants  
> to do something similar to other Etoys activity (ZIP, Speach etc etc)?

Well, replacing SugarLauncher with a more generic one would be good.  
At least the Etoys-specific parts should be factored out. But then  
again getting it to work first is not the worst idea.

> - In step 6, what would be the mime type for the new datastore  
> record, so it is associated with Etoys? There are Mime types listed  
> in /usr/share/sugar/data/mime.defaults but it does not list Etoys...

It should not be associated with Etoys but with FreeCell. You could  
make up any mimetype. It does not have to be listed in the mime  
database, unless you intend to transfer these files outside of Sugar.  
If you want that you need to make up an extension and add a mime rule,  
see mimetypes.xml in

http://wiki.laptop.org/go/Activity_bundles

> - I need to check when etoys start SugarLauncher>>#startUp is  
> performed when I click on a Journal FreeCell item, as startUp  
> contains the FreeCell creation and initialization mechanism

SugarLauncher is registered with AutoStart.

> - I cannot figure out which class puts the ACTIVITY_ID to  
> AbstractLauncher>>member parameters, but that is not needed for the  
> stuff above.

AbstractLauncher>>parameters does lazy initialization. But before  
that, AutoStart>>startUp: actually sets the parameters. In either  
case, #extractParameters is what gets arguments from the command line  
(as passed in the activity script).

- Bert -




More information about the Etoys mailing list