5.1.1 Creating Observer Configurations

The input driver maintains a list of observer configurations (DtObserverConfiguration) that describe the observers that should be present when the input driver is running. A list of observer configurations is provided to the input driver when it is created. Additional configurations can be added. If a configuration is added while the input driver is running, then that observer is created immediately. Otherwise, it is created the next time (and each subsequent time) the input driver is started. The following example shows how to add an observer configuration to the input driver.

Create an observer configuration to describe the observer to be created. The observer configuration lets you change many of the default values for the observer, but all you really need to specify is the new observer's name in the constructor:

makVrv::DtObserverConfiguration observerConfig("Example Observer");
Add the configuration to the input driver's observer configuration list:

de.driverManager().inputDriver().addObserverConfiguration( observerConfig );

By adding the observer configuration to the input driver's observer configuration list, you ensure that the observer will be created each time the input driver is started.

The exampleCreateObserver example shows how to create a complete VR-Forces application with an additional observer created as described in this section. With a second observer, you can open the display configuration editor, select a channel, and change the observer associated with that channel.

5.1.2 Input Driver Signals

The input driver uses the DtInputDriverSignaler to notify other objects of the operations that it performs. The following table describes the input driver signals.

DtInputDriverSignaler Signals
Signal	Description
signal_inputDriverCreated	Emitted when an input driver is created. Provides a pointer to the input driver selected.
signal_inputDriverAboutToBe-Destroyed	Emitted when an input driver is about to be destroyed. Provides a pointer to the input driver about to be destroyed.
signal_observerCreated	Emitted when an observer is created. Provides a pointer to the input driver and a pointer to the observer created.
signal_observerAboutToBe-Destroyed	Emitted when an observer is about to be destroyed. Provides a pointer to the input driver and a pointer to the observer about to be destroyed.
signal_currentObserverChanged	Emitted when the current observer changes. Provides a pointer to the input driver and a pointer to the new observer.
signal_rightClickTerrainMenu-Request	Emitted when the user right-clicks on the terrain. Provides the <x,y> mouse coordinates and a pointer to the channel that was moused in.
signal_rightClickSelectionMenuRequest	Emitted when the user right-clicks on an object in the scene. Provides the <x,y> mouse coordinates and a pointer to the channel in which the mouse was clicked.
signal_entityIndicatorsToggled	Emitted when entity indicators are toggled.
signal_viewControlsEnable	Emitted when the Accept View Controls switch is changed. Provides a boolean to indicate whether view control is on or off and a pointer to the affected observer.

5.1.3 The Keyboard and Mouse Listener

Management of keyboard and mouse events for an application is often dependent on which GUI system (if any) is in use. Sometimes other components within an application take responsibility for handling these events. For example, OSG provides a keyboard and mouse event handling system.

The keyboard and mouse event listener provides an interface for handling mouse and keyboard events that is independent of the GUI, the renderer, or other components that may grab events. The base class, DtKeyAndMouseEventListener, is a mechanism for registering and creating the type of listener needed for the system in use. It maintains accessors for the DtDe and the input driver, which provides a pointer to itself when it creates the listener. The listener is expected to process keyboard and mouse events in whatever manner it chooses, convert them to the VR-Forces-specific DtKeyEvent and DtMouseEvent classes, and pass these on to the input driver through its processKeyEvent() and processMouseEvent() methods.

Since VR-Forces uses an OSG-based renderer, it uses the DtOsgKeyAndMouseEventListener, which gets the keyboard and mouse events from an OSG event queue, converts them to DtKeyEvents and DtMouseEvents, and passes them on to the input driver. Each OSG channel has its own event queue. If there are multiple observers, events will affect whichever observer is assigned to the channel in which the events occur.

When a Qt-based GUI is in use (as it is in VR-Forces), Qt grabs the keyboard and mouse events before they get to OSG. VR-Forces uses the DtOsgAdapterWidget to convert these events to OSG keyboard and mouse events, and then puts them on the correct OSG event queue for the channel in which they occurred.

5.1.4 The Observer Controller

The observer controller tracks which observer is the one currently under keyboard and mouse control, and works with the Key Map Manager to execute observer functions on specific keyboard events. It provides mappable functions that wrap the observer functions that we want to be able to invoke from the keyboard. Mappable functions take no arguments and return void. The observer controller registers each of these functions and a corresponding string name with the Key Map Manager. Once registered, key events can be bound to the string names as part of a key map, which in turn causes the registered functions to be executed when those key events occur.

5.1.5 The Key Map Manager

The Key Map Manager maintains a list of all functions that can be bound to a key and the string representation for that function. It also maintains a list of key maps, which provide mappings from key events to those string representations. The string representations are used to find and invoke the desired function. Please see exampleKeyMap for an explanation of how to register a function with the Key Map Manager, and bind it to a key event in a key map.

The Key Map Manager uses the Key Map Manager signaler (DtKeyMapManagerSignaler to emit signals when certain operations are performed. The following table describes the DtKeyMapManagerSignaler signals.

DtKeyMapManagerSignaler Signals
Signal	Description
signal_keyMapCreated	Emitted when a key map is created. Provides a pointer to the Key Map Manager and the name of the key map created.
signal_keyMapAboutToBeDestroyed	Emitted when a key map is about to be destroyed. Provides a pointer to the Key Map Manager and the name of the key map about to be destroyed.
signal_keyMapChanged	Emitted when the current key map in use changes. Provides a pointer to the Key Map Manager and the name of the newly current key map.

5.1.6 Custom Event Processors

The input driver provides a way to see (and optionally, handle) keyboard and mouse events before it processes them. It maintains a queue of event processors, which are derived from the abstract base class DtEventProcessorInterface. You can add event processors to the front or the back of the queue. When a key or mouse event is received, the input driver invokes the appropriate processKeyboardEvent() or processMouseEvent() method for the event processor on the front of the queue. If the event processor wants to handle the event, it can return true; otherwise it returns false and the next processor on the queue is invoked. When the queue of event processors has been exhausted, if none of them has handled the event, the input driver handles the event directly.

The exampleEventProcessor example shows how to create an event processor.

[Home] [Top of Page] [Simulation Drivers >>]