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.
As Step 1, my goal was to figure out how to save a project in Journal from a set of commands in Workspace. Going to the debugger, I found that if I open a project in Etoys, and in a workspace, and do
Project current storeOnServerWithNoInteractionThenQuit.
the project is saved in Journal, and on restart, Etoys must have read the Journal saved project because it shows any changes I have made in the project. It seems that the core method called from storeOnServerWithNoInteractionThenQuit that interacts with Datastore is
SugarDatastoreDirectory>> #writeProject: self inFileNamed: fileName fromDirectory: localDirectory
So I tried to do the the same (Project current storeOnServerWithNoInteractionThenQuit.) from a workspace in the FreeCell activity. When performed, it does write to the Journal, but upon restart, I get an exception that appears a DBus object cannot be found - picture attached.
Could the difference be it because Freecell, on startup, does not setup some DBus interaction?
Well in any case, I am looking for some help trying to figure this out. I was thinking about these steps I'd like to achieve:
1) Command in Workspace that saves the FreeCell project on Journal. I seem to be able to do that, but on fairly high level ( Project current storeOnServerWithNoInteractionThenQuit.). Eventually I'd like to get it done with more but lower level commands.
2) Sure and understood way to open the saved Journal Project in FreeCell. (So far within Etoys it seems to work, but I have little understanding of it. In FreeCell it does not)
3) A command or set of commands in workspace, which wil allow to Rename the FreeCell project (and save on Journal under the new name)
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. .
5) More interaction such as copy/paste on Journal
Do these goals and order make sense?
I will try to maintain a blog about what I am playing with.
http://mzimmerm.blogspot.com/2009/05/how-to-install-and-run-sugar- activity.html
I am unfortunately frustratingly slow and sometimes fail to respond for a long time, combination of lack of time and experience in this area (Squeak/DBus/Sugar), but will keep going... Appreciate any help.
Milan
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. 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 ...
As Step 1, my goal was to figure out how to save a project in Journal from a set of commands in Workspace. Going to the debugger, I found that if I open a project in Etoys, and in a workspace, and do
Project current storeOnServerWithNoInteractionThenQuit.the project is saved in Journal, and on restart, Etoys must have read the Journal saved project because it shows any changes I have made in the project. It seems that the core method called from storeOnServerWithNoInteractionThenQuit that interacts with Datastore is
SugarDatastoreDirectory>> #writeProject: self inFileNamed: fileName fromDirectory: localDirectorySo I tried to do the the same (Project current storeOnServerWithNoInteractionThenQuit.) from a workspace in the FreeCell activity. When performed, it does write to the Journal, but upon restart, I get an exception that appears a DBus object cannot be found - picture attached.
No, this is a regular file-not-found prompt. It looks like an file from the Datastore could not be opened. You should press alt-. at this prompt and investigate what it's trying to do.
Could the difference be it because Freecell, on startup, does not setup some DBus interaction?
No, that should not be the problem.
Well in any case, I am looking for some help trying to figure this out. I was thinking about these steps I'd like to achieve:
- Command in Workspace that saves the FreeCell project on Journal.
I seem to be able to do that, but on fairly high level ( Project current storeOnServerWithNoInteractionThenQuit.). Eventually I'd like to get it done with more but lower level commands.
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.
- Sure and understood way to open the saved Journal Project in
FreeCell. (So far within Etoys it seems to work, but I have little understanding of it. In FreeCell it does not)
The regular Etoys Sugar startup happens in SugarLauncher>>startUp. 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.
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 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.
- A command or set of commands in workspace, which wil allow to
Rename the FreeCell project (and save on Journal under the new name)
Renaming means nothing more than storing in the DataStore with different meta data. Inspect
SugarDataStore new getProperties: someObjectId
(see the SugarDataStore class example to find out object ids). This meta data is just a dictionary that you can modify and later pass to the datastore's "update" function.
You should try to create and retrieve a file for the datastore manually in a workspace first. Like in this example, where a file is first read from the datastore, then modified, the saved again:
http://wiki.squeakland.org/display/sq/Saving+to+a+file+in+Sugar
This is actually a pretty complete example of what would have to happen for FreeCell on startup and on saving (reading a datastore object on startup, and creating or updating the datastore object to save). The difference would be that no find call is necessary because we would know the object id (if any) already.
One minor thing missing is that an activity is supposed to watch the journal entry so it catches e.g. renames done on the Journal screen. Etoys actually does this (try resuming an Etoys project, switch to Journal, rename it there, switch back to Etoys, name should have changed there, too). See #monitorJournalEntry.
- 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).
- More interaction such as copy/paste on Journal
What would you like to paste into FreeCell? Not sure how useful that would be.
Do these goals and order make sense?
I will try to maintain a blog about what I am playing with.
http://mzimmerm.blogspot.com/2009/05/how-to-install-and-run-sugar-activity.h...
Nice. I commented about two misconceptions.
I am unfortunately frustratingly slow and sometimes fail to respond for a long time, combination of lack of time and experience in this area (Squeak/DBus/Sugar), but will keep going... Appreciate any help.
Just take your time, I'm glad someone else is finally looking at this stuff :)
- Bert -
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 ?
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. 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...
As Step 1, my goal was to figure out how to save a project in Journal from a set of commands in Workspace. Going to the debugger, I found that if I open a project in Etoys, and in a workspace, and do
Project current storeOnServerWithNoInteractionThenQuit.the project is saved in Journal, and on restart, Etoys must have read the Journal saved project because it shows any changes I have made in the project. It seems that the core method called from storeOnServerWithNoInteractionThenQuit that interacts with Datastore is
SugarDatastoreDirectory>> #writeProject: self inFileNamed: fileName fromDirectory: localDirectorySo I tried to do the the same (Project current storeOnServerWithNoInteractionThenQuit.) from a workspace in the FreeCell activity. When performed, it does write to the Journal, but upon restart, I get an exception that appears a DBus object cannot be found - picture attached.
No, this is a regular file-not-found prompt. It looks like an file from the Datastore could not be opened. You should press alt-. at this prompt and investigate what it's trying to do.
I will debug it.
Could the difference be it because Freecell, on startup, does not setup some DBus interaction?
No, that should not be the problem.
OK.
Well in any case, I am looking for some help trying to figure this out. I was thinking about these steps I'd like to achieve:
- Command in Workspace that saves the FreeCell project on Journal.
I seem to be able to do that, but on fairly high level ( Project current storeOnServerWithNoInteractionThenQuit.). Eventually I'd like to get it done with more but lower level commands.
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.
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 - 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: - what does assign the "ownership" of that file on Journal as FreeCell - how to deserialize the state - how to import it back to the game
- Sure and understood way to open the saved Journal Project in
FreeCell. (So far within Etoys it seems to work, but I have little understanding of it. In FreeCell it does not)
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?
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?
- A command or set of commands in workspace, which wil allow to
Rename the FreeCell project (and save on Journal under the new name)
Renaming means nothing more than storing in the DataStore with different meta data. Inspect
SugarDataStore new getProperties: someObjectId
(see the SugarDataStore class example to find out object ids). This meta data is just a dictionary that you can modify and later pass to the datastore's "update" function.
ah i see - so the getProperties reads the database key-values and update just puts it back with whatever changes we may have done.
You should try to create and retrieve a file for the datastore manually in a workspace first. Like in this example, where a file is first read from the datastore, then modified, the saved again:
http://wiki.squeakland.org/display/sq/Saving+to+a+file+in+Sugar
This is actually a pretty complete example of what would have to happen for FreeCell on startup and on saving (reading a datastore object on startup, and creating or updating the datastore object to save). The difference would be that no find call is necessary because we would know the object id (if any) already.
i saw the example but did not study it - actually I tried, but did not get far enough. I will play with it from workspace, and likely ask some questions.
One minor thing missing is that an activity is supposed to watch the journal entry so it catches e.g. renames done on the Journal screen. Etoys actually does this (try resuming an Etoys project, switch to Journal, rename it there, switch back to Etoys, name should have changed there, too). See #monitorJournalEntry.
I see - will play with that as well.
- 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.
- More interaction such as copy/paste on Journal
What would you like to paste into FreeCell? Not sure how useful that would be.
Well I though of it as an exercise, rather then useful feature, but it could be used like this: User could copy and later paste another state of FreeCell from the Sugar black ribbon on the left - this would replace the current game with the one that was pasted
Do these goals and order make sense?
I will try to maintain a blog about what I am playing with.
http://mzimmerm.blogspot.com/2009/05/how-to-install-and-run-sugar-activit y.html
Nice. I commented about two misconceptions.
Thanks! That means that section of blog is really for a developer that wants to do things manually (rather then just install FreeCell by clicking "download" - I will modify the blog with that comment so it is less confusing
I am unfortunately frustratingly slow and sometimes fail to respond for a long time, combination of lack of time and experience in this area (Squeak/DBus/Sugar), but will keep going... Appreciate any help.
Just take your time, I'm glad someone else is finally looking at this stuff :)
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 :)
ok time to go, I have stuff to try during the week and weekend, but I should have some questions earlier...
Later, Milan
- Bert -
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
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
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.
- 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 -
On 2009-05-05 11:45, 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
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.
- 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 -
Milan, you can take a look at the JournalMorph I'm sporadically working on: http://wiki.laptop.org/images/5/54/JournalMorph.005.pr This code is unfortunately stripped of any comment as I have developed in the etoy image in Sugar.
Karl
On May 5, 2009, Karl Ramberg wrote:
Milan, you can take a look at the JournalMorph I'm sporadically working on: http://wiki.laptop.org/images/5/54/JournalMorph.005.pr This code is unfortunately stripped of any comment as I have developed in the etoy image in Sugar.
Karl
Hi Karl,
Thanks I will take a look this evening
Milan
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
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.
- 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@lists.laptop.org http://lists.laptop.org/listinfo/etoys
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 -
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
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Karl Ramberg -
Milan Zimmermann