[etoys-dev] FreeCell: Etoys interaction with Journal via DBus on
milan.zimmermann at sympatico.ca
Tue Jul 28 00:00:36 EDT 2009
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,
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?
> I can add you as an author so you can upload releases yourself once
> they are ready for users
yes - milan.zimmermann at gmail.com
(but, not yet ready)
> * I did set up a git repository for FreeCell a while ago:
> If you are familiar with git you might want to contribute right
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 .
> - Bert -
> etoys-dev mailing list
> etoys-dev at squeakland.org
More information about the etoys-dev