moodss (Modular Object Oriented Dynamic SpreadSheet)
Author: Jean-Luc Fontaine
Description: user and reference manual for using moodss and writing modules

# moodss

## (Modular Object Oriented Dynamic SpreadSheet)

### Contents:

- 1. About this document
- 2. Introduction
- 3. Required software
- 4. Architecture
- 5. Core
  - 5.1. User interface
    - 5.1.1. Menus
      - 5.1.1.1. File
        - 5.1.1.1.1. Save
        - 5.1.1.1.2. Save As
        - 5.1.1.1.3. Modules
          - 5.1.1.1.3.1. Loaded
          - 5.1.1.1.3.2. Load
          - 5.1.1.1.3.3. Unload
        - 5.1.1.1.4. Print
        - 5.1.1.1.5. Exit
      - 5.1.1.2. Edit
        - 5.1.1.2.1. Thresholds
          - 5.1.1.2.1.1. Types
          - 5.1.1.2.1.2. Color
          - 5.1.1.2.1.3. Script
        - 5.1.1.2.2. Configuration
        - 5.1.1.2.3. New
        - 5.1.1.2.4. Preferences
          - 5.1.1.2.4.1. Printing
      - 5.1.1.3. View
        - 5.1.1.3.1. Refresh
        - 5.1.1.3.2. Poll Time
      - 5.1.1.4. Help
        - 5.1.1.4.1. Global
        - 5.1.1.4.2. Modules
        - 5.1.1.4.3. Copyright
        - 5.1.1.4.4. Source Versions
        - 5.1.1.4.5. About
    - 5.1.2. Drag and drop
      - 5.1.2.1. Drop sites
      - 5.1.2.2. Drag sites
  - 5.2. Command line
    - 5.2.1. Main arguments
    - 5.2.2. Module arguments
  - 5.3. Configuration
    - 5.3.1. Canvas
      - 5.3.1.1. Size
      - 5.3.1.2. Colors
    - 5.3.2. Viewers
      - 5.3.2.1. Colors
      - 5.3.2.2. Graphs
      - 5.3.2.3. Pies
  - 5.4. Preferences
    - 5.4.1. Canvas
      - 5.4.1.1. Printing
    - 5.5.1. Thresholds
      - 5.5.1.1. Email

- 6. Modules
  - 6.1. apache
  - 6.2. apachex
  - 6.3. arp
  - 6.4. cpustats
  - 6.5. diskstats
  - 6.6. kernmods
  - 6.7. memstats
  - 6.8. minimal
  - 6.9. mounts
  - 6.10. myprocs
  - 6.11. myquery
  - 6.12. mystatus
  - 6.13. myvars
  - 6.14. netdev
  - 6.15. pci
  - 6.16. ping
  - 6.17. ps
  - 6.18. random
  - 6.19. route
  - 6.20. snmp
  - 6.21. snmptrap
  - 6.22. system
  - 6.23. trace
- 7. Module development
  - 7.1. Source
    - 7.1.1. Namespace
    - 7.1.2. Configuration
    - 7.1.3. Initialization
    - 7.1.4. Termination
    - 7.1.5. Variable data
  - 7.2. Installation
  - 7.3 Displaying messages
  - 7.4. Error handling
  - 7.5. Perl
  - 7.6. Python
  - 7.7. Tips and tricks
    - 7.7.1 Single row tables
    - 7.7.2. Void values as numbers
- 8. Future developments
- 9. Miscellaneous information

### 1. About this document

This document contains general information, reference information and examples designed to help the user understand the moodss application and the programmer write modules for it.

### 2. Introduction

Quite often, one needs to monitor changing data, whether it might come from a system, such as the different processes running on a Unix server, or from a network, such as the volume and distribution of traffic that runs through it.

Most often, such data can be organized in a table with rows of information, each column representing a different kind of data. For example, in the case of processes running on a computer system, rows might be sorted according to their unique process identifier, with columns containing values such as CPU usage, memory usage, owner's name, time of creation, ...

The software used to view this type of information comes in different forms and shapes. Unix users might be familiar with the top application which presents rows of process data as lines of text, whereas RMON (Remote MONitoring) SNMP software usually uses multiple windows with graphical displays, curves, pie charts, multiple configuration dialog boxes, even 3D visualization modules to visualize network traffic, connection matrices, ...

In most cases, data comes from one or more tables. A common interface, graphical with menus, drag'n'drop capability, table widgets, textual and graphical data viewers such as multiple line graphs, bar and pie charts, could be used. The user could then sort table rows, select one or more cells, rows, columns, create views such as other tables, charts, ... best suited to the way data should be presented. Once optimized, the data viewers layout and configuration could be saved for later reuse as a dashboard. In effect, what is needed is a spreadsheet tailored to dynamic data processing.

Moodss (Modular Object Oriented Dynamic SpreadSheet) is an attempt at answering these needs. It is composed of a main part (the core) and an unlimited number of modules, loaded as the application is launched or while it is running, each module interfacing to a specific type of data. The core is written in the great Tcl language (at http://www.scriptics.com/) using object oriented techniques thanks to the stooop package (at http://jfontain.free.fr/). The module function is to describe the data that it is also in charge of retrieving and formatting. Modules can be written in plain Tcl or use dynamically linked libraries written in the C language (modules are packages in the Tcl sense, so any language that can interface with Tcl is supported).

Modules are loaded when moodss is started or dynamically at a later time. Several modules can be handled concurrently (starting with moodss version 3.0). This way, you may monitor data coming from any number of heterogeneous sources. Modules are specified in the command line or dynamically loaded, and can be unloaded at any time.

Versions 4.0 and up add a dashboard functionality: the current configuration (modules, viewers, poll time, windows sizes and placement, ...) can be saved in a file at any time, for later reuse (see the -f (--file) command line switch documentation).

Versions 4.3 and up support asynchronous modules (for which no polling is needed as module data may change on its own). Note that any number of asynchronous and regular (synchronous) modules can be simultaneously loaded.

Versions 5.0 and up add a free text viewer, which can be used for comments, and which can also embed live data cells in text form.

Versions 5.3 and up support viewer type mutation through viewer icon drag'n'drop, and viewer quick destruction by a drop into the eraser icon. A new menu for empty viewer creation was also added.

Versions 6.0 and up support command line arguments per module, data table column anchoring in module configuration and automatic module discovery.

Versions 6.1 and up support HTML formatted help data for modules.

Versions 6.6 and up support automatic cross hairs with coordinates in message area for graph data viewers.

Versions 6.7 and up support contextual help (through the main window message area) on all menu items.

Versions 7.0 and up support per user (on UNIX systems) application wide preferences setting.

Versions 7.99 and up support concurrent instances of the same module.

Versions 8.1 and up support configuration settings per dashboard, with a user interface similar to the preferences interface.

Versions 8.6 and up (in the 8 series) add a stacked graph viewer.

Versions 9.0 and up are only compatible with Tcl/Tk versions 8.2 and above.

Versions 9.4 and up add a stacked graph viewer.

Versions 10.0 and up allow printing in postscript to printer or a file.

Versions 10.1 and up allow printing previewing.

Versions 11.0 and up are multilingual with incomplete French language support added.

Versions 11.1 and up allow dynamically loading modules.

Versions 11.3 and up allow dynamically unloading modules.

Versions 11.7 and up allow swapping columns and rows in module data views.

Versions 11.12 and up include a core trace module that allows displaying message from other loaded modules.

Versions 12.0 and up include the ability to set thresholds on data cells.

Versions 12.1 and up include the ability to send email alerts on thresholds.

Versions 12.3 and up include the ability to change source data cells color on thresholds.

Versions 13.0 and up allow modules to be written in the Perl language.

Versions 14.0 and up allow modules to be written in the Python language.

Since module data access is entirely customizable (through C code, Tcl, HTTP, ...) and since several modules can be loaded at once, applications for moodss become limitless. For example, comparing a remote database server CPU activity and traffic load from a network probe on the same graph becomes possible.

As features are added to moodss, different ways of viewing data will be made available while the module structure will stay the same. The goal of moodss is to become a nice feature packed generic way of viewing data. Moodss can be used to monitor any type of data, since the simplest cases can fit in one table with a single row, with the most complicated requiring loading several multiple table modules.

As moodss is written in Tcl and uses well supported extensions (Tktable and BLT), it will run on Tcl/Tk supported platforms: UNIX and Windows (I do not know if Tktable and BLT are available for the MacIntosh). Obviously, some modules may be specific to a platform, but the core is guaranteed to run on them all.

After reading and understanding this document, you should be able to write your own modules in order to monitor the data that you are interested in.

Moodss is free software. You can redistribute it and/or modify it under the terms described in the COPYRIGHT file or use the main window Help Copyright menu for more information.

### 3. Required software

If you are using a Linux Redhat system (6.0 or above), then use the moodss rpm file (available at http://jfontain.free.fr/) for installation. It requires the tcl, tk, blt and tktable rpms also available at the same location (see INSTALL file for more information). You are then all set for using the included Linux modules or develop your own modules.

Unless you want to work on the moodss source code (not the modules), you can skip the rest of this section.

For the current version (14.0), the following packages must be installed before attempting to install moodss (make sure to check the INSTALL file for the latest information):

- Tcl/Tk version 8.3.1 or above (at http://sunscript.sun.com/)
- tkTable version 2.6 or above (at http://www.hobbs.wservice.com/tcl/main.html)*
- the latest BLT library version 2.4u or above (at http://www.tcltk.com/blt/)*

* many thanks to the authors for these great packages
The pie widgets, stooop and scwoop libraries are included in the self contained moodss application file. Therefore, it is not required to install the stooop, scwoop and tkpiechart packages, unless you want to work on the moodss source code itself. However, should you want to get more information on those extensions, you will find the latest versions:

- stooop version 4.1 or above
- switched version 2.2 or above (included in the stooop distribution)
- scwoop version 4.0 or above
- tkpiechart version 6.1 or above

at http://jfontain.free.fr/.

### 4. Architecture

The moodss application is composed of the core software and one or several modules. Modules are implemented as Tcl packages and thus usually comprise a Tcl source file and a pkgIndex.tcl file as required by the Tcl package implementation.

The core loads one or more modules, whose names are passed as command line parameters, come from a save file or are dynamically loaded, and starts displaying module data in one or more tables. The tables are then updated at the frequency defined by the poll time, which the user may change, or asynchronously for the relevant modules. For example, to launch moodss with the random module, just type (on a UNIX machine):

    $ moodss random

All the module code and data are kept in a separate namespace. The module data is stored is a single array including some configuration data used when the module is loaded by the core, and variable data (displayed in the application table and eventual graphical viewers). If a module is synchronous, it must start updating its data when requested by the core. If a module is asynchronous, its data may be updated at any time. The synchronous or asynchronous nature is specified in the configuration data for the module.

The initial data tables represent the first data views, from which any number of cells can be selected. Data viewers can be created by dragging and dropping cells into a graph, bar chart, pie chart, summary table, free text or thresholds iconic site. In turn, these viewers can display more table cells, which when dropped into the viewer, result in the creation of corresponding data graph lines, chart bars, pie slices, table rows or text cells. Cells or rows can be removed from existing viewers, by simply selecting them and dropping them in the eraser iconic site (a pencil eraser).

Any viewer can be mutated (its type changed) by dragging from a viewer icon and dropping into it. For example, create a stacked data bar viewer from several cells, then drag the 3D pie icon into it. Any viewer can also be destroyed in one shot by dropping the eraser icon into it.

Any draggable data can be dropped in any valid drop site at any time. It is thus possible to drag several data cells from any table or any viewer into other ones, the thresholds interface, the eraser, ... even if the data comes from different modules.

All data viewers can be moved and resized at will with the help of a simple internal window manager.

The current configuration (loaded modules, tables and viewers coordinates, sizes, poll time, main window size, ...) can be saved in a file at any time, so that an identical dashboard can be relaunched at will.

### 5. Core

#### 5.1. User interface

Immediately after launch, module(s) is(are) loaded and initialized, with corresponding messages displayed in the message area, as follows:

Soon after, tabular data is displayed in one or more tkTable widgets with the module identifier as title, automatic scroll bars, between the menu bar, the drop sites with graphical viewers, summary table, free text, thresholds and eraser icons and a message area, as one can see below:

The message area is used to display status information, such as when the data is being updated, and help information, as the user moves the mouse pointer over sensitive areas, such as table column headers. Contextual help on all menu items is also activated as traversal occurs, either using the mouse or the keyboard, resulting in a short explicative string appearing in the message area and related to the active (highlighted) menu item. Further help is provided through widget tips (also known as balloons) when appropriate (on data table column headers, for example), and of course the Help menu.

The window title shows the name of the loaded module(s) along with the poll time.

When several modules of the same type are loaded (for example, CPU statistics on a group of servers), the initial data tables feature the module name followed by an instance number (module<N>), or the module identifier generated from the module code (cpustats(host.domain.org) for example). A lone module keeps his unmodified name as table titles.
Any data displayed in a table can be sorted (provided that the related module allows it) at any time by simply clicking on a column title. Clicking on the same column title again sorts the data in opposite order, thus toggling between increasing and decreasing orders.
When sorting, the selected column is used as a reference, meaning that all rows will be rearranged so that the selected column appears sorted, with values either increasing or decreasing.
A little triangular indicator is placed to the right of the reference column title label, pointing up or down depending on whether the sorting order is decreasing or increasing.
Table columns can be interactively resized by holding the first mouse button down on a column border. The mouse cursor is changed to an horizontal double arrow on column borders to show this capability.

Aside from the main tables, graphical and textual viewers can be created for monitoring table cell data over time. Viewers can also be deleted, data views (such as pie slices, curves, ...) can be added or removed from existing viewers, ... These functions are all implemented using the drag and drop functionality.

For all viewers, if a module identifier string is required (provided by the module, several instances of the same module, ...) for proper cell identification, that string will be placed first in the label. For example, data cells originating from the third instance of the random module would be labeled: "random<3>: data cell label".

Graphical viewers available at this time are BLT graph viewers (see images below), side-by-side bars charts, overlapped bars charts, stacked bars charts, 2D pie charts and 3D pie charts*. Graph viewers feature an automatic cross hair which follows the mouse pointer movements inside the plotting area. Corresponding coordinates are updated in real time in the main window message area.

*Note: if you know of any other nice viewers (like 3D graphs) that work with Tcl, please let me know so I can integrate them. Many thanks in advance...

There are 2 textual viewers.

The summary table displays for each row the cell label, the current, average, minimum and maximum values since the row was created. Data cells can be inserted one or several at a time through a simple drop. Rows can be deleted by selecting any cell in the row then dropping any number of them into the eraser drop site. Data cells with missing data (could be no longer available if coming from a vanished process, for example) display the ? character.

The free text viewer is an editable Tk text widget with any number (including zero) of embedded data cell windows. Data cells can be inserted one or several at a time through a simple drop, as with the other viewers. New data cell windows are inserted at the current insertion cursor position. Data cells can be deleted by selecting then dropping any number of them into the eraser drop site. They can also be deleted using the keyboard Delete and Backspace keys, which also work on the regular text, as well as the expected other key bindings. When dropping data cells, each data cell window is preceded by a relevant label text for the cell, which can later be edited at any time.

Here is a screen shot of loaded ps and cpustats modules with several graphical viewers:

All data viewers can be moved and resized thanks to handling areas in the data viewer borders. When moving the mouse pointer over these areas, the mouse cursor changes to indicate the possible action. Corner handles allow resizing in both X and Y axis. Handles in the middle of the sides allow resizing in either the X or Y axis direction. All other areas can be used for moving the data viewer as shown by the quadruple arrow cursor. Clicking on any part of the border changes the stacking order: the viewer being clicked on either goes below (eventually becomes hidden) the other viewers, or becomes fully visible (on top, eventually hiding other viewers). When moving or resizing, the message area displays the current coordinates or size in real time as the mouse is being moved. Further description of this small window manager functionality is useless, as it behaves like a basic window manager (let me know if it does not).

Here is another shot featuring a free text viewer with loaded cpustats and memstats modules:

Dropping cells into the thresholds drop site in the main window, or selecting the edit menu thresholds entry results in the following dialog box being displayed. While displayed, user interaction with other parts of the user interface remains possible.

More information on thresholds.

##### 5.1.1. Menus

###### 5.1.1.1. File

###### 5.1.1.1.1. Save

The current application configuration (including existing data viewers) can be saved in a file, which achieves a dashboard functionality.

Once moodss has been launched with one or several modules and tables have been moved, resized, viewers created, moved and resized, the current configuration can be saved in a .moo file, and later reused by passing the corresponding file name with the -f (--file) command line switch.

For moodss version 4.0 and above, the following information is saved in the file (which is human readable):

- moodss version
- date and time
- application window size
- poll time
- modules
- tables positions and sizes
- viewers types, positions, sizes and specific data

For moodss version 5.1 and above, the following information is also saved:

- table viewers column widths

For moodss version 5.2 and above, the following information is also saved:

- viewers stacking order (for internal window manager)

For moodss version 8.1 and above, the following information is also saved:

- global configuration (such as canvas color, sizes, ...) (see Edit menu)

When using this menu for the first time, and if a file name was not specified in the command line, the file selector dialog box appears so that the user may choose a file name (with a .moo extension).

Once a file name has been specified (either through the command line or the file selector dialog box), that file name is reused whenever the File Save menu is used.

###### 5.1.1.1.2. Save As

This menu behaves as expected, with the user always having to choose a file name using the file selector dialog box (see Save menu above).
This menu may be used at any time to change the current save file name.

###### 5.1.1.1.3. Modules

###### 5.1.1.1.3.1. Loaded

A module can be picked from a list of the currently loaded modules. Eventually, the module current options appear underneath.

###### 5.1.1.1.3.2. Load

You can dynamically load a module by simply selecting its name from the available list discovered when the selection window opens. When the module is selected, its options appear underneath and any number of them can be filled.

Once the new module, or new instance of an already loaded module, is loaded, the application behaves as if the module had been loaded from the start.

###### 5.1.1.1.3.3. Unload

The module to unload is picked from a list of the currently loaded modules. Once unloaded, the module data tables disappear, but the viewers containing cells pointing to the module data remain, simply showing that the data is now invalid.

Note: if a module is unloaded then loaded again, viewers that monitored the unloaded module data will not resume monitoring the newly loaded module data since internally Tcl traces on variables were removed.

###### 5.1.1.1.4. Print

You can print the canvas area in postscript to a printer or a file, which you may choose using the classical file browser. Please note that only the strictly visible area, without the scrollbars, will be printed.

You can choose the printout orientation (portrait or landscape), palette (color, gray scale or monochrome) and the paper size.

Due to widget and architecture limitations, the printout is pixel based. As a benefit, it is extremely WYSIWYG :-).
Also, because of design limitations, printing is disabled on Windows platforms.

The printout is sized according to the following rules:

- empty space, around tables or data viewers, is not included (the area is cropped)
- a margin of 0.5 inch (12.7 millimeters) is used both horizontally and vertically on all sides
- size reduction occurs equally horizontally and vertically (aspect ratio is preserved) only when necessary so that all tables and data viewers are visible on the printout

When the print menu entry is selected, a dialog box appears, as can be seen in the screen shot below (which also shows the preview window):

You can choose to send the postscript data to a printer or to the screen for previewing.

Depending on the print configuration (see Preferences), either a print command line entry or a printer selection list appears below the informational message. Hitting the OK button sends the data to the selected printer or through the specified command line.

The preview functionality uses gs (also known as ghostscript), which must be installed (note: version 5.50 is required, as 5.10 is buggy). If gs cannot be found or executed, the preview button is grayed. If the gs version is below 5.20, the button is also grayed and a window tip explaining the cause is displayed when the mouse pointer is located above the button.

When the gs utility is available and of the correct version, the preview button can be depressed, in which case the print dialog temporarily disappears (so that the application main window is not obscured), and reappears along with the preview window, once the printout view has been calculated.
The preview window also features a zoom menu for resizing. If the user so desires, one or more printing parameters, such as page size, orientation, ... can be changed while the preview window remains visible. Hitting the preview button then results in both the print dialog box and the preview window to temporarily disappear while the new page look is calculated. After a short while, they both reappear with the preview updated accordingly, and having kept the same zoom ratio.

Also note that due to the implementation of the graphical layer on UNIX systems, any window or object obscuring the canvas area will also be printed, but this is unlikely, as the moodss application window will be in front when the print menu item is selected.

###### 5.1.1.1.5. Exit

Use this menu to gracefully quit the moodss application. You may also use the window manager to close the application.

If there are unsaved changes (configuration, viewers created, tables or viewers moved, stacked, ...), the user is given the opportunity to save them to file (see File Save menu). The file selector dialog box is used if no save file name is currently known by the application.

###### 5.1.1.2. Edit

###### 5.1.1.2.1. Thresholds

Opens the thresholds dialog box.

A list of threshold entries is displayed in a table with the following columns:

- active: clicking on the check button toggles the state of the entry between active and not. When active, the shell script is invoked when and if the threshold condition occurs. For example, if the threshold type is up and the data cell value goes above the threshold value.
- type: clicking on the entry icon toggles the threshold type between differ, down, equal, unknown and up. (see threshold types below).
- color: selects the color to be displayed in source cell(s) when the threshold condition occurs. Clicking on the menu button drops a menu window with predefined color buttons, the last of which, with 3 dots as a label, if selected, opens a custom color selection dialog box. The menu button color reflects the currently selected threshold color. The ? entry stands for the transparent color, that is there will be no color change in the monitored cell displays when the threshold condition occurs.
- source: initially, when the threshold entry is created, the data cell label, as it would be displayed in a data viewer. This column is editable so that the user may input a more meaningful description.
- value: the threshold value, used as reference when comparing with the data cell current value. When changed, the threshold condition is checked as the user confirms when closing the dialog window.
- emails: a comma separated list of email addresses. When a threshold event occurs, an alert message will be sent to each recipient (also see preferences).
  Note: this column title is grayed if the SMTP package, which is required to send emails, was not found (see the INSTALL file for more information).
- script: a UNIX shell script invoked when the threshold is crossed. See script section below for passing arguments to the script. Any errors are displayed on the standard error channel and eventually visible in the trace module data table if displayed (incompatible with the Windows platform).

Help is provided through widget tips on the table title cells, and a help button, which directly opens the main help window at the relevant section.

Creating threshold entries is done through the drag'n'drop mechanism by dropping data cells into the thresholds drop icon. Any number of thresholds can be set on the same data cell.

Selecting a row is done by clicking on any cell of the row. The row is then highlighted. Below the thresholds table, the following buttons, that act on the selected row, can be found:

- Test: simulates a threshold condition. The shell script is then invoked as if the real threshold was crossed, the cell value being artificially generated. Displayed source cell(s) in the main application window remain unaffected colorwise.
- Delete: removes the selected threshold entry (row). All related displayed source cells are reset to their original (transparent) color.

Note: there are still a lot of features to implement: please see the TODO file.

###### 5.1.1.2.1.1. Types

The following threshold types are supported:

- : threshold and cell value must differ.
- : cell value must be less than threshold.
- : threshold and cell value must be equal.
- : cell value must be unknown (invalid).
- : cell value must be more than threshold.

Depending on the source data cell type, specific internal comparison techniques are used.

For the ASCII type, the current cell value can be lexicographically less than, equal to, or greater than the threshold value. Empty threshold values are allowed. The strings are compared in a case-insensitive manner.

The dictionary type is handled as the ASCII type, with case ignored except as a tie-breaker and if there are embedded numbers, the numbers compare as integers, not characters.

For the clock type, the cell and threshold values are first converted to seconds, then compared.

When the threshold type is , the condition occurs when the data cell value cannot be determined, and only in such a case. It is the only type of threshold that can be triggered by the void nature of a data cell, as for the other threshold types, no action is ever taken in such an event.

###### 5.1.1.2.1.2. Color

If a non-transparent color has been selected (see previous section), whenever the threshold condition occurs, all displays of the monitored data cell change color (in data tables or in viewers), and return to their normal color when the threshold condition no longer exists.

When several thresholds are placed on the same data cell with different colors, and they all trigger, the behavior is undefined at this time (but the most recent threshold is likely to prevail).

###### 5.1.1.2.1.3. Script

Whenever a threshold is triggered (the manner of which depends on the type), the corresponding script is passed to the UNIX shell interpreter (the sh UNIX command), after variable substitution.

Substitution occurs prior to script invocation if the script contains any % characters. Each % and the character following it is replaced with information from the threshold occurrence. The replacement depends on the character following the %, as defined in the following list:

- %%: replaced by a single %.
- %c: replaced by the original data cell string (as would be displayed in any data viewer).
- %s: replaced by the contents of the source column from the thresholds table.
- %t: the threshold value
- %T: the threshold type (either up or down)
- %v: the data cell value responsible for triggering the threshold

###### 5.1.1.2.2. Configuration

When selected, this menu launches the configuration dialog box, as described in Configuration.

###### 5.1.1.2.3. New

Allows the creation of empty viewers of any type (graph chart, stacked graph chart, overlap bar chart, side bar chart, stacked bar chart, 2D pie chart, 3D pie chart, summary table or free text).
This menu is only visible when not running in read-only mode (see Command line).

###### 5.1.1.2.4. Preferences

The Preferences dialog box is very similar to the configuration dialog box, except that it also includes canvas printing default settings.
It allows the user to change application wide settings, saved in a global file (known as an rc file to UNIX people), used for initialization when the application is started. Since this file is stored in the user home directory (on a UNIX system), it provides a way for a user to customize the look, behavior, ... of the moodss application in a permanent manner.

Preferences choices, when applied (either by choosing Apply or OK) also affect configuration settings.

Further and up-to-date help is always provided in the different Preferences dialog box screens.

###### 5.1.1.2.4.1. Printing

Choose the default behavior when printing: either to a printer or a file, and set various parameters. The print command typically reads the Postscript data from its standard input and redirects it to the specified printer (for example, on UNIX, 'lpr -Pacme' will print the canvas area on the "acme" printer.
By default, the command is set to 'lpr -P%P', which by including the %P generic printer name tag allows the user to pick the printer from a list (drawn from the /etc/printcap database) at printing time.

When printing to a file, you may choose its default location and name with the file browser. Note that it can be overridden in the print dialog box launched when actually printing.

###### 5.1.1.3. View

###### 5.1.1.3.1. Refresh

Immediately refreshes display of all loaded asynchronous modules.

###### 5.1.1.3.2. Poll Time

The View menu (may not exist, see below) contains the Poll Time entry which when selected launches the corresponding dialog box, as shown below:

The user can select a new poll time among the module choices from a spin entry widget, or directly type in a new value, as long as it is not smaller than the module minimum poll time, in which case a warning message is displayed.

When several modules are used, the minimum poll time is the greater of the minimum poll times of all modules. The default poll time (used when moodss is started) is the greater of the default poll times of all modules. The available choices in the poll time dialog box is the combination of all modules poll times.

The Poll time menu entry is available only when needed, which is not the case if all the loaded modules are asynchronous. If this case, the Options menu itself is not displayed.
This menu is only visible when not running in read-only mode (see Command line).

###### 5.1.1.4. Help

###### 5.1.1.4.1. Global

This menu launches an embedded HTML viewer with this very document minus the sections related to module development.

###### 5.1.1.4.2. Modules

This menu features one sub menu per module, which when selected displays the module's help data.

###### 5.1.1.4.3. Copyright

Displays the GPL (Gnu General Public License) document, a truly great idea from the Free Software Foundation.

###### 5.1.1.4.4. Source Versions

Displays all the source code file names with their versions, in a table with sortable columns (as in table viewers).

###### 5.1.1.4.5. About

Displays version, author, extension authors, license and basic information about moodss.

##### 5.1.2 Drag and drop

Drag and drop in moodss tries to behave as the now familiar Windows functionality (no, it doesn't mean I am a Bill Gates fan, as they probably stole the idea from somebody else anyway :^). For example, to create a graphical plot, one must first select one or more data cells in a data table, hold down the first mouse button (the left one for a right handed user) while dragging over to the left-most icon below the menu bar (when dragging an object, as the mouse pointer passes over possible drop sites, they are highlighted with a thin black border for user feedback). Releasing the mouse button at this time results in the creation of a BLT graph viewer.

Only valid drop sites for the data being dragged are highlighted when the mouse cursor passes over them, thus guaranteeing error free operations (if there are no bugs, that is :).

In summary, data cells can be dragged from any table or any viewer into any viewer drop site icon, any viewer or the eraser.

###### 5.1.2.1. Drop sites

All icons right below the menu bar are valid drop sites for data cells (several may be dropped at the same time). From left to right:

- graph viewer with one or more data curves created at once
- stacked graph viewer with one or more data filled curves created at once
- side by side bar chart with one or more data bars created at once
- stacked bar chart with one or more data bars created at once
- 2D pie chart with one or more data slices created at once
- 3D pie chart with one or more data slices created at once
- summary table with one or more data rows created at once
- free text with one or more labeled data cell windows created at once
- thresholds with one or more entries created at once
- object eraser with one or more data viewer elements deleted at once

For example, a graph viewer with 1 curve is created by dropping 1 data cell into the graph viewer icon.

Once a viewer exists, it also acts as a drop site for data cells, which may be dragged from any table or other viewers. Dropping one or more cells directly in the viewer results in corresponding lines, bars, slices or rows being created and automatically updated. Each new graphical element is assigned a new and different color.

You may delete one or more viewer elements (graph lines, bar chart bars, pie charts slices, summary table rows or free text cell window) from a viewer by selecting them (using the first mouse button) through their labels. Several elements can be selected by depressing the control key as the first mouse button is pressed. The selection can also be extended by depressing the shift key along with the first mouse button. The pie slices can also be directly selected by clicking on the slices themselves.
Then dragging from the viewer to the eraser drop site (the pencil eraser) on the upper right side of the main window and releasing the first mouse button result in the corresponding viewer elements to be destroyed. When there are no remaining elements, the viewer itself (graph, bar chart, pie or summary table) can be destroyed by dropping it into the eraser site. The free text viewer can only be deleted this way when completely emptied of any text and data cell window.

Any viewer can be deleted in one shot by dropping from the eraser icon into it.

Any viewer also acts as a drop site for viewer type data, which allows viewer mutation by just dropping from the new viewer type icon into the existing viewer. It is much quicker than destroying the existing viewer and create a new one of the new type, while remembering which data cells were monitored by the viewer of the old type.
When mutating, if some cells in the current viewer no longer exist (they may belong to a disappeared summary table), they are not made a part of the new viewer, and a warning message is flashed to the user in the message area.

###### 5.1.2.2. Drag sites

A table is obviously a drag site. One or more cells can be dragged at once after selection, using the traditional single/shift/control mouse click technique.

Any viewer is also a drag site. It requires selecting one or more viewer elements before initiating the drag operation from any selected element in the viewer. If there are no selected elements, dragging is impossible: the mouse cursor is not changed into the drag circular cursor.

If a viewer contains no elements, then the viewer itself can be dragged and dropped into the eraser.

All viewer icons (below the menu bar) are drag sites for viewer type data, which allows quick viewer mutation (see mechanism description in Drop sites).

The eraser icon is also a drag site of the killing action type, which allows viewer destruction in one shot.

#### 5.2. Command line

##### 5.2.1. Main arguments

Launching moodss is very simple:

        $ moodss

or

        $ wish moodss

if the Tcl/Tk wish interpreter is not found in your PATH. You can then dynamically load modules from the File menu.

You can also just pass one or more data module names as parameters, as in:

        $ wish moodss random

or, for 2 modules at once:

        $ wish moodss ps cpustats

You can specify the same module more than once and with different arguments in the command line:

        $ wish moodss ps -r host.domain ps -r otherhost.domain

When several modules of the same type are passed as argument, the initial data tables feature the module name followed by a number as title. For example "ps<2>". If the module provides an identifier string, that text will be used instead, as in "ps(host.domain)". Data cell labels include the module identifier or numbered module name as well, for proper identification.

You may eventually specify a poll time in seconds using:

        $ wish moodss -p 25 random

Note that when all the specified modules are asynchronous, the poll time option specifies the preferred interval for graph viewers.

Once saved through the File Save menus (for example in save.moo), the configuration can be retrieved using:

        $ wish moodss -f save.moo

which would result in the same modules being loaded, the same viewers displayed at the same positions and sizes, the same poll time being used, as well at the same application window size. New modules data displays can be added at any latter time to existing dashboards by specifying modules on the command line after the -f (--file) switch / value pair.

Command line options include:

- --debug: set verbose reporting when module errors occur
- -f (or --file): specify a configuration file name
- -h (or --help): display some help text and exit
- -geometry: set the initial geometry of the main window (a la X window)
- -p (or --poll-time): specify a poll time in seconds
- -r (or --read-only): disable viewer creation, editing, ...
- -S (or --static): disable internal window manager sizing and moving
- --show-modules: discover valid moodss modules, show their directory location(s) and exit
- --version: output version information and exit

Moodss command line options must appear before any module name appears on the command line, so as not to interfere with the module options.

In debug mode, when errors occur within the module namespace body or initialize procedure, the error message (either in text output when loading the module from the command line, or in a message window when dynamically loading the module) is followed by a Tcl stack trace of what was in progress when the error occurred (see the Tcl error manual page for further information).

##### 5.2.2. Module arguments

Module themselves can take options (if programmed to do so, see module initialization), through command line arguments placed right after the module name and before the next module name, if any.

For example, the following command:

        $ moodss -p 15 random --asynchronous arp --remote jdoe@foo.bar --numeric route --numeric

causes the random module to update asynchronously, the arp module to collect data from the foo.bar host under the jdoe login name and not attempt to lookup symbolic names for hosts, with the last module route doing the same.

Note the setting the application poll time to 15 seconds does not interfere with the module options.

The moodss core checks the validity of module options according to the information provided by the module programmer. Any invalid option / value combination for the module is detected, reported on the standard error channel before the application exits.

Finally, it is always possible to determine the valid options for a module, using the following command:

        $ moodss module --help

#### 5.3. Configuration

All configuration parameters can be set using the following interface:

The Configuration dialog box allows the user to change global settings for the current view (also called a dashboard). This data is stored along when saving the configuration to a file (see Save menu).

Changing configuration choices do not affect the Preferences choices, which are used as initial values the first time the user modifies the configuration. Configuration settings have a higher priority than preferences settings, but are lost when not filed.

Configuration entry is done through pages organized in a browsable hierarchical tree, always visible on the left side of the configuration dialog box (see picture above).

After selection of the category from the tree on the left, a related dialog interface appears, which may or may not allow immediately applying new data values.
Clicking on the OK button results in the current configuration data to be saved in memory. It will be stored in the save file when requested (see File Save and Save As menus).

Specific help can always be accessed by clicking on the bottom Help button when in a configuration page.

##### 5.3.1. Canvas

The canvas is the data viewers background area, and its configuration (size, color, ...) can be changed as described below.

##### 5.3.1.1. Size

The canvas width and height can be changed so that all the different tables and viewers that the dashboard comprises can fit nicely within the viewing space.

The default is the current screen size.

The size is immediately updated when clicking on the Apply button.

##### 5.3.1.2. Colors

The canvas color can be changed for your viewing pleasure...

The color is immediately updated when clicking on the Apply button.

##### 5.3.2. Viewers

The viewers are used for viewing table data, and their configuration (colors, ...) can be changed as described below.

##### 5.3.2.1. Colors

These are the colors of viewer elements. For each viewer that needs different colors for displaying data cell elements (such as graphs, pie charts, ...), each new element uses the next color in the sequence (wraps around if necessary).

Advice: adjacent colors should be very different, colors should be visible on a black background.

Note: in a future version, creating, deleting and moving colors in the sequence will be possible.

##### 5.3.2.2. Graphs

The number of samples (on the X axis) can be changed for data graph viewers. The specified value will not be used for existing graphs but for newly created ones.

##### 5.3.2.3. Pies

The labeler type for data pie viewers can be changed as follows:

- current value labels can be displayed next to corresponding slices (peripheral style)
- or next to the corresponding text labels (box style)

The selected type will not be used for existing pies but for newly created ones.

#### 5.4. Preferences

The preferences dialog box is used for application-wide settings.

On UNIX systems, preferences data is saved in each user home directory under the rc file named .moodssrc.

On Windows, data is saved in C:\.moodssrc (by default, but depends on the HOME variable).

After selection of the category from the tree on the left, a related dialog interface appears.
Help is provided for each interface, which may or may not allow immediately applying new data values.
Clicking on the OK button results in the preferences data to be written to the rc file.

##### 5.4.1. Canvas

##### 5.4.1.1. Printing

The canvas area can be printed in the Postscript data format.

The default behavior when printing can be set to either a printer or a file, but can always be overridden in the print dialog box launched when actually printing.
Various parameters, such as orientation, palette and paper size can be set.

The print command typically reads the Postscript data from its standard input and redirects it to the specified printer (for example, on UNIX, `lpr -Pacme` will print the canvas area on the acme printer, and `lpr -P%P` will allow printer selection from a listbox at printing time.

When printing to a file, you may choose its default with the file browser.

##### 5.5.1. Thresholds

##### 5.5.1.1. Email

When a threshold event occurs, an email alert message can be sent (see thresholds).

Proper identification is required so that the originator of the message (the From address field in an email message) is known. Use your own email address or another email address (such as moodss@your.domain.com) that you control.
In any case, the From address field must contain a valid email address.
Your user name is used by default.

Sending email requires an Outgoing mail SMTP server. Input the one that you use for sending your emails (check your browser or email software current configuration), or any other valid SMTP address (consult your system administrator in case of doubt).
The local host (127.0.0.1 address) is used by default.

### 6. Modules

#### 6.1. apache

Documentation.

#### 6.2. apachex

Documentation.

#### 6.3. arp

Documentation.

#### 6.4. cpustats

Documentation.

#### 6.5. diskstats

Documentation.

#### 6.6. kernmods

Documentation.

#### 6.7. memstats

Documentation.

#### 6.8. minimal

The minimal module is as bare bone as possible and can be used as a starting point for developing new modules.

#### 6.9. mounts

Documentation.

#### 6.10. myprocs

A module for the MySQL database server (documentation).

#### 6.11. myquery

A module for the MySQL database server (documentation).

#### 6.12. mystatus

A module for the MySQL database server (documentation).

#### 6.13. myvars

A module for the MySQL database server (documentation).

#### 6.14. netdev

Documentation.

#### 6.15. pci

Documentation.

#### 6.16. ping

Documentation.

#### 6.17. ps

Documentation.

#### 6.18. random

The random module code contains a lot of comments, providing some extra documentation about module coding.
Documentation.

#### 6.19. route

Documentation.

#### 6.20. snmp

Documentation.

#### 6.21. snmptrap

Documentation.

#### 6.22. system

Documentation.

#### 6.23. trace

Documentation.

### 7. Module development

All examples are drawn from the random Tcl and Random Perl sample modules.

#### 7.1. source

A module is a package, it must have a name and a version.

- Tcl: at the beginning of the random.tcl file:

      package provide random 1.1

  This line simply states that this is the 1.1 version of the random package. Please note that the package name must also be used as the module namespace name (see below).
- Perl:

      package Random;
      ...
      BEGIN {
      ...
          our $VERSION = 1.1;
      }

  Note that traditionally, Perl package names must be capitalized, and the package name must match the corresponding file name (not counting the .pm extension). The VERSION variable must be defined.

Module names can be any combination of the following characters:

- `space character`
- `alphanumeric (letters and digits)`
- `_@%&*()=+:.-`

##### 7.1.1. namespace

All module procedures and data are kept in a specific namespace bearing the module name.

- Tcl: from the random.tcl file:

      namespace eval random {
          array set data {
              ...
          }
          proc update {} {
              ...
          }
      }

- Perl: implicit as a module has its own namespace:

      our %data;
      our @data;
      ...
      sub update() {
      ...

The update procedure is not needed when the module is asynchronous.

Note: at this time, it is required for Perl modules, as they cannot be asynchronous.

##### 7.1.2. configuration

The module configuration defines the data table column headers, help information, ... This data never changes during the lifetime of the application.

- Tcl: all the module configuration data is stored as array members of the array named data within the module namespace. For example:

      namespace eval random {
          array set data {
              updates 0
              0,label name 0,type ascii 0,message {user name}
              1,label cpu 1,type real 1,message {cpu usage in percent}
              2,label disk 2,type integer 2,message {disk usage in megabytes}
              3,label command 3,type dictionary 3,message {most time consuming command} 3,anchor left
              pollTimes {10 5 20 30 60 120 300}
              sort {1 decreasing}
              indexColumns {0 3}
              helpText {This is a simple demonstration module ...}
          }
          ...
      }

- Perl: all the module configuration data is stored in a hash named data.
  Columns data is kept in an array of hashes. The array index is the column number starting from 0.
  The poll times, sort data and index columns are kept in arrays.
  For example:

      our %data;
      $data{updates} = 0;
      $data{columns}[0] = {
          label => 'name', type => 'ascii', message => 'user name'
      };
      $data{columns}[1] = {
          label => 'cpu', type => 'real', message => 'cpu usage in percent'
      };
      $data{columns}[2] = {
          label => 'disk', type => 'integer', message => 'disk usage in megabytes'
      };
      $data{columns}[3] = {
          label => 'command', type => 'dictionary', message => 'command name',
          anchor => 'left'
      };
      $data{pollTimes} = [10, 5, 20, 30, 60, 120, 300];
      $data{sort} = {1 => 'decreasing'};
      $data{indexColumns} = [0, 3];
      $data{helpText} = 'This is a simple demonstration module ...';
      ...

The updates member is a counter used to keep track of the number of times that the module data was updated, and is also used by the core to detect when module data display should be updated (see variable data for more information).

The label members ($data(n,label) in Tcl, $data{columns}[n]{label} in Perl, with n the column number), define the text to be displayed as column titles. There must be as many label members as they are columns. The titles must contain no ? character.

The type members ($data(n,type) in Tcl, $data{columns}[n]{type} in Perl) define the type of the corresponding column data. Valid types are simply those that the Tcl lsort command can handle: ascii, dictionary, integer and real, plus the clock type, which accepts any format that the Tcl clock format command can handle (see the trace module for an example). There must be as many type members as they are columns.

The message members ($data(n,message) in Tcl, $data{columns}[n]{message} in Perl) define the text of the help message to be displayed in a floating yellow window (widget tip, balloon, also see User Interface) as the user moves the mouse pointer over column titles. It can be composed of only a few words or multiple formatted lines. There must be as many message members as they are columns.

The anchor member ($data(n,anchor) in Tcl, $data{columns}[n]{anchor} in Perl) is optional. Column data is either centered by default, tucked to the left or right side of the column. Valid values are center, left or right.

Note that column numbers start at 0. There must be no hole in the column numbers sequence.

The pollTimes member is a list of valid poll times (in seconds) for the module. The list is not ordered, as its first element represents the default poll time value to be used when the moodss application starts. This value may be overridden by a command line argument. The smallest value in the list is used by the core as the lowest possible poll time and checked against when the user enters a new value through the poll time dialog box. The list must not be empty.
Note that the list is also used by moodss as a set of possible choices in the dialog box used to set the new poll time. The user may still directly input any value as long as it is greater than or equal to the minimum value.

If the module is asynchronous (data can be updated at any time and not in response to update procedure invocations (no polling required)), the pollTimes member must be a single negative integer value representing the preferred time interval for viewers that require one (only graphs at this point). For example, if you wish graph viewers to have a display interval of 10 seconds, use:

- Tcl:

      namespace eval random {
          array set data {
              ...
              pollTimes -10
              ...
          }
          ...
      }

- Perl: asynchronous modules not yet available.

In this case, the graph viewers time range (knowing that they feature 100 time points) would be 1000 seconds. I guess that the value that you should specify as the pollTimes member should be the expected average update interval for your asynchronous data. Note that the graphical viewers x axis always display properly labeled absolute time ticks in any case.

When several asynchronous modules are loaded with no synchronous modules, the interval used for all relevant viewers is the average (in absolute value) of all module intervals. For example, if you load 2 asynchronous modules, one with a pollTimes member of -10 and the other of -20, then a 15 seconds interval value is retained. Note that the interval can be forced through the --poll-time command line argument.

If at least one synchronous module is loaded concurrently with any number of asynchronous modules, the actual application poll time (the one that can be set with the then available poll time dialog box) is used.

The indices member is an optional list that specifies the table columns that should be displayed. If not specified, all the table columns are visible.
Note: visibleColumns, the previous keyword for that function, is obsolete (but still supported) after moodss version 11.7.

The sort entry is optional. It defines the index of the column which should be initially used as a reference for sorting the data table rows, and in which order (increasing or decreasing) the rows should be sorted. The column index for sorting works like the -index Tcl lsort command option, that is rows are sorted so that that specific column appears sorted in the specified order. The specified column must be visible (see indices member documentation above).

The indexColumns list specifies the columns required to uniquely identify a row in the table. In database talk, it represents the table key. To maintain backward compatibility, it is optional and defaults to 0, the leftmost column. The index columns are used when creating data viewer elements: their label is built by concatenating the key value for the cell row with the cell column title. The key value is the concatenation of the index column values for the cell. When specified, all the columns in the list must be visible (see indices member documentation above).

The helpText member specifies a text of any length, to be displayed when the user requests help information on the current module from within the help menu. The text can be HTML formatted or plain. HTML formatted help requires the <HTML> and <BODY> tags to be present, while tables and frames are not supported (and many other tags: stick to formatted text at the moment). The core will render HTML formatted or plain text in the module help window according to the help text contents.

The views member is optional. If specified, it defines one or more views to be used in place of the default view. One table will be displayed per view. For each view, 1 member must be defined: indices, the sort member being optional (syntax and usage are identical to the default table members). A swap optional member may be used if the table data is to be displayed with columns and rows swapped, which is generally the case when the data table has 1 or 2 rows, or a fixed number of rows (see memstats module for an example). The swap value is a boolean and must be either 0 or 1.

- Tcl: each view is a list of array members, suitable as an argument to an "array set" command:

      namespace eval random {
          array set data {
              ...
              views {
                  {indices {0 1 3 4} sort {1 decreasing} swap 1}
                  {indices {0 2 4} sort {2 decreasing}}
              }
              ...
          }
          ...
      }

- Perl: each view is a hash of arrays:

      $data{views} = [
          {indices => [0, 1, 3, 4], sort => {1 => 'decreasing'}, swap => 1},
          {indices => [0, 2, 4], sort => {2 => 'decreasing'}}
      ];

The switches member is optional. A switch is a single letter or a string prepended with the - or + sign. The boolean value (0 or 1) specifies whether the switch takes an argument. If the switches member exists, an appropriate initialize procedure must be provided by the module (see Initialization). The core will take care of parsing the command line and reject any invalid switch / value combination for the module. The switches value may not be changed in the initialize procedure.

For example, a recent random module configuration is as follows:

- Tcl: switches are a list of switch / boolean pairs:

      array set data {
          updates 0
          0,label name 0,type ascii 0,message {user name}
          1,label cpu 1,type real 1,message {cpu usage in percent}
          2,label disk 2,type integer 2,message {disk usage in megabytes}
          3,label memory 3,type integer 3,message {memory usage in kilobytes}
          4,label command 4,type dictionary 4,message {command name}
          pollTimes {10 5 20 30 60 120 300}
          sort {1 decreasing}
          indexColumns {0 4}
          helpText {...}
          views {
              {indices {0 1 3 4} sort {1 decreasing}}
              {indices {0 2 4} sort {2 decreasing}}
          }
          switches {-a 0 --asynchronous 0}
      }

- Perl: switches are stored in a hash:

      our %data;
      $data{updates} = 0;
      $data{columns}[0] = {label => 'name', type => 'ascii', message => 'user name'};
      $data{columns}[1] = {label => 'cpu', type => 'real', message => 'cpu usage in percent'};
      $data{columns}[2] = {label => 'disk', type => 'integer', message => 'disk usage in megabytes'};
      $data{columns}[3] = {label => 'memory', type => 'integer', message => 'memory usage in kilobytes'};
      $data{columns}[4] = {label => 'command', type => 'dictionary', message => 'command name'};
      $data{pollTimes} = [10, 5, 20, 30, 60, 120, 300];
      $data{sort} = {1 => 'decreasing'};
      $data{indexColumns} = [0, 4];
      $data{helpText} = '...';
      $data{views} = [
          {indices => [0, 1, 3, 4], sort => {1 => 'decreasing'}},
          {indices => [0, 2, 4], sort => {2 => 'decreasing'}}
      ];
      $data{switches} = {'-a' => 0, '--asynchronous' => 0};

In this case, data is presented in 2 tables: one for the CPU and memory usage, the other for disk usage.

The identifier member is optional. It is string that uniquely identifies this module. If set, it is displayed by the core in the initial data tables title area and data cell labels in viewers. This feature can be used for example in modules that gather data from a remote host: in such a case, the identifier could be set to dataType(hostName) (the ps module uses ps(host) string). The allowed character set for the identifier is identical to the allowed set for a module name.
Note that the identifier member is usually set in the module initialize procedure, as it usually depends on the module options.

##### 7.1.3. Initialization

The initialize procedure, if it exists, is invoked by the core before any update occurs (when the update procedure is invoked if the module is synchronous).

In order for a module to accept command line arguments, the initialize procedure must exist (more information below). Otherwise, if the module can take no arguments, it stays optional. In that case, it is rather redundant with inline module code (outside of any module function or procedure). When the module takes no arguments, so does the initialize procedure if it exists.

The initialize procedure is mandatory when the module supports command line arguments, and in such a case takes option values as arguments.

Let us use the following command line as example:

    $ moodss random --asynchronous --other-option value -x 1234

- Tcl: The initialize procedure takes an array name as sole argument. The array contains the switched options values, indexed by switch. The options array will contain:

      options(--asynchronous) =
      options(--other-option) = value
      options(-x)             = 1234

  Note that the --asynchronous member value is empty as that switch takes no argument. For the above example, switches would have been defined as:

      switches {-a 0 --asynchronous 0 --other-option 1 -x 1}

- Perl: The initialize procedure takes a hash as sole argument. The hash contains the switched options values, indexed by switch. The hash will contain:

      $options{--asynchronous} = 1
      $options{--other-option} = value
      $options{-x}             = 1234

  Note that the --asynchronous member value is filled with a boolean even though that switch takes no argument. For the above example, switches would have been defined as:

      $data{switches} =
          {'-a' => 0, '--asynchronous' => 0, '--other-option' => 1, '-x' => 1};

In all cases, data members other than updates and switches can be set or updated in the initialize procedure, and successfully taken into account by the core.

Example for a module that take arguments, where a module identifier is generated according to the -i or --identify command line switches:

- Tcl: the options array is accessed using the upvar command technique (used when passing arguments (such as arrays) by name):

      proc initialize {optionsName} {
          upvar $optionsName options
          variable data
          if {[info exists options(-i)]||[info exists options(--identify)]} {
              # generate a random module identifier:
              set data(identifier) "random [expr {int(rand()*100)}]"
          }
      }

- Perl: the options are passed as a hash with the switch as index, where options that take no arguments have a boolean as value:

      sub initialize(%) {
          my %option = @_;
          if ($option{'-i'} || $option{'--identify'}) {
              # generate a random module identifier:
              my $identifier = int(rand(100));
              $data{identifier} = "random $identifier";
          }
      }

The core waits for the initialize procedure to be completed before initializing the next module. For modules likely to initialize slowly and/or susceptible to initialization failure, it is advised to allow the user interface to be updated in the meantime:

- Tcl: using the vwait command (technique used in all the remote capable modules shipped with moodss):

      proc initialize {optionsName} {
          ...
          set file [open "| /usr/bin/rsh -nl $remote(user) $remote(host) cat /proc/net/arp"]
          fileevent $file readable {set ::arp::remote(busy) 0}
          vwait ::arp::remote(busy)
          ...
      }

  Since the file to be read sits in a remote machine on an eventual slow link, the initialize procedure is blocked until the file becomes readable, but without hanging the user interface, using the Tcl fileevent and vwait commands combination.
- Perl: not possible at this time.

Similar techniques must be used in such cases within the module update procedure, so that the user interface and eventual modules running concurrently are not prevented to update. The remote capable moodss modules contain various coding techniques achieving that functionality, which I am sure you can improve on.

##### 7.1.4. Termination

If a procedure named terminate exists in the module namespace, it is invoked when the module is unloaded dynamically. That procedure must take no arguments. For example:

- Tcl:

      proc terminate {} {
          # do some cleanup
      }

- Perl:

      sub terminate() {
          # do some cleanup
      }

##### 7.1.5. Variable data

The tabular data (variable data) that the module code must update is stored in the data array (same as the module configuration data in Tcl, named after the module configuration data hash in Perl).

In case of a synchronous module, the core invokes the module update procedure (which obviously must exist) when it is time to refresh the data display (tables and eventually graphical viewers). At this time, the update procedure may update the tabular data straight away (synchronous operation) or launch a request for later data update (asynchronous operation (only available in Tcl)).

In case of an asynchronous module, variable data may be updated at any time. The update procedure may not exist.

For all module types, it actually does not matter when the data is updated. The core will know that fresh data is available when the updates array member is set (actually incremented as it also serves as a counter for the number of updates so far).
It is the module programmer's responsibility to increment this counter right after all tabular data has been updated.

For example, retrieving information for the processes running on a machine is a local operation that can be achieved in a reasonably small amount of time. In such a case, data would be updated immediately and the updates variable incremented at the same time.
But if the data has to be retrieved from across a network, waiting for it to come back would cause a delay that the user would certainly notice, as the application would not respond to mouse or keyboard input during the whole time that it would take to fetch the whole data. In such cases, it is easier to let the update procedure return immediately without setting the updates variable, which would be incremented at a later time, only when the data would become available.

For example, in Tcl, when waiting for data to come across a network connection, the fileevent command could be used on a non blocking channel, where the script to be evaluated when the channel becomes readable would increment the updates array member.

In Perl, this is not yet possible, since the Perl interpreter is dormant outside of the update() function call (a solution to this problem is being studied).

- Tcl: The tabular data array index is the row number followed by the column number separated by a comma. Example:

      proc update {} {
          variable data
          array set data "
              0,0 john    0,1 1234 0,2 4567 0,3 cc
              1,0 william 1,1 8901 1,2 2345 1,3 xedit
              2,0 anny    2,1 6789 2,2 0123 2,3 ps
              4,0 peter   4,1 4567 4,2 8901 4,3 ls
              6,0 laura   6,1 2345 6,2 6789 6,3 emacs
              3,0 robert  3,1 1234 3,2 5678 3,3 top
          "
          incr data(updates)
      }

- Perl: Data is kept in an array (of rows) of arrays (of column cells). Example:

      our @data;
      ...
      sub update() {
          @data = (
              ['john',    1234, 4567, 'cc'],
              ['william', 8901, 2345, 'xedit'],
              ['anny',    6789, 0123, 'ps'],
              ['peter',   4567, 8901, 'ls'],
              ['laura',   2345, 6789, 'emacs'],
              ['robert',  1234, 5678, 'top']
          ),
      }

The column number must start from 0 up to the total number of columns minus 1 (no holes are allowed in the column sequence).
The row number can take any positive integer value (between 0 and 2147483647) and be defined in any order, as long as it is unique during the lifetime of the module data. If a new row is created, it must take a value that was never used: the index of a row that has disappeared cannot be reused. Row numbers need not be consecutive.

When all rows (or only those table cells that have changed) have been updated, the updates member array must be incremented so that the core knows that it can update the table data display.

The Tcl random module source code can be made to function asynchronously: please look into the random.tcl file.

#### 7.2. installation

A module is a package in the Tcl sense. When writing a module, you must then provide a pkgIndex.tcl file along with the module code file, placed in the module directory. The pkgIndex.tcl file is very simple, as the following example shows:

- Tcl: the line below says that if the random package is needed, the core should source the random.tcl module source code from the directory where it was installed. 1 is the major version number for the package:

      package ifneeded random 1 "source [file join $dir random.tcl]"

- Perl: the line below says that if the Random package is needed (note the capitalized name required for Perl packages), the core should load the Random.pm module source code into its own Perl embedded interpreter from the directory where it was installed. 1 is the major version number for the package:

      package ifneeded Random 1 "source [file join $dir Random.pm]"

Modules can be installed at any valid place that the Tcl core allows (look at the pkg_mkIndex manual page for more information).

When you unpack moodss, you will find the sample modules in sub directories. The current directory (.) is appended to the auto_load global list variable so that sample modules can be found when moodss is run from the unpacking directory.

For example, if you unpacked moodss in /home/joe/moodss-X.x/, you will find the random module package in /home/joe/moodss-X.x/random/ so that the following will work:

    $ cd /home/joe/moodss-X.x/
    $ wish moodss random

You can install your new modules in the default location: /usr/local/lib/ on Unix. For example, if you move the files in /home/joe/moodss-X.x/random/ to /usr/local/lib/random/, moodss will still be able to find the random module (again, look at the pkg_mkIndex manual page for more information).

Please take a look at the INSTALL file for the latest information on how to install the moodss application itself.

#### 7.3 Displaying messages

Note: this functionality is not yet available for Perl modules.

You may want to inform the user of the module activity. You may use the message area (called the messenger, across the bottom of the application main window) through the following API:

    pushMessage "your message..."
    popMessage
    flashMessage "your message..." numberOfSeconds

Your message can be any kind of string (1 line only: it should fit in a reasonably wide main window), and numberOfSeconds being optional and defaulting to 1. Note that messages sent to the message area are also displayed in the trace module table(s) if it(they) exist(s) (see below). In such cases, popping messages has no effect on trace module tables.

- pushMessage puts the string passed as parameter to the top of the messenger internal stack and displays it immediately.
- popMessage discards the string at the top of the internal messenger stack and immediately displays the next string in the stack, or nothing if there is none.
- flashMessage is equivalent to a push followed by a pop a number of seconds later. A flash always discards a yet active flash if there is one.

One should use the message area facilities with discretion, as it is already used by the application core for informing the user of modules loading, initialization, updates, context sensitive help, ... My advice is to use it for important messages or errors pertinent to the module itself. Also, the module name should appear at the beginning of the messages for identification, since multiple modules can be loaded concurrently.

You also have the option of using trace tables (also see trace module) through the following API:

    traceMessage "your message..."

The difference is that messages from the module are displayed in the trace module tables if they exist (there can be more than 1 trace module loaded), remain visible to the user for a longer period of time, and can be multi-line.

Finally, displaying separate (toplevel) message windows using Tk is of course always possible (if you load Tk in the module). Keep in mind that the core, not being aware of the module event that has taken place, will continue to invoke the module update procedure (unless the module is asynchronous, of course). In such a case, you may want to use an internal (to the module) busy flag so that the update procedure immediately returns until the user acknowledges the informational message. Other strategies are of course possible (let me know if you have one that you think should appear here as an example).

#### 7.4. Error handling

In order to allow clean error handling with module loading either by command line arguments or dynamically while the application is running, the following rules need be followed:

- in the module body, use:
  - Tcl: the error command.
  - Perl: the die function.
- while in the module initialize procedure or function, use:
  - Tcl: the error command.
  - Perl: the die function.
- thereafter, either the short messages facility (for Tcl only, see Displaying messages) or printing to standard output or error must be used, eventually exiting in case of fatal errors

In the first 2 cases, specifying the module name in the error message is not necessary as the core handles it.

#### 7.5. Perl

Moodss modules can also be written in the Perl language.

An embedded Perl interpreter is used for each loaded module, thus achieving complete independence between modules.

The tclperl library is required (available on my homepage).

Complete documentation for programming Perl modules can be found in the module development section.

#### 7.6. Python

Moodss modules can also be written in the Python language.

An embedded Python interpreter is used for each loaded module (only a single Python based module can be loaded at one time, for the current tclpython 1.x implementation), thus achieving complete independence between modules.

The tclpython library is required (available on my homepage).

Complete documentation for programming Python modules can be found for the moment in the included and fully documented randpy.py randpy module source file.

#### 7.7. Tips and tricks

##### 7.7.1. Single row tables

When data to be displayed is an array of unrelated values, the only solution is to organize the data in a table with a single row and 1 column per value (which does not prevent the use of several views for displaying the data).

In such a case, no index column is required and as a matter of fact rather gets in the way. The trick is to use an empty column 0, use as index by the core by default, and to prevent it from being displayed by using 1 or more views.

Please look at the cpustats module code for a working example.

##### 7.7.2. Void values as numbers

In the module data array, you cannot leave or set a numeric cell empty when no data is available. Use the ? character (also used in summary tables) instead.

### 8. Future developments

The following features will eventually be added to the core (also look at the TODO file):

- more Linux modules
- more data viewers
- table row and column selection in one click

I welcome any suggestion for new features that you may need in your specific use of moodss.

### 9. Miscellaneous information

For downloading Tcl software (such as stooop, scwoop, tkpiechart, ...), many Redhat rpm packages, visit my home page at http://jfontain.free.fr/.

Send your comments, complaints, ... to jfontain@free.fr.