User Interface

The NeatTools user interface displays menus when the mouse is clicked, or when the mouse is over an area where a menu selection is possible. Menu selections are made by moving the mouse cursor through the menu option to the right. Mouse clicks are used only to indicate locations of modules.

NeatTools is a component of WebFlow. The NeatTools interface will be consistent with the WebFlow interface, and a portion of the code implementing this interface will be common to both WebFlow and NeatTools. In this initial prototype, the generic portions of the NeatTools interface are referred to as WebFlow classes. These classes are subject to change as WebFlow evolves.

Program construction in the NeatTools environment consists of creating modules, arranging them in the workspace, and directing the data flow. There are two frames in this environment:

  1. Run Frame: used to start, stop, load, and save NeatTools programs.
  2. Workspace Frame: the free form area for arranging and connecting the modules of a NeatTools program.

    3. Program Construction Tasks

    1. Creating a Module Instance
      Modules are created directly in the workspace by clicking the mouse at the desired location of a module. Menus then appear which allow a module to be selected by moving the mouse through the selections to the right. Mouse movement out of the menu area to the left, top, or bottom result in the menu disappearing. Also, a mouse click within the menu area causes the menu to disappear.
    2. Moving a Module
      A module is moved by dragging the module with the mouse.
    3. Directing Data Flow
      Data flow is directed by connecting the output of one module to the input of another. An output is selected by moving the cursor into the right portion of a module. A menu of all outputs is displayed, and one can be selected by moving out of the menu to the right. Any other movement out of the menu area results in the menu disappearing. Also, a mouse click within the menu causes the menu to disappear.
      When an output is selected, all modules with compatible inputs are displayed so that their compatible inputs. There are two rules for compatible input display. If there is an input that has an exact name match to the output, only that input is shown. Otherwise, compatibility is indicated by the type of the output matching the type of the input.
      A compatible input is selected by moving the mouse into the compatible input shown on the display.
    4. Deleting a Module Modules are deleted by dragging them into the picture in the lower right corner.
    5. Deleting and Input/Output Association
      To delete an association between an output and input, select the output and re-connect it to the input.
    6. Undo/Redo
      Not implemented in this prototype.
    In addition to these visual changes, the status line changes to provide a more detailed description of the specific output stream selected. If the module has more than one output stream, repeated selections cycle to the next output stream.

    Transfer of Module Properties

    There are two types of property transfers between modules. If two modules are connected, and both have a set of identically named fixed input streams, but only one module defines values for those streams, that modules values are transferred to the other module. This is to handle cases where an input device uses a specific hardware port configuration. The generic hardware port module then receives the known values for the configuration when connected to the input device module.
    The second type of property transfer occurs when the direction of the data flow is not obvious to the user. For example, when a TNG1 device is connected to a serial port, the user may view this at the physical level, and connect a TNG1 module output to a serial port module input. Or the user may view this at a logical level, where the serial port is passing its data to a TNG1 format decoder module, and connect the serial port module output to a TNG1 module input.
    In a case like this, where module A is connected to module B, by an exact name match field, all module B inputs are transferred to module A. All module A outputs are transferred to module B. The result is that the two connected together (either one first) form the same composite module.

    Module Visualization

    Modules consist of three sections: inputs, module body, and outputs. Each of these sections is displayed differently depending on the state of the module. The properties of each section for each module state is kept in a table used when the module is displayed. The module properties controlled by this table are:
    1. Visibility -- in some states parts of a module are invisible.
    2. Solid -- the module shape is either solid, or just an outline.
    3. Shape color -- the color to use when the shape is drawn.
    4. Text color -- the color to use when displaying the text.
    5. Font -- the font to use when displaying the text.

      6. The state machine for a module includes the following states: NotSelected, InputShown, InputSelected, OutputShown, OutputSelected. Each state has a structure describing the visual properties of the input, body, and output portion of the module.

      Module behavior as well as visualization is implemented within these state classes (see State Pattern of Design Patterns book).