A guess is that a PHOBOS GUI might have over 90% of its available information in the form of web pages, which can easily be written by the detector experts. Only the remaining (essential) 10% would be information from the on-line run or offline processing, which would be obtained via compiled or macro C++ code in ROOT. The web is appropriate for information which changes on a scale of days, not hours. It could include catalogs of previous "standard" plots, taken every N hours, to help in validating current runs (instead of the familiar fat binders of plots looked at during "checklists"). These could be automatically generated, saved and cataloged. These can then be accessed from within ROOT. The advantage over external browsing is that the references can be automatically linked to the objects of attention in ROOT.
Another observation is that interpreted C++ i.e. ROOT macros are sufficiently fast in general for human interaction. There is no real advantage, and some loss of flexibility, in compiling the macros in many cases. Where there is considerable looping inside or other time consuming code, or where there is a clearcut object of general use, compilation as a shareable library (as for instance this author's TPhGEA class) compilation is straightforward and .L macro.C is simply replaced by .L compiled.dll or .L compiled.sl. Macros can "talk" to each other as well as to shareable or compiled-in objects, as this demo illustrates.
The full "event display" may be mainly for "show", as is sometimes pointed out. An exception may be pattern recognition where a 3-d view (in real space or some sort of phase space) may help diagnose problems. For detector monitoring it may be preferable to simply have a table or matrix of buttons, perhaps a table for each subsystem, with the detector name e.g. SPA1 on each button plus a large button for subsystem attributes. Nevertheless it's fun to speculate on extensions beyond 2-d plots and histograms of data display. For example a "fur plot" in 3 dimensions could show nearly all PHOBOS data in one view: Imagine a lego plot (or perhaps just a single line or "bristle" attached to each pixel) attached to each silicon wafer in the view, with its orientation; the length of each bristle could represent pulse height or frequency of hits. A view of the octagon would be an instant snapshot of the rapidity and phi distribution! Maybe the bristles could be made to point away from the event vertex, so that the octagon display would look something like a furry caterpillar. (Note the perp. distance of the bristle end from the base plane is then the dE/dx i.e. the pulse size obtained if the track had been normal incidence.)
An "AUI" rather than a "GUI" might be useful for online operation; it could be useful to be jolted at 3 AM by a voice from the workstation "Wake up! Bias supply l4 is off!". As implied in the cryptic remarks in "Instructions" about a little red button, I've tried gSystem.Exec() on an audio program.
It appears that for general program control ROOT has facilities equivalent to those used similarly in LABVIEW. Some of us recall the very nice experiment control display written by Huang K. T. for our 1997 testbeam run; it appears that ROOT would be able to duplicate such an interface. Another GUI I have in mind is an interface to multiple processors used by STAR and shown at the LBL Dec. '96 RHIC Core Software Workshop. This was, I recall, written in Tcl. Here we can follow the general principle of using the highest level language available to save work.
There are some "generic" issues of concern. The wish for more systematic exception handling has been expressed by others. A "crash" should allow quick return to the point of work. A related issue is how to go "sideways" in navigating an online GUI; an example of a partial solution to such a problem is the "GO" pulldown with a site history in Netscape. Of course keeping several windows open may often solve the problem. A useful feature would be a "user profile", maybe a choice of several, which would take you immediately to the region of your greatest responsibility and concern (such as TOF for Rochester).
Is this a wild idea or actually useful? In noting the integration of the web into ROOT illustrated by this demo one asks the converse, can ROOT be integrated into the web? One example is to set a special version of ROOT, let's call it roote, as a helper application for a browser keyed to ROOT Tree objects of file type .root. Then roote would receive the whole file, similar to Ghostview etc.; roote would then open this Tree-structured file and from one "leaf" which is in fact a CINT macro would get its instructions for opening the canvases, button panels etc. useful for manipulating this particular tree. For example, one might have a set of histograms in the tree, with a button panel or "presenter" (such as discussed often recently in ROOTTALK) opened automatically for their convenient access. A disadvantage of this simple approach is that the whole tree would be transferred, perhaps giving a long delay. The new class TWebFile allows access to selected byte ranges i.e. portions of the Tree but to open, ROOT needs the URL for the file. Somehow this would have to be passed from the web browser instead of the actual ftp'd file; does anyone know how to do this? It's probably information available via the plug-in API but I've been warned off the idea of making ROOT a plugin... too browser/system dependent! Maybe the JAVA experts can tell us all how to integrate in ROOT; one gathers that the ROOT team has some ideas about JAVA in the background.
Many in PHOBOS will contribute to the form of interactive monitoring
and control. It seems best at this time to concentrate on providing
useful tools, and tutorial examples. Soon we may need to define "the"
online GUI but this seems premature now... we need more ideas and reactions
from users.