> Date: Wed, 14 Aug 2002 11:31:32 -0300
> From: Paul Gordon <[EMAIL PROTECTED]>
>
> > Class View gives access to its Canvas3Ds. I could add a Constructor for
> > the MouseInputDevice taking an array of Views.
> > Is this what you would suggest. Or do you have something else in mind ?
>
> Hmmm. ConfiguredUniverse requires an argumentless constructor for the
> InputDevice, so I don't think that'll work. I think the cleanest way to
> do it would be to have a method addView (and corresponding removeView) in
> the MouseInputDevice class, and add a caveat in the javadocs saying that
> this is only effective for static displays, otherwise addComponent should
> be used. Question for Mark Hood (ConfiguredUniverse author):
>
> Does
>
> (DeviceProperty mouse addView view0)
>
> pass view0 as a string or a View? If it's a String (as I guess from the
> docs about introspection calls), how can the view object itself be
> retrieved?
Hi Paul,
I've been thinking about this since you first emailed me about the trackd
InputDevice implementation, and I submitted an RFE for Java 3D 1.3.1:
RFE 4725633 ConfiguredUniverse needs to instantiate
AWT InputDevice implementations
The problem with something like (DeviceProperty mouse addView view0) is that
view0 would just be passed as a string by the parser -- there would need to
be a new built-in command to take the view0 string and return a core J3D
View instance, e.g., (DeviceProperty mouse addView (GetView view0)). But
the parser evaluates commands before any core J3D objects are instantiated,
so this wouldn't work as things are now.
To fix this problem we would need to rework the parser to allow delayed
evaluation for built-in commands, rearrange the order of evaluation for
top-level commands so that the View is instantiated before any InputDevices,
and then evaluate the built-in command that would return a View to the
InputDevice.
An alternative is for the universe package to define a new interface,
AWTInputDevice, that would specify a new method addComponents(). Then after
the View was instantiated, ConfiguredUniverse could enumerate all the
InputDevices registered with the View's PhysicalEnvironment, check to see if
they were instances of AWTInputDevice, and then call the addComponents()
method with the array of Canvas3D objects used by the View. The dirty part
here would be that the initialize() method of InputDevice would actually be
called before addComponents(), so initialize() couldn't actually initialize
much -- the implementation would have to wait for the addComponents() call.
This issue arises because the J3D core InputDevice interface doesn't specify
any way to pass configuration information (such as AWT components, ports,
shared memory addresses, etc.) to the implementation -- these were intended
to be handled by the implementation itself through constructors and methods
not specified by the interface definition. We did consider extending
InputDevice with ConfiguredInputDevice, but it seemed at the time that
everything could be handled by a Property mechanism implemented through
reflection. Unfortunately, it turned out that it doesn't work well for
properties such as AWT Components that have dependencies on other configured
objects.
-- Mark Hood
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
