The GDMS user interface is the most prominent part of the application. It is the main way in which the user experiences the application. GDMS currently supports two user interface variants: The X windows user interface (the program called GDMS) The batch user interface (the program called gdms-batch) This section will deal primarily with the research undertaken for implementing the X windows user interface. This is not only due to the fact that the scale of implementation required was much greater for this variant, and because there were many more alternatives available. There are a plethora graphical user interface toolkits available today. As each has it's advantages, a small survey of the options considered, and then a discussion of why wxWindows was selected is appropriate. The Common Desktop Environment (CDE) was jointly developed by Hewlett-Packard, IBM, Novell and Sun Microsystems. These companies have subsequently adopted CDE as the standard window manager as shipped on a variety of their various operating systems (Chapman 2002). CDE uses the Motif windowing toolkit.

imgsun-cde.gif

KDE development started in October 1996 (KDE 2002), as a replacement for Sun's CDE. KDE is based on Trolltech's qt widget set (Trolltech 2002). KDE is available as an installation option on the majority of the Linux distributions available.

imgkde300-snapshot2-320x240.jpg

Gnome is the default window manager and windowing toolkit set for many Linux distributions, including Red Hat Linux, which the Survey Lab at the University of Canberra makes extensive use of. Gnome is implemented using the GTK windowing toolkit (GTK 2002). Sun Microsystems have recently announced that from Solaris 8, Gnome will be available as a window manager. They have also announce that CDE will be replaced with Gnome in future releases (Sun Microsystems 2002).

imggnome.png

Whilst not a X windows toolkit, Window's MFC toolkit was considered as a development alternative for GDMS. However, the survey lab does not currently contain any Microsoft Windows machines, so this option was not pursued any further.

imgmfc-xp.jpg

Whilst wxWindows is not a window manager in the same sense as the others discussed in this section, it has a variety of advantages relevant to GDMS. These include: The ability to use a variety of windowing toolkits. wxWindows supports GTK and Motif for Unix and Unix-like operating systems. Windows is also supported. Cross platform functionality. This allows GDMS to run on a variety of Unix and Unix-like operating systems. Based on the factors outlined above, the group selected wxWindows for the user interface implementation of GDMS. As previously mentioned, all of these toolkits require developers to write in C++, which was one of the determining factors in the language choice for the development of the application. There are two common implementation methodologies for scripting languages. Both of these were considered for the GDMS implementation. The most common manner for implementing the parser and grammar for a scripting language is by using the compiler construction tools yacc, and lex (or their free versions, bison and flex). Lex and flex are parser generation tools. They take a lexical specification file, and generate a LALR finite state machine for matching input strings (Aho, Sethi & Ullman 1986). A sample of a lexical specification is shown below (in this case for the PDF file format): <INITIAL>\%PDF-[0-9]+\.[0-9]+ { debuglex(yytext, -1, "version"); yylval.sval.data = (char *) returnStr(yytext, -1); yylval.sval.len = yyleng; return VERSION; } <INITIAL>[+-]?[0-9]+\.[0-9]+ { debuglex(yytext, -1, "floating point"); yylval.sval.data = (char *) returnStr(yytext, yyleng); yylval.sval.len = yyleng; return FP; } <INITIAL>[+-]?[0-9]+\.[0-9]+\>\> { debuglex(yytext, -1, "floating point"); yyless(yyleng - 2); yylval.sval.data = (char *) returnStr(yytext, yyleng); yylval.sval.len = yyleng; return FP; } In this example, two tokens are defined, VERSION, and FP. The syntax for these specifications is relatively simple. The first field, which is wrapped in angled brackets, is the name of the state that the specification should be used in. All of the examples shown here are for the default state, known as INITIAL (Levin, Mason & Brown 1990). What follows this is a posix compliant regular expression to be matched. Finally, within the braces lies C code to execute when a match occurs. In each of these examples, the C code writes a log entry for the match, sets up the data structure symbolising the match, and then returns the name of the lexical token which was matched. Yacc and bison define the grammar which uses the tokens defined by lex or flex. In effect, this defines valid orders for the tokens to appear in, and what operations should be performed when a set of tokens is matched. Error handling for undefined token combinations is also supplied by the grammar. This is done through the use of hooks for reporting to the user in a manner which is appropriate to that particular application. A sample grammar specification, in this case for SQL (Connolly & Begg 1998) is as follows: SQL : create SQL | insert SQL | select SQL | ; create : CREATE TABLE STRING '(' colvalspec ')' ';' {} ; insert : INSERT INTO STRING '(' colvalspec ')' VALUES '(' colvalspec ')' ';' {} ; select : SELECT cvsaster FROM STRING {} wsel ';' {} A grammar consists of three building blocks. Each of the tokens which can be returned by the lexer is termed a terminal. Examples from above include CREATE, TABLE, STRING, INSERT, INTO, VALUES, and SELECT. These terminals are used by non-terminals, such as SQL, create, insert, and select from the example above. The rule which groups a non-terminal with a series of other non-terminals, and terminals, is called a production (Aho, Sethi & Ullman 1986). This grammar defines a language in which a SQL statement can consist of either a create, an insert, or a select statement, as shown by the SQL production. The empty non-terminal on the SQL production ensures that an end of file or empty line is also matched. It should also be noted that the SQL production is recursive, except for this case which matches the empty line or end of file. The alternative to using the compiler construction tools is to develop a language parser by hand. Depending on the complexity of the grammar to be implemented, this can be quite a realistic alternative. On the other hand, if the grammar is complex, then it can rapidly escalate into task of much larger scale, comparable to that of the rest of the application. This option was found to be the most suitable for the GDMS. The grammar for the scripting language implemented by the batch version of GDMS is relatively simple, in that all commands are parsed based on only one line, and no recursion within productions is required. As mentioned earlier in this section, the graphical user interface to GDMS was implemented using the wxWindows windowing toolkit. The batch user interface was developed using a hand coded parser written in c++. This has maximised the amount of design flexibility enjoyed by the development team, whilst minimising the amount of unnecessary code development. A significant portion of the GDMS user interface development was integrating the various classes and features with the graphical user interface. This integration has been facilitated by a standard process for integrating mathematical functionality. The process is as follows: All functionality is either accessed from the mouse, or a menu. This leads to a consistent user interface, and minimises user confusion. The output of all mathematical operations is a new dataset, and hence a new tab in the main application window. This has several advantages, including:- Facilitating the implementation of the batch interface to the application. Allowing ease of comparison of the dataset before and after the application of the mathematical operation Further documentation of the actual functionality available in the GDMS application is available in the user manual. Whilst the user interface for GDMS is fully functional, there are a variety of improvements which could be made in the future. These include: Online help: the application does not currently provide any help in the user interface. wxWindows supports the display of HTML files within windows, which would an efficient and standard method for the implementation of online help within the application. Greater resilience to errors: if an error is discovered, the application currently abandons all further processing on that dataset. This should be improved in the future, so that a failure will not stop all calculations. Greater flexibility in the batch user interface: Further research into what other commands should be implemented needs to be undertaken. The ability to determine the value of the nearest data point by hovering over it: Currently the application checks the location of the mouse and looks up the relevant graph values. This is misleading as the display resolution means that is almost impossible to determine with any accuracy, the value of the data point at which you are pointing. The ability to edit out points from the dataset: once accurate mouse pointing is integrated this will be trivial. Meaningful graticules: currently the graphs are displayed with a fixed number of graticules, and the scale is modified accordingly. This can be deceptive and must be revisited in a future release. Revision of this code was attempted late in the process, but due to time constraints and an uncooperative plotting library this was abandoned. Analysis of plotting precision: currently the precision of the graphs is such that using high sampling frequencies and cause them to lose precision. Analysis of the plotting functions needs to be considered to minimise this.