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