INTEGRATED SVG OPERATING SUBSYSTEM

For the SVG Open 2007 conference

Mr Domenico Strazzullo
Director
Dotuscomus
159 rue Marcadet
75018 Paris
France
nst@dotuscomus.com


Abstract


Business case study. Building an SVG interface for a pre-existing application. Demonstration and analysis of the realization process of grafting a mini operating system using SVG. The script controlled SVG interface allows engineers to monitor parallel microchip procedures.

The reusable GUI.


Table of Contents


1. Introduction
2. Demonstration
     2.1 The Source Window
     2.2 The Events Window
     2.3 The Graph Window
     2.4 The Top Bar
     2.5 The Side Panel
     2.6 The Tabs Panel
3. Technical analysis
4. The reusable GUI
Acknowledgements

1. Introduction

The work I’m going to present is the result of an assignment by a California based company specializing in microchip programming languages. The original assignment consisted simply with the implementation of zooming, panning, menus and other facilities, into a three pane SVG interface that has the role of reflecting the sequence of procedural activities taking place in a programmed microchip, with playback capability. During the accomplishment of this task, the chief of the project has gradually discovered the implementation’s possibilities with SVG, deciding at some point to leave ample scope to the evolution of the project. The specifications were reformulated and the new mission consisted in building a subsystem of windows with most current features like zooming, scrolling, displacement, collapse, maximize, menus, debugger like functions, etc.

A key feature is the possibility of opening new windows: the program running in the microchip can present several thousands of procedures, with events activity taking place in parallel in different channels at a given time. The monitoring engineer must be able to simultaneously visualize procedures in a time zone other than the current or to check events taking place in procedures not currently shown. At runtime one window for each procedure is created but not rendered. This method, while considerably increasing processing time on opening the application, makes the window objects immediately available. Three master windows containing the clones of the totality of procedures are created and rendered. We will see later the technical artifact that allows the interactivity between windows. As with any operating system, any of the windows must come to front on activation.

2. Demonstration

Let’s start the demonstration by describing the function of each of the three master windows opened at runtime and the other elements of the interface; the panes show, respectively:

  1. The Events window , showing the clock driven events sequence
  2. The Graph window , animated graphs of such events
  3. The Source window , the procedures’ source code
  4. The Top Bar ,
  5. The Side Panel ,
  6. The Window Tabs Panel ,
global.png

Figure 1: Global view

2.1 The Source Window

It contains the procedures’ code. This window has line numbering, with each individual procedure’s Source window having conforming line numbering, i.e. the equivalent of its clone in the Source master window. Highlighting of relevant lines and evidencing of code variables are driven by onbegin and onend events of the Graph window procedures nodes’ animations. This type of window is movable and resizable and has collapse and full buttons, but no zoom commands.

2.2 The Events Window

The events window, to the upper right, acts as a monitoring meter and only one unique instance of it is created. It has tape transport functions: play; pause; back 5 sec; forward 5 sec; fast play (x2.5); rewind to begin. While showing the time progression in the form of a moving needle through a time grid, one of its main functions is to show the events taking place in the procedures, materialized by numbered dots on the time (x) and the code’s line (y) axis. This window has line numbering corresponding to the source lines, with synchronous line highlighting. The time grid shows time units expressed in seconds and grid lines with menu selectable spacing values of: 1 sec; 5 sec; no grid. The time units are event sensitive and set the time to the corresponding figure.

player.png

Figure 2: Time control unit

The horizontal slider of this window has the particular behavior, contrary to the other window types, of displacing the needle through the grid while within the grid, or scrolling the grid when the needle reaches the near extreme right of the pane. Another particularity is that it can also act directly on the needle, overriding the clock, to provide a scrubbing functionality, while showing at the same time the percentile position of the slider in respect to the total time on the progress bar. For this reason the slider is made to move automatically along this bar, i.e. it is driven by the clock, while it can still be driven by the user at any moment while in play or pause mode.

The zoom for this window has the same function as in video or sound editing, i.e. it only acts on the time span along the horizontal axis, the other elements, like the graphics representing the events, the grid and the time figures, remaining at their original size. Zoom in is infinite, with the theoretical possibility of displaying a nanosecond in the space of, say, one inch. Display all shows the entire time taken by the totality of the processes. This type of window is movable and resizable and has collapse and full buttons.

eventszoom.png

Figure 3: Effect of the Events window zoom

2.3 The Graph Window

This is the window where the processes are actually visualized. The animated events of procedure nodes taking place in this window determine the state of the other windows. This type of window has regular zoom and panoramic functions, collapse and full buttons.

windowBuf2.png

Figure 4: Events and animation synchronous cloned procedure

2.4 The Top Bar

Its function is to carry the Events window time control unit, timer, menus, as well as act as a status bar showing some information. The Run menu proposes debugger like functions like: back 1 event; back x events; back to last breakpoint; run; run to next breakpoint; forward 1 event; forward x events. The Breakpoint menu allows typical breakpoint actions: show; hide; new; delete; delete all.

menus.png

Figure 5: breakpoints menu

breakpoints.png

Figure 6: breakpoints

2.5 The Side Panel

This is where various types of data, such as channel id, type of data, last known type, last known data, time of last event node id, line/column of source are shown by hovering over channel arcs and ellipses in the Graph window etc.

2.6 The Tabs Panel

Here the windows can be activated to be brought to front, opened or restored after having being collapsed.

tabs.png

Figure 7: Source windows tabs

3. Technical analysis

The windows are created through the DOM interface and encapsulate each of the children of the document node designated to contain the procedures. First, all relevant information like the size and other characteristics of these children is collected and passed as parameters to the window constructor. Next, the solution for meeting the specifications’ requirement of having one window containing all the procedures, plus individual procedures’ windows, follows these proceedings:

  1. Each child node is cloned and the clone appended to the master window, the first to be created and shown at runtime. Events have to be cloned “manually” passing a copy of the event string.
  2. The parameters of the events function calls are modified to take account of the originals and the clones. This action is also carried out on the originals so that originals and clones reflect the same state of events, allowing a total interactivity between the windows. It’s interesting to note a particular problem that I encountered: after changing the function calls parameters of onbegin and onend attributes of the animations, only the original hardcoded parameters were passed, even though a query of the onend attribute would show the modified string containing the clone targets. Obviously, modifications of those attributes weren’t being applied to the SMIL synchronization table, while those of the created clones were taken into account. I haven’t verified if this is the normal behavior. The workaround was to test the existence of the clone node of each ID parameter passed and, if true, force the animation. Not elegant and time consuming but works. While writing this I realized that a smarter solution would have been to remove the original node and append it with the modified event parameters AND with a different id; given that it works for the clone nodes, it should work for any node…
  3. After the master window, the individual procedures windows are created and the procedures appended to them after removal from the document. This technique is also used to bring an activated window to the top; it is removed from its actual position within the document tree and then appended to it.
  4. The windows having been created, only the master windows containing all the procedures clones are opened and displayed.

The sliders objects are properties of the window and have their own constructor with a private event handling function; this theoretically gives some speed gain in the event handling.

The menus constructor is not a prototype of the window, so it can be invoked by any other element of the interface, for example the top bar.

Information retrieved from the procedures nodes also determines the aspect and behavior of each window. For example, Graph windows width is set by the highest x + width value of all primitive graphic elements in a procedure; sliders become inactive whenever the procedure’s graphic displays in its entirety within the window’s minimum set dimensions.

The windows dispose of a common drag area, which becomes a property of the window ad hoc.

The global functioning of the thing orbits around the clock which is controlled by a 50ms (20 fms/s) self-recursive function that basically does three things: get the current time; invoke the player functions depending on conditions; invoke the custom ctm function for the Events window and its horizontal slider’s control function. Depending on user actions, all relevant functions affect a global time variable that is set by setCurrentTime whenever requested.

Another aspect of this project was that the SVG document is built by an engine at a lower level of the production chain. Ultimately, this engine produces files following optimized, human coding technique, reflecting the structural changes applied during the development process. For this reason, the solution of producing the SVG using the DOM, with parameters provided by the engine through server pages for example, hasn’t been adopted. Another particularity is that the SVG presents animations using SMIL. As most of these animations are triggered by onbegin and onend events, and because of the presence of the timer control unit, controlling the animations through the script would have meant reproducing practically the whole SMIL synchronization table, which would have been quite a mission, if possible at all. As it stands now, at writing time, the application does not run under Firefox.

One point of the specification is that the application must be able to run locally. This of course excludes the possibility of saving files, and therefore the possibility of saving preferences under a local configuration. It also excludes the use of XMLHttpRequest for opening and parsing local files because of the local security restrictions.

4. The reusable GUI

Now, after all these bad news here comes the good news, I have decided to make publicly available the reusable GUI under EGPL and because of legal constraints and the difficulty that it would represent to extract it from this very specific work, I have rebuilt it as a stand alone and effectively reusable for more generic purposes (presentation). The windows now have regular sliders. At writing time the menus are not implemented yet. The events window type with its timer control unit will be part of a separate project since it doesn’t make sense to include it in a generic GUI.

The structure and functioning follow the same logic of the application we saw, because I feel strongly that a GUI can only be useful if it is designed to be integrated, in other words if it can do something other than just function for it’s own sake. This interface encapsulates inner SVGs that can either be present in the SVG file, or can be built using the DOM interfaces, or, finally, can be loaded and parsed using XMLHttpRequest, respecting of course the structure expected by the interface constructor (an expert programmer can easily change this structure to suit his needs). This flexibility should make it possible for anyone to integrate their work with the interface (demonstration of replacement). If the windows need to be interactive like in the previous application, it’s up to the developer.

This is a large scope project that will be regularly updated and is available at http://www.dotuscomus.com/svg/lib/library.html#gui

Acknowledgements

Thanks to Jayne DeSesa for contributions on the design.

XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.