[Etoys] Etoys Based Activity - FreeCell Sugar interactions

Tue May 5 14:20:46 EDT 2009

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/etoys/attachments/20090505/f80915c8/attachment.htm