<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 2009-05-05 11:45, Bert Freudenberg wrote:
<blockquote
cite="mid:9FCCECD7-F307-4E4C-9385-F19460350020@freudenbergs.de"
type="cite">
<pre wrap="">On 05.05.2009, at 07:27, Milan Zimmermann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On May 4, 2009, Bert Freudenberg wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 04.05.2009, at 07:31, Milan Zimmermann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Bert,
I finally did some investigation into Squeak interaction with
</pre>
</blockquote>
</blockquote>
<pre wrap="">DBus and
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Datastore. I went through the classes that implement the DBus and
Datastore
interaction. This is some great stuff! Among others, if I
</pre>
</blockquote>
</blockquote>
<pre wrap="">understand
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">Yes indeed.
</pre>
</blockquote>
<pre wrap="">Very cool. I think such functionality could also add interest in
Squeak... Would it makes sense to add Squeak to this list
<a class="moz-txt-link-freetext" href="http://www.freedesktop.org/wiki/Software/DBusBindings">http://www.freedesktop.org/wiki/Software/DBusBindings</a>
?
</pre>
</blockquote>
<pre wrap=""><!---->
Yes. This would be the official page for it:
<a class="moz-txt-link-freetext" href="http://squeaksource.com/dbus.html">http://squeaksource.com/dbus.html</a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">can,
</pre>
<blockquote type="cite">
<pre wrap="">for example, find the screen saver on the session bus and tell it to
blank the screen ...
</pre>
</blockquote>
<pre wrap="">Or exiting any application :) This is worth a blog by itself.
</pre>
</blockquote>
<pre wrap=""><!---->
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 ...
</pre>
<blockquote type="cite">
<pre wrap="">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...
</pre>
</blockquote>
<pre wrap=""><!---->
Hehe. Did you notice you can even invoke methods with arguments?
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Well. IMHO we should *not* save the whole project to the Journal.
</pre>
</blockquote>
<pre wrap="">This
</pre>
<blockquote type="cite">
<pre wrap="">is not supposed to be an Etoys activity, but a Squeak application.
</pre>
</blockquote>
<pre wrap="">It
</pre>
<blockquote type="cite">
<pre wrap="">should only store and retrieve its relevant state. For starters I'd
only store the statistics, which is about 10 numbers.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, it writes out pretty much everything reachable from "Project
current".
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->
No, that is only the statistics. Not sure how useful it is to store
the entire state.
</pre>
<blockquote type="cite">
<pre wrap="">- 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:
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">- what does assign the "ownership" of that file on Journal as FreeCell
</pre>
</blockquote>
<pre wrap=""><!---->
Just the meta data properties, in particular the "activity" property.
See
<a class="moz-txt-link-freetext" href="http://wiki.laptop.org/go/Low-level_Activity_API#Meta_Data">http://wiki.laptop.org/go/Low-level_Activity_API#Meta_Data</a>
</pre>
<blockquote type="cite">
<pre wrap="">- how to deserialize the state
- how to import it back to the game
</pre>
<blockquote type="cite">
<pre wrap="">The regular Etoys Sugar startup happens in SugarLauncher>>startUp.
</pre>
</blockquote>
<pre wrap="">yes
</pre>
<blockquote type="cite">
<pre wrap="">There it looks for the ACTIVITY_ID parameter to see if we are
</pre>
</blockquote>
<pre wrap="">actually
</pre>
<blockquote type="cite">
<pre wrap="">running under Sugar, and an OBJECT_ID which is present if we are
resuming a Journal entry.
</pre>
</blockquote>
<pre wrap="">yes
</pre>
<blockquote type="cite">
<pre wrap="">I think the best way would be to use different parameter names in
FreeCell.sh, perhaps FREECELL_ACTIVITY_ID and FREECELL_OBJECT_ID.
</pre>
</blockquote>
<pre wrap="">Then
</pre>
<blockquote type="cite">
<pre wrap="">the Etoys logic would not kick off
</pre>
</blockquote>
<pre wrap="">logic in SugarLauncher.startup?
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, because that looks for ACTIVITY_ID and OBJECT_ID.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">and would not try to open the
object as project, but we could provide our own startup method
</pre>
</blockquote>
<pre wrap="">that we
</pre>
<blockquote type="cite">
<pre wrap="">would simply call at the end of FreeCell.st.
</pre>
</blockquote>
<pre wrap="">and load the state read from the Datastore/Journal?
</pre>
</blockquote>
<pre wrap=""><!---->
Right, if the FREECELL_OBJECT_ID parameter is present it would hold
the object id to load.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">4) Ability to start using the black Launcher ribbon on top, with
</pre>
</blockquote>
</blockquote>
<pre wrap="">the
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">standard Etoys project name a project stop widget that would call
the commands from 1 and 2. .
</pre>
</blockquote>
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">Ah I thought the bar was SugarLauncher. Another thing to look at.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">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 :)
</pre>
</blockquote>
<pre wrap=""><!---->
Sounds like a fun thing to try, yes :)
- Bert -
</pre>
</blockquote>
Milan, you can take a look at the JournalMorph I'm sporadically working
on:<br>
<a class="moz-txt-link-freetext" href="http://wiki.laptop.org/images/5/54/JournalMorph.005.pr">http://wiki.laptop.org/images/5/54/JournalMorph.005.pr</a><br>
This code is unfortunately stripped of any comment as I have developed
in the etoy image in Sugar.<br>
<br>
Karl<br>
<br>
</body>
</html>