[Etoys] Etoys Based Activity - FreeCell Sugar interactions

[Milan Zimmermann]

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?"
	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)

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)

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
		- 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?"
	
	FreeCell class startUpInSugar.

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.

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

- 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...

- 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

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

Thanks Milan

PS:

A few weeks ago I also investigated a way to make a Squeak based KDE4 Plasmoid 
("applet" running in the Plasma container) and manage the Squeak Plasmoid only 
via DBus. It turns out that, for some likely misguided performance concerns, 
Plasmoids are not managed by their container via DBus, but rather internal Qt 
API. So what I thought would be neet is likely not possible without some sort 
of wrapper, and probably out of reach for practical time considerations, so I 
will ignore that part. (Maybe possible in gnome..)


=======================
old part



On May 5, 2009, Bert Freudenberg wrote:
> On 05.05.2009, at 07:27, Milan Zimmermann wrote:
> > On May 4, 2009, Bert Freudenberg wrote:
> > > On 04.05.2009, at 07:31, Milan Zimmermann wrote:
> > > > Hi Bert,
> > > >
> > > > I finally did some investigation into Squeak interaction with
> >
> > DBus and
> >
> > > > Datastore. I went through the classes that implement the DBus and
> > > > Datastore
> > > > interaction. This is some great stuff! Among others, if I
> >
> > understand
> >
> > > > this correctly, your Squeak DBus client framework could, for
> > > > example, allow to use Squeak to write a KDE or gnome panel applet?
> > > > But that is an aside.
> > >
> > > Yes indeed.
> >
> > Very cool. I think such functionality could also add interest in
> > Squeak... Would it makes sense to add Squeak to this list
> >
> > http://www.freedesktop.org/wiki/Software/DBusBindings
> > ?
>
> Yes. This would be the official page for it:
>
> http://squeaksource.com/dbus.html
>
> > > A fun way to explore it is to run Squeak on a regular KDE/
> > > Gnome desktop and open the DBus Explorer from the World menu. You
> >
> > can,
> >
> > > for example, find the screen saver on the session bus and tell it to
> > > blank the screen ...
> >
> > Or exiting any application :) This is worth a blog by itself.
>
> Oh, nice idea. Announce it on squeak-dev, too. And maybe have your
> blog (or the posts tagged with "squeak") added to planet.squeak.org ...
>
> > World Menu -> Open -> DbusExplorer.
> > Expand DBus sessionBus
> > open KDE system konsole
> > org.kde.konsole/konsole/MainWindow_1/actions/file_quit/
> > com.Trolltech.QT.QAction.trigger
> > yellow(middle or right)-click, select "invoke method"
> > konsole gone
> > Neat...
>
> Hehe. Did you notice you can even invoke methods with arguments?
>
> > > Well. IMHO we should *not* save the whole project to the Journal.
> >
> > This
> >
> > > is not supposed to be an Etoys activity, but a Squeak application.
> >
> > It
> >
> > > should only store and retrieve its relevant state. For starters I'd
> > > only store the statistics, which is about 10 numbers.
> >
> > I did not think of saving only the state of the game, but it is
> > definitely a better approach. Maybe I am missing something here
> > though. For example, in Etoys, saving a project writes the whole
> > project as a pr file - I assume .PR is some for of serialized
> > everything in the project, not just what have changed.
>
> Yes, it writes out pretty much everything reachable from "Project
> current".
>
> > When attempting to store only FreeCell's state, I have a few things
> > to learn and understand:
> > - without looking I am surptised FreeCell's state is only 10
> > numbers, it seems that position of the cards must be more than that
> > unless it's packed somehow - I will look
>
> No, that is only the statistics. Not sure how useful it is to store
> the entire state.
>
> > - which objects represent the state stored
> > - how to serialize it (well that should be relatively
> > straightforward knowing the objects)
> > - what method will write the serialized FreeCell state to Journal
> > instead of
> > SugarDatastoreDirectory>>#writeProjectinFileNamed:fromDirectory:
>
> In FreeCell.st I patch SugarLauncher>>quit which normally would store
> the project, so nothing is stored but the activity simply quits.
>
> This is triggered either by pressing the stop button in the tool bar,
> or by a #windowClose event the launcher receives because in its
> #startUp method it registered itself for these events:
>
> 	World windowEventHandler: self.
>
> So if we replace the SugarLauncher mechanism we should register these
> events to be sent to FreeCell instead.
>
> > - what does assign the "ownership" of that file on Journal as FreeCell
>
> Just the meta data properties, in particular the "activity" property.
> See
>
> http://wiki.laptop.org/go/Low-level_Activity_API#Meta_Data
>
> > - how to deserialize the state
> > - how to import it back to the game
> >
> > > The regular Etoys Sugar startup happens in SugarLauncher>>startUp.
> >
> > yes
> >
> > > There it looks for the ACTIVITY_ID parameter to see if we are
> >
> > actually
> >
> > > running under Sugar, and an OBJECT_ID which is present if we are
> > > resuming a Journal entry.
> >
> > yes
> >
> > > I think the best way would be to use different parameter names in
> > > FreeCell.sh, perhaps FREECELL_ACTIVITY_ID and FREECELL_OBJECT_ID.
> >
> > Then
> >
> > > the Etoys logic would not kick off
> >
> > logic in SugarLauncher.startup?
>
> Yes, because that looks for ACTIVITY_ID and OBJECT_ID.
>
> > > and would not try to open the
> > > object as project, but we could provide our own startup method
> >
> > that we
> >
> > > would simply call at the end of FreeCell.st.
> >
> > and load the state read from the Datastore/Journal?
>
> Right, if the FREECELL_OBJECT_ID parameter is present it would hold
> the object id to load.
>
> > > > 4) Ability to start using the black Launcher ribbon on top, with
> >
> > the
> >
> > > > standard Etoys project name a project stop widget that would call
> > > > the commands from 1 and 2. .
> > >
> > > Well if you look at the end of FreeCell.st you see the tool bar is
> > > explicitly toggled off. Before re-enabling it we would have to
> > > customize it (see class SugarNavigatorBar).
> >
> > Ah I thought the bar was SugarLauncher. Another thing to look at.
>
> No, SugarLauncher is registered with the AutoStart class, just like
> the ProjectLauncher which handles the regular Etoys startup (like
> loading a project in the browser plugin etc.).
>
> SugarLauncher handles all the Sugar-related session tasks - datastore,
> collaboration, etc. It's not a pure launcher anymore and probably
> should be factored into some more specific classes.
>
> > I am actually quite excited about this - you did lots of great stuff
> > there that deserves attention, use, and maybe we can do some
> > marketing for it :) by having a few blogs and a small tutorial at
> > some point. Long time ago I played with DCOP in KDE and Dbus is
> > similar but that's not the point - The point is that apart from it's
> > usefulness for Sugar, what you did can be also used for Squeak /
> > Etoys applications to be integral part of KDE and Gnome desktops
> > (perhaps even OS X - I am reading Dbus is ported there there but
> > probably not integrated). I especially like the idea trying to write
> > a KDE Panel applet in Squeak :)
>
> Sounds like a fun thing to try, yes :)
>
> - Bert -
>
>
> _______________________________________________
> Etoys mailing list
> Etoys at lists.laptop.org
> http://lists.laptop.org/listinfo/etoys


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/etoys/attachments/20090531/9f03102b/attachment-0001.htm