ROOT's GUI

and

Visualization of Histograms & Ntuples

Table of Contents

• Goals of the Investigation
• The Areas of Concern
• Recommendations
• Costs of Accomplishing the Recommended Tasks
• Display, Visualization, and Manipulation of Histograms/Ntuples & Integrating Nirvana Products

References

• ROOT Home Page
• Nirvana Home Page
• PASSREC Home Page

Goals of the Investigation

This report discusses the investigation done by Joy Kyriakopulos and Philippe Canal for the Run II Physics Analysis Software Recommendations Group (PASSREC) on the following aspects of the ROOT Physics Analysis System:

• the GUI
• its display, visualization, and manipulation of histograms and ntuples
• the feasibility of integrating ROOT with Nirvana products such as the Plotting Widgets and the Histo-Scope API.

The major portion of this report concerns the GUI. The last two topics will be be discussed in the last section of this report.

The Areas of Concern

ROOT has been an aggressive project for its limited number of developers. ROOT contains some very impressive functionality, and some of it is readily useable and integrated nicely. Yet, it is our opinion that ROOT's GUI and visualization functionality still needs careful attention, enhancement, and some redesign.

We have categorized the areas of concern for the ROOT GUI as follows:

1. Intuitive use - We found ROOT to be difficult to use for the neophyte. An important goal of a good GUI is to make it easy for the new user to accomplish real work and provide an educational help facility to point the user in the right direction. While there is much information in the ROOT web pages, it is almost entirely geared towards the ROOT classes used in writing C++ programs or CINT scripts. This www help facility seems to follow the design of ROOT. We could find no way to run a GUI and use that for physics analysis. Things must begin in CINT by either creating objects or reading files and then creating a canvas which has a GUI for graphics editing. There are many GUI classes implemented, but everything still seems to start with CINT unless someone has "built" a GUI for a specific use using ROOT. We suspect that "experienced users" will quickly collect a set of macros for repetitive tasks they often do.

Some of the functionality that is available in the GUI is hard to find. For example, we could not find a GUI window for files or Ntuples that displays what items are in a file or the variables in an Ntuple and allows the user to select items or variables and the kind of plot to generate. After asking Rene he showed us how the TBrowser class (available from a canvas menu) has most of these features in it, but we had to look at the bottom of the TBrowser file folder list to see the file folder and know to click on it to open it. Also, the meaning of some buttons and other GUI adornments are either confusing or a complete mystery (e.g. "gStyle" button).

It is possible to add features and menu items to the GUI through macros while you're running. This is a way for users to customize their GUI and make it easier for them to do things they want readily accessible.

2. GUI design - other functional additions or changes of the GUI's functioning and layout will be necessary for it to conform to good GUI design. For example, when opening files, the directory should not be "sticky" unless a file has been successfully opened in that directory. It is also a good idea to have a Windows menu for all ROOT windows and canvases so the user can find his ROOT windows easily and bring them forward (visible). Another example is to include at the top of all attribute windows the name of the canvas to which it belongs to avoid confusing which canvas window's attributes are currently being changed. Lastly, the efficiency and effectiveness in accomplishing tasks is another important GUI design consideration.
3. There is a serious CINT/GUI protection problem between doing something via the GUI vs. CINT. This needs to be solved because doing very simple things from first CINT (e.g. creating an object), then the GUI (like deleting that object), and then trying to access that object in CINT can and will probably cause irrecoverable errors that result in lost time and work for the user (i.e. CINT crashes).
4. More testing and bug fixing - i.e. going through it "with a fine tooth comb," robustness, dependability.
5. Incomplete functionality - some essential functionality still needs to be implemented, such as "Undo" in canvas windows. There also is more work for selecting Ntuple names and plot options that needs to be done. The integrated fitPanel is nice, but does not offer all the functionality available in MINUIT or NFit. Some users will need the additional features.

As it stands today, the GUI would be usable for experienced users who have their set of CINT macros at hand and know their way around if #3 and #5 above were solved.

The ROOT GUI most probably will be a moving target for at least two reasons. First of all, Rene has mentioned the that they have reworked the implementation of the look and feel. They admit that how the panels are put togther in the GUI still could benefit from major enhancement. (He is hoping a co-author of PAW++ will be transferred to the ROOT team to free himself and Fons to work on other things besides the GUI.) Secondly, as more functionality is implemented into the ROOT system, most of these new features will require changes or additions to the graphical user interface. For these two reasons it will be very difficult to estimate the work that will be required for ROOT's GUI. Therefore a closer collaboration between ROOT and Fermilab on the ROOT GUI deserves consideration as a possible best plan of action. Rene welcomes this and has told us that he would like to see one person at CERN and one from Fermilab working closely together with clearly defined functional responsibilities set aside for each developer. Since Rene knows ROOT better than we do, his estimation of the amount of work that could/should be done with the GUI should be considered.

---

Recommendations

First, Fermilab needs to come to some agreement with Rene about what direction the GUI will take, and which parts will be done by CERN and which by Fermilab. It is probably too being too hasty for Fermilab to decide this today without further discussions of collaboration.

Therefore the assumptions we used in listing our recommendations below is that of making the ROOT GUI useable, not perfect or even wonderful. GUI's generally can take up great amounts of time in up-front design and polishing the implementation based on user experiments and user input. But there is much grey area between barely usable and perfect, and for these recommendations we have taken the approach of defining usability as having the following attributes: fairly intuitive to use, online help to guide the user (of the GUI), robust execution and recovery from common user errors without loss of work or data, functional completeness, and effectiveness/efficiency in accomplishing analysis tasks (it should take less time to do something in the GUI than to write a program to do the same thing). Lastly, the physicist user should be able to concentrate on his/her physics while using the ROOT GUI, not on how to use the software. (This is a very important question to ask when designing changes and enhancements to the ROOT GUI. Can the physicist user concentrate on his/her analysis while using the present GUI? The answer to this question should come from physicists, not computing professionals.)

Noting the assumptions above, we make the following recommendations to address the above areas of concern:

1. Intuitive use - A GUI executable for naive users needs to be designed and implemented. In addition the currently existing GUI panels need to be thoroughly reviewed for the naive user. The existing GUI panels often almost carbon copies of the ROOT classes and often require knowledge of the ROOT classes and their attributes to achieve real work. Careful thought and effort should go into "choosing one's battles" so that work in this area is limited by clear goals and guidelines for usability rather than perfection. Once the most serious areas are addressed, remaining needs can be considered as a "background task" to some of the other important tasks below.
2. Good GUI design - As above, usability is the goal. However we do believe that some effort and priority should be made towards better efficiency and effectiveness in accomplishing tasks via the GUI. Most things, if not everything, that is implemented in the GUI should be easier to accomplish from the GUI than by writing a program fragment in CINT. Any usability issues that tend to frustrate physicists in doing their analysis should be solved. Part of the task will be in canvassing opinions about the GUI from physicists using ROOT.
3. The CINT/GUI protection problem - this one is serious and quite difficult to solve. One complexity to this goal is whether CINT itself will be rewritten. Whichever CINT is used, it must be modified to include hooks to update its data and pointers when things are deleted and changed from the GUI. Rene is quite aware of this problem and knows better than we do what is required to fix this.
4. More testing and bug fixing - somebody needs to do this, preferably not the hard way by users all around the world. We deem this important, but capable of being done somewhat "in the background."
5. Incomplete functionality - "Undo" in canvas windows needs to be implemented to reverse any mistakes the user may make. This is a complex and time-consuming feature to add, but the canvas window, from an annotation standpoint, is not complete until this is implemented. The "gStyle" button functionality Rene has decided on needs to be implemented. The areas of the GUI that are currently in flux must be resolved and changes implemented. New features to ROOT that require or suggest changes to the GUI need to be designed and implemented into the GUI. There are also some open issues between the Windows version of the GUI and the X-Windows implementation. From a practical standpoint this, along with bug fixing, should be given the highest priority and initial attention.

---

Costs of Accomplishing the Recommended Tasks

Before listing the estimated costs, we need to note that because of the many variables and uncertainty surrounding some these issues, the following estimates are only guesses made with imperfect knowledge of ROOT's current and future functionality:

1. Intuitive use - work in this area limited by clear goals and guidelines for usability rather than perfection: .3 FTE.
2. Good GUI design - .3 FTE.
3. The CINT/GUI protection problem - CINT work not estimated because of the uncertainty of a CINT rewrite and the feasibility question of implementing it into the current CINT. Rene himself was hesitant about modifying the current CINT to accomplish this. If CINT is rewritten, it should be designed for consistency with the GUI and provide hooks callable by the GUI. The GUI portion of the modifications are much smaller in comparison with the CINT modifications.
4. Testing and bug fixing : .1 FTE per major release. It is important to note that testing of the GUI must be done for each major release of ROOT and also involves testing the functioning of the ROOT classes the GUI calls. (It is quite possible for the classes to appear to work from a program and yet break the GUI. Thus it is still necessary to re-test functionality from the GUI even if the majority of changes lie with the underlying libraries. This estimate also assumes a re-testing of new GUI functionality integrated with new ROOT system functionality. All this certification must be done for all systems and platforms Fermilab requires.

It is possible that a better idea would be to write a test suite rather than always depending on manual testing. This would involve more up-front cost, but be a benefit in the long term.

5. Incomplete functionality: .5 FTE. This could be larger if the "moving target" of new ROOT functionality moves quicker than we expect.

Thus, we expect at least the equivalent of 1.1 experienced full-time C++ programmer(s) will be needed to address concerns with the current ROOT GUI plus one month per ROOT major release for integration, testing, bug fixing, and certification.

When passing these estimations past Rene, he suggested that two people (one from CERN and one from Fermilab) could work on the ROOT GUI. Thus we conclude that there are many more things he would like to see in the GUI than were apparent to us in a couple of days of studying ROOT. For example, Rene would like to see Java based GUI classes with a C++ backend, which is probably a very good idea.Thus we believe there is merit in further examining how GUI collaboration should proceed.

Display, Visualization, and Manipulation of Histograms/Ntuples & Integrating Nirvana Products

Initially, the question of integrating Nirvana products seemed important; however as we began thinking about it more, the question seemed somewhat absurd. Admittedly the Nirvana products do not have the broadness of functionality that ROOT has. Some of the best attributes of the Nirvana products and GUIs are the built-in good design, robustness, consistency, and quality. Functionally, however, Nirvana users really like the interactivity of the plotting widgets, the rich functioning of the two-dimensional histogram (LEGO) plot, and the interactive browsing of data as it is being generated. Also, NEdit is clearly the best free GUI editor around and is already usable as the default editor in ROOT by setting an environment variable.

ROOT's best attributes seem to be the broadness of functionality and its current availability. For example, ROOT currently has a neat graphical editor that allows annotation of plots and even more general, hierarchical graphical editing. This functionality does not exist currently in the Nirvana suite (although it was planned as the unimplemented NDraw product). Histograms are very flexible and easy to create, fill, save, and draw (from CINT). Some work on Ntuple browsing and plot options from the ROOT GUI still needs to be done. ROOT also has integrated fitting, where at the flick of the GUI, or from some C++ code, MINUIT is called and the fit drawn on top of the plot. Nirvana's fitting package (NFit) is a separate product, and is not integrated with the Histo-Scope browser (by design). NFIT contains some fitting functionality that is not currently accessible from the ROOT GUI. ROOT also has graphical display of surfaces, contours, bar charts, and detector objects, which do not exist in the Nirvana products.

ROOT currently does not support a time-series plot but hopes to have one in the future. One is available in the Nirvana Plotting Widgets package and from Histo-Scope. We also prefer many of the interactive features of the Nirvana plotting widgets when compared to the ROOT way of interacting with plots. For example, you can either drag on an axis to scale a Histo-Scope plot or quickly bring up a background menu which allows entering the numeric limits of the plot. We also found the sliders used in ROOT to set values difficult to use (perhaps we're just used to Histo-Scope sliders). One feature of ROOT we did like is the ability of to pick points on the plot and drag them around which is not currently implemented in Histo-Scope or the widgets (nice for composing pictures, but less useful for real data display). Also, ROOT provides many data formats for saving plots (.ps, .eps, .gif, .C) which is a clear benefit over the Nirvana widgets which provide only X-Display and Postscript.

There are a few reasons why users might want some functional level of integration of Nirvana products with ROOT:

• They don't know C++ and want a simple, immediately usable GUI tool.
• To dynamically browse data as it is being generated by a ROOT process (?)
• To gain the interactivity of the Nirvana plotting widgets or immediate need for a Time Series plot.
• To access current Histo-Scope-format files for use with ROOT.
• To access ROOT files for use with Histo-Scope or NFIT. (?)

The majority of Histo-Scope users are using the product for its dynamic data browsing capabilities (from other running processes) rather than just for browsing files. ROOT does have a program called "rootd.exe" (standing for ROOT Daemon) that runs in the background on a computer and works as a server to carry out ROOT commands given over a local area network. It also supports web-based access. Rene claims that ROOT has all the dynamic functionality currently used by Histo-Scope users through local shared memory or sockets and has macros available on his tutorials web pages that can be run to accomplish this. However ROOT does not run on online VxWorks systems as the Histo-Scope API currently does. Thus, there probably is still a need to use Histo-Scope in such situations. If such experiments will also be using ROOT, there may be the need for file interchange or conversion from one file format to the other. It is debatable whether there is a need to call the Histo-Scope API from a ROOT application so the data could be browsed on another system by Histo-Scope. In this case, a shareable image of the current Histo-Scope API library could be made available to make it easier for ROOT users to include the library from CINT (on those systems that support shareable libraries).

If it turns out that Run II users need some of the graphical capabilities offered by the Nirvana widgets but not offered by ROOT, it is conceivable that a ROOT application could link with the Histo-Scope plotting widgets and open a separate window to display a Nirvana plot widget. However, unless the widget is integrated into the ROOT system, or at least callback hooks provided by ROOT, this display would be outside of the ROOT display event loop and would have to begin and end before the ROOT displays do any further work or updating. The nice graphical editor would also not be available to that window. Thus before evaluating how to proceed on this area of concern, it is important to evaluate the level of need in Run II to design an appropriate solution. For integration into ROOT, a Nirvana plotting widget would probably have to be modified slightly to remove the Motif dependency currently inherent in the widgets. Since the Nirvana widgets use Motif primarily for window shading and other minor considerations, the modifications to the widget itself are expected to be straightforward (assuming internal widget data formats are preserved).