Smalltalk › Squeak › Croquet › Croquet - Dev 2

Multiviews?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

David Faught

Multiviews?

Howard Stearns wrote:
>One particular example of this -- thumbtack annotation -- is in the
>Hedgehog repository and will appear in a later distribution. However,
>there are some issues trying to load from this repository right now, and
>I strongly suggest that you wait a few weeks if possible.

I thought that Mark had fixed this with his most recent updates. Is
that not true? Although the whole task of updating from the base SDK
might be a bit daunting right now.

>The Dormouse branch of Croquet was, I think, the first to make some of
>this filtering available for general use, but this work has not yet been
>carried forward to Hedgehog (the current version). Part of the reason
>for this (and there are many reasons...) is that Dormouse filters (and I
>think, thumbtack annotations) are based on the idea that everything is
>there in the island (i.e., all the collaborators actually have all the
>bits), but not all the parts are displayed to everyone. It is trivial
>for a skilled programmer to futz with their own system so that
>everything can be seen on that system without using the special viewing
>filter.

I wasn't aware that Dormouse was ever available for general use. Must
have missed that one! ;-)

>I am working on a new design that allows multiple separate islands to be
>coordinates by a viewing window (an "interactor"). The common stuff is
>viewed by everyone as they join the island. A different set of content
>to be superimposed is in a different island. The interactor renders
>both islands, coordinating the local execution of the two island clocks.
>Finally, one can drive through the interactor so that it's sort of
>pasted to your camera lens rather than fixed in island-space, such that
>you don't need to stand to the side to see both worlds, but rather can
>walk around and interact with both. Security is achieved through the
>interactors. You only give out the interactors to those whom you want to
>have access. (And the interactors might be non-assignable, revocable,
>etc.)

This sounds like you are working it out as you go (like I do a lot of
the time!). Is there going to be a set of interactors, one per
island, that can all be superimposed on the display? Or one
interactor that rules the display and coordinates with the islands?
Or maybe an interactor hierarchy? This sounds a lot more complicated
that the facets that are discussed in the white papers.

Howard Stearns

Re: Multiviews?

David Faught wrote:
> Howard Stearns wrote:
>> One particular example of this -- thumbtack annotation -- is in the
>> Hedgehog repository and will appear in a later distribution. However,
>> there are some issues trying to load from this repository right now, and
>> I strongly suggest that you wait a few weeks if possible.
>
> I thought that Mark had fixed this with his most recent updates.

Could be!

Is

> that not true? Although the whole task of updating from the base SDK
> might be a bit daunting right now.
>
>> The Dormouse branch of Croquet was, I think, the first to make some of
>> this filtering available for general use, but this work has not yet been
>> carried forward to Hedgehog (the current version). Part of the reason
>> for this (and there are many reasons...) is that Dormouse filters (and I
>> think, thumbtack annotations) are based on the idea that everything is
>> there in the island (i.e., all the collaborators actually have all the
>> bits), but not all the parts are displayed to everyone. It is trivial
>> for a skilled programmer to futz with their own system so that
>> everything can be seen on that system without using the special viewing
>> filter.
>
> I wasn't aware that Dormouse was ever available for general use. Must
> have missed that one! ;-)

http://www.wetmachine.com/itf/item/429
Fortunately, the SDK Beta release made it irrelevant.

>
>> I am working on a new design that allows multiple separate islands to be
>> coordinates by a viewing window (an "interactor"). The common stuff is
>> viewed by everyone as they join the island. A different set of content
>> to be superimposed is in a different island. The interactor renders
>> both islands, coordinating the local execution of the two island clocks.
>> Finally, one can drive through the interactor so that it's sort of
>> pasted to your camera lens rather than fixed in island-space, such that
>> you don't need to stand to the side to see both worlds, but rather can
>> walk around and interact with both. Security is achieved through the
>> interactors. You only give out the interactors to those whom you want to
>> have access. (And the interactors might be non-assignable, revocable,
>> etc.)
>
> This sounds like you are working it out as you go (like I do a lot of
> the time!).

Is there another way?

Is there going to be a set of interactors, one per
> island, that can all be superimposed on the display? Or one
> interactor that rules the display and coordinates with the islands?
> Or maybe an interactor hierarchy? This sounds a lot more complicated
> that the facets that are discussed in the white papers.

This interactor is a general viewing mechanism -- a generalization of
TPortal. They stack, just like TPortal does. The toplevel applicaton
window is really just an interactor that's stuck on your camera lens (no
TWindow frame).

You can have any number of TPortals to an island, and they can be on the
island itself. (For a while there was a little bug that prevented this.)
Interactors are no different. So I don't think it is any more
complicated to use than TPortals now. We didn't run into any
user-difficulty with this in Dormouse or WiscWorlds.

The main conceptual extension of this kind of interactor versus a
TPortal (at least, for this conversation), is that an interactor has TWO
viewpoint postcards, and they both get rendered. One of them is intended
to be an "extra content" or "UI" island that is rooted in a TGroup
instead of a TSpace, and so shares lighting model and such with the
"main" or "traditional" viewpoint.

The part that I'm still wrestling with ("sleeping on" is more apt), is
how to coordinate the timing of the execution of messages for each
island on a given machine. The presence of the interactor on my system
ensures that I have both islands running. By (my) definition, the "UI"
island is always subserviant to the "main" island, in that the main
island clock provides an upper bound on the execution of the UI island
clock, and not the other way around. I *think* this means that --
mathematically at least -- we can have cycles among island/interactor
graph. However:
1) I'm not sure. I can't quite wrap my head around it.
2) I have no idea yet how to enforce these bounds on execution using
real procedural code.

--
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:[hidden email]
jabber:[hidden email]
voice:+1-608-262-3724