This whole proxy scheme can be confusing. We admit that it makes the learning curve for VR Juggler a little steeper, but once you get it, you will know it all. An alternate title for this section is “Horton Hears a Proxy.” In this case, Horton is VR Juggler (it is rather elephant-like at times), and the complexity of dealing with these ethereal, ubiquitous proxies causes VR Juggler to take a lot of guff. This section presents the vjProxy class, the base class for the input proxies, making it the one that is used the most. It should be noted, however, that the concept is spreading to other parts of VR Juggler because it is so useful. While this is only the introduction, we will give you the moral of the story now: proxies are important concepts, and you should not step on them.
The class vjProxy is the base class for all the proxies in the VR Juggler Input Manager. A better name would be vjInputProxy, and it may help to think of it with that name. As a programmer of VR Juggler applications, knowledge of such proxies does not have to be terribly in-depth. The fact is, most VR Juggler programmers will probably never need to know more about a specific device proxy's interface than the return type of its getData() method. Most of the apparent complexity in the specific device proxy classes is only important to VR Juggler's internal maintenance of the active proxies.
That said, this section is relatively short. As a programmer, the important thing to know is that a proxy is a pointer to a physical device. Application programmers use the higher level device interface as the mechanism to read data in some form from the device. The device interface encapsulates some type of proxy that in turn points to an input device. That device can be a wand, a keyboard, a light sensor, or a home-brewed device that reads some input and returns it to VR Juggler in a meaningful way. That is a lot of indirection, but it makes the handling of physical devices by VR Juggler incredibly powerful.
To be blunt, application programmers do not use vjProxy. Instead, access to a subclass of vjProxy is given through a device interface acting as a smart pointer. The getData() method of that subclass is used. That method is the window into the soul of an input device. The device interface allows calling getData() for the specific proxy object it encapsulates, and the current state of the device pointed to by the proxy is returned.
Therefore, what must be known is the return type of the specific proxy to which access is granted through the device interface. The naming conventions for the proxies and their interfaces makes it relatively simple to determine which proxy object is being encapsulated by which device interface. For example, a vjDigitalInterface holds a vjDigitalProxy pointer. In that case, refer to the documentation for the vjDigitalProxy class and find the return type of getData() (int in this case). The proxy header files have the information, too. These are located in $VJ_BASE_DIR/Input/InputManager. Just search for the getData() methods therein.
The gory details of vjProxy and its subclasses are not really relevant to this particular section. The subclasses look complicated, and they can be. It is important to note, however, that the complication is part of the interface used internally by VR Juggler rather than the interface used by the application programmer. Because of that and because each device proxy class is different, those details will not be addressed here. It is sufficient to deal with getData() alone in applications. Leave the ugliness up to VR Juggler; it can handle it.