Hi Bert,
Thanks for detail comments - and more notes inline:
On July 27, 2009, Bert Freudenberg wrote:
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.
Yeah, although it seemed sort of nice the FreeCellLauncher would register with Autostart and be launched via startUp but because of the order of code loading and startup it did not work. But playing with it made me understand AutoStart and CodeLoader much better :)
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:
Yes, I wonder what the list of "required" meta data is. I will add what I find in the Sugar document.
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.
There are many silly questions and notes in my code, I will clean it up and refactor - but you did pick a question that matters and I did not really understand - so thanks for explaining it. Also the serialization of Statistics is obvious hack but I will probably not change that, I consider this more of an example of how to do an Activity in Etoys, so cleaning up the other stuff and making it somewhat reusable is more important.
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
true! Also based on your comment below, that we do not need activity-specific FREECELL_ACTIVITY_ID just MY_ACTIVITY_ID, for all activities, I can remove much of the stuff I added to the "generic" startup script.
- 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.
ah, yes I did not think of it.
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".
yes, I "knew" it but later forgot. Will change.. I am trying to think of a better name, PERSISTABLE_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?
Goo question. I first developed it in an image where all changes went to a changeset named mz-free-cell or similar. I just kept saving the image. At some point I file-out the changeset as FreeCell.st, and started loading it using the --document mechanism. At that point, I started just editing FreeCell.st in vi. I also globally added some CTRL-J endlines because when exported, the changeset was missing end of lines.
But anyway, "How to start developing an Etoys-based Sugar Activity" is one of the important things I want to figure out how to describe in the blog: If someone wants to develop a activity similar to FreeCell, how to start? Open Etoys, make changes go to changset, make some changes, file-out, quit, move the file-out to appropriate directory, start FreeCell.sh using the file-out as --document, make some changes etc etc. It IS lots of work just to move the changes around, and difficult to explain, probably a deterrent. Or just keep things in one image and export at the end - but that is hard to test. Or edit the FreeCell.st as a file ... If I am being somewhat understandable here, what is your opinion?
- 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
yes - milan.zimmermann@gmail.com
(but, not yet ready)
- 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.
Yeah I have a git client :) I will check with you before I put it in, maybe at the end of next weekend - large scale cleanup is needed first :)
Hope you guys enjoyed Squeakfest Brazil!
Later, Milan
We did, it was a great event. Hopefully someone will write an extended report ...
Great to hear! Next few days I plan to check tickets and accomodations in LA for 10,11,12 .
Milan
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev