Tweak and Croquet questions

Hi everyone,

I sent a general question a while ago, about some work I'm trying to  
do using Croquet to share 2D worlds. I'm focusing right now on one  
specific question - how to share a small world, either Tweak or  
Morphic, on a Croquet island, and then building out from there. My  
goal is share programming sessions using the usual Smalltalk tools -  
browsers, inspectors, and workspaces - and to record programming  
sessions for future viewing.

I have done some more work on the problem and am still pretty  
confused. I think this is due to my unfamiliarity with Tweak and  
Croquet in particular - I am very familiar with Smalltalk and Squeak  
in general - so hopefully a few pointers should clear up my  
misunderstanding.

Here is one particular question related to my current focus. I had  
some success doing the below with a Morphic world, but quickly ran  
into problems where, e.g., a Morph would require a pointer to the  
global EventSensor, or some other such thing; and so I decided to try  
again with Tweak and my improved understanding of Croquet.

I am trying to share a Tweak world (say, a CProjectBuilder, or even  
something simpler) on a Croquet island, displaying it in a  
CProjectMorph on each participant. The first problem I run into is  
that the world displays, but won't respond to any events. My process  
browser shows a ton of suspended "runOneCycle" ScriptProcesses.

        They appear to be suspended because their scheduler is nil;
        it looks like the scheduler is set initally from the active  
process's scheduler,
                in ScriptProcess>>newScript;
        or else it can be set.

But that's where my understanding stops. Where should I look next?

(I am using the Croquet 1.0.18 SDK, updated from the "stable"  
Monticello repositories.)

Thanks for any help you can offer.

Best regards,
Benjamin Schroeder

Hi Josh,

Ah, that makes sense - it explains why I was seeing so many event  
script processes. To see if I understand correctly, the basic problem  
is that the Squeak scheduler is outside the island, and runs at its  
own pace. Since Tweak relies heavily on it, we can't reliably  
replicate Tweak behavior inside a Croquet island. (And of course  
Morphic, as much as I like it, has its own modularity issues.)

I like the idea of running only the Browser model on the island. I am  
not sure whether I understand where Croquet messages are directed  
with embeddable apps. Is the following a correct sequence?

        Participant clicks mouse
        Mouse event is sent to local UI
        Local UI sends future message to model
        Model's change is reflected in each participant's UI

If this is correct, everything in the model (which, for Browsers, is  
a lot, including, I believe, list selections) will be replicated to  
each participant correctly. However, I'm concerned that transient UIs  
like menus will require special handling to be seen by all participants.

Yes, this is true.

Strictly as a sort of hack, I think it is possible to store code on  
an island in a limited fashion without too much work. Say each  
participant starts with the same basic system classes, and confines  
programming activity to classes in a limited set of system  
categories. Then the problem becomes how to separate a set of classes  
from the main Smalltalk dictionary.

Again, strictly in a limited fashion, I think it is possible to take  
advantage of the old "environments" support to do this - I've had a  
little success in a non-replicated image.

Now, the browser UI isn't ideal for this sort of programming, and it  
might only work correctly for a subset of things; and it ignores  
questions like where source code might be stored for participants who  
receive a snapshot that already has classes in it (no replicated  
changes file). But it might be enough to allow some playing with the  
problem, and hence learning about what a "real" solution would be  
like! :)

Thanks again. I'll try out some things and report back!

Benjamin Schroeder

On Aug 8, 2007, at 3:54 PM, Benjamin Schroeder wrote:

Exactly.

>
> I like the idea of running only the Browser model on the island. I  
> am not sure whether I understand where Croquet messages are  
> directed with embeddable apps. Is the following a correct sequence?
>
> Participant clicks mouse
> Mouse event is sent to local UI
> Local UI sends future message to model
> Model's change is reflected in each participant's UI

This is essentially correct.  IIRC, the sequence is:
        - participant clicks mouse
        - future event is sent to targeted object (in this case a TEmbeddedApp)
        - event is propagated off-island to the TEmbeddableApp subinstance  
that corresponds to the on-island TEmbeddedApp

At this point, the behavior depends on the particular subclass of  
TEmbeddableApp.  In your case, the chain of events will be something  
like:
        - off-island view checks to see who originated the mouse event
                - if it was someone else, discard the event
                - this ensures that the model gets only one future message (see  
next step)
        - send the future message to update the model
        - model receives future message
                - change is reflected in each participant's UI

(forgive me if I missed a detail, I haven't worked with this version  
of Croquet recently)

To be a bit more concrete, you might make a subclass of Browser named  
OffIslandBrowser.  You would could then override some methods like this:

classListIndex: anInteger
        browserRef future classListIndex: anInteger

reallySetClassListIndex: anInteger
        super classListIndex: anInteger

The first method would be triggered when your mouse-click is handled  
by the non-replicated UI.  The second method would be triggered when  
the future message is received by the replicated browser (you'll have  
to arrange for this to happen, probably by using #runScript:when: to  
let the off-island browser listen for changes in the on-island browser).


> If this is correct, everything in the model (which, for Browsers,  
> is a lot, including, I believe, list selections) will be replicated  
> to each participant correctly. However, I'm concerned that  
> transient UIs like menus will require special handling to be seen  
> by all participants.

Probably.  This could be a bit tricky.  I wouldn't worry about it at  
first.

Have fun!  Looking forward to hearing about it...

Josh


>
> Benjamin Schroeder
>

On Aug 8, 2007, at 17:09 , Joshua Gargus wrote:

> On Aug 8, 2007, at 3:54 PM, Benjamin Schroeder wrote:
>> Thanks again. I'll try out some things and report back!
>
> Have fun!  Looking forward to hearing about it...

Also note that this has been made to work once before, though not in  
the current Croquet version - see the TinLizzie paper at http://
vpri.org/html/writings.htm

I'm sure you could get a peek at the TinLizzie image that was used  
for these experiments ... but I'm not sure where the latest (or  
actually any) version is right now.

- Bert -

Hi Benjamin,

Even though you said you were working on a 2D project, it somehow  
didn't penetrate my skull until seeing Bert's email.

Most of what I said is still valid, but TEmbeddedApp is specific to  
3D Croquet.  You might look at it for inspiration, but the code won't  
be directly usable.

Sorry for any confusion,
Josh


On Aug 8, 2007, at 10:17 PM, Bert Freudenberg wrote: