[next] [prev] [prev-tail] [tail] [up]

6.2.6 Graphical User Interface

The GUI of ViennaMOS is the central interaction platform, providing the end user access to the rendering facilities and the modules. It makes use of the previously discussed flexible GUI elements, in particular the module system as well as the multiview facility with its three-dimensional rendering and two-dimensional chart views. All main elements of ViennaMOS’ GUI are based on QDockWidget objects, enabling to decouple the containing widget from the main frontend and move it, for instance, to a secondary monitor (Figure 6.15).

ViennaMOS provides the means to automatically discover valid modules on the local filesystem, to load them, and to provide a list of discovered modules to the end user via the so-called module manager. The module manager is in fact a dialog enabling the end user to select individual modules to be used in the current session. Selected modules are then loaded, meaning that the module’s factory mechanism is used to instantiate a module, and are finally listed in the active module list where they can be selected to show the module-specific GUI (Figure 6.16).

This active module list allows selection-based switching between the individual module GUIs. Only modules the input dependencies of which are resolved, can be interacted with by the end user. As already indicated, each module is asked by the framework to evaluate its readiness state after one module of the active set finished execution, as previously discussed in Section 6.2.5. For instance, two modules are loaded, where the first is used to generate a device representing the simulation domain, the latter actually conducts simulations requiring the presence of a device. Therefore, until the first module stored a suitable simulation domain in the central database, the second module remains inactive. Only if a valid domain has been stored, the second module becomes active and thus enables the end user to interact with it. This mechanism ensures that the end user interacts only with modules which can be actually executed, due to the resolved dependencies.

The output messages generated by the framework and by the modules are collectively presented to the end user via the central Messages window. The implementation is based on extending Qt’s QPlainTextEdit class by additional methods to claim and release C++ streams, based on rerouting the respective buffers.

pict


Figure 6.15: The main elements of the default ViennaMOS GUI; Top left: The list of activated modules is provided, which is being populated by using the module manager dialog. Middle left: The module-specific GUI is shown based on the selected module in the active modules window. Bottom left: An output message window gathers all messages, both from the framework and from the modules. Middle: A multiview environment holds a set of views, where each view can be specialized to either hold a three-dimensional render view or a two-dimensional chart view. All four main elements can be undocked from the main window, enabling, for instance, to move the respective windows to a secondary monitor.

pict


Figure 6.16: Triggering the module manager dialog (Step 1) allows to select modules used for the simulation (Step 2). When a module is selected - in this case the so-called Device Generator - it can be activated, which instantiates the module in the background and adds it to the list of active modules (Step 3). An active module can be selected, loading the module-specific GUI into the main frontend (Step 4).

[next] [prev] [prev-tail] [front] [up]