I think this should be clarified (it's a question I've also had for some
time now).
Right now Switch is totally browser dependent - this could cause trouble
Switch {
and clicking on the door would cause it to open or close.
The only trouble would b> if you had a WWWAnchor inside a Switch -
Or, we could do something like WebSpace and say that every Switch
Separator {
Would cause the browser to create the menu heirarchy:
Switch -> Cameras -> Entry
Door -> OpenDoor
(Would also have to require Switches to b> DEFed with names to appear in the
Tim.
down the road as different browsers implement different ways of handling
Switch. I think WebSpace has a good idea by using Switch to store
viewpoints. Maybe we can also say that clicking on a node under switch
will cause the switch to cycle, giving >
whichChild 0
DEF OpenDoor Separator { etc. }
DEF ClosedDoor Separator { etc. }
}
what would the click do? (WWWInline doesn't have this problem).
OK, Switch within a Switch would have a problem too, so this would
have to b> addri> ed.
must have a pull-down menu of some sort. So the structure:
DEF Cameras Switch {
whichChild 0
DEF Entry PerspectiveCamera { etc. }
DEF Exit PerspectiveCamera { etc. }
}
DEF Door Switch {
whichChild 0
DEF OpenDoor Separator { etc. }
DEF ClosedDoor Separator { etc. }
}
{ etc. etc. etc. }
}
Exit
ClosedDoor
menu). This is clumsy, but it illustrates the point that ther> are many
things which can be don> with a Switch *if* the action is defined in the spec.