Hi Bert,
Thanks for your detail comments. I will probably try to get the "patched" version working this weekend so that I can get quickly to the part of coding the Datastore interactions. I have been stalling on this too long (mostly time reasons I cannot get anything done except weekends), so I want to get to the Datastore part first as a step 1 experiment.
But I completely agree it is best to replace SugarLauncher with a more generic one asy ou suggested, which I'd make to be step 2.
Let me see how far I get this weekend on step 1. I have a feeling I will ask for help along the way :)
Thanks and later, Milan
On June 1, 2009, Bert Freudenberg wrote:
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 :)
- 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
- 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).
- Add method FreeCell class>>#instance
FreeCellSingleton := FreeCell new. "just a class var" ^ FreeCellSingleton.
- 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)
- Patch SugarLauncher>>#shutDown as follows:
activityId := parameters at: ACTIVITY_ID. objectId := parameters at: OBJECT_ID. freeCell := FreeCell instance. freeCell #shutDownInSugarAsActivity: activityId object: objectId.
- 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
- Add method FreeCell>>#quit which would do:
Sugarlauncher current quit
- 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.
- 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 -
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys