On 27.07.2009, at 02:24, Milan Zimmermann wrote:
Hi Bert,
During last month, I spent quite a bit of time getting FreeCell interact via DBus with Sugar Datastore. I tried to create a FreeCellLauncher which would register with AutoStart, so that nothing relies on special names such as FREECELL_ACTIVITY_ID, and could be used as a framework to develop and deploy other Etoys-based Sugar activities. Many of the directions I took were dead ends, mostly because CodeLauncher which Launches the code such as FreeCell.st cannot at the point of it's execution add FreeCellLauncher to AutoStart, at least to the best what I tried. I eventually accepted that used FREECELL_ACTIVITY_ID etc.
Yes, we do not need launcher classes at all, because we are actually executing a script on startup. That is, yes we need a class that's launching the app, but it would not be triggered by the usual launcher mechanism on image startup but directly from our script document.
So now, FreeCell does persist it's Statistics on Journal, and can be restarted with persisted Statistics from Journal.
Great! I tried it in jhbuild and it indeed created a journal entry :)
There are some meta data properties missing. E.g, the color for the icon should be set to the XO owner's color, which you need to retrieve from the PresenceService:
SugarPresence new getOwner getProperties at: 'color'
And a question I found in your code: "why do we need to check whether the stored values are Strings? We stored them that way..."
Well, the answer is that since Sugar 0.83 the strings we store are converted to byte arrays so when we load them, they are ByteArrays. But some other code assumes that e.g. the title is actually a String so we need to convert there. Also, this does the conversion between utf-8 and WideString, as well as composing accents (Sugar often stores accented characters decomposed into multiple chars). In addition, we are not the only ones modifying these strings, but e.g. the user can modify the description in the Journal.
Everything is ugly at this point - but I want to make it nicer and generalize things so that they could hopefully serve as a cookbook to deploy Etoys objects as Sugar activities using the same mechanism.
Yes, that will be very useful to others.
I also plan to write one or two blogs on this topic in http://etoys- and- olpc.blogspot.com/ (started already but only as drafts).
Yay :)
Here's a couple of notes:
* there is no need for FreeCell.sh because you can put arguments on the exec line in activity.info
* in activity.info, increment activity_version for each new version. Version numbers must be integers. The version number in activity.info should match the xo bundle filename. Version comments go into NEWS (see etoys NEWS)
* we do not really need to customize the OBJECT_ID param name because SugarLauncher>>startUp only looks for ACTIVITY_ID. In fact, the param name does not even need to be customized per activity but it just needs to be something different than "ACTIVITY_ID". Say, "MY_ACTIVITY_ID".
* there is some strange formatting in your code. Some temps lost there names, other methods were saved with style info embedded. How are you developing this?
* Do you have an account here? http://activities.sugarlabs.org/en-US/sugar/addon/4054 I can add you as an author so you can upload releases yourself once they are ready for users
* I did set up a git repository for FreeCell a while ago: http://git.sugarlabs.org/projects/freecell/ If you are familiar with git you might want to contribute right there.
Hope you guys enjoyed Squeakfest Brazil!
Later, Milan
We did, it was a great event. Hopefully someone will write an extended report ...
- Bert -