I commited a simplification of the Makefile:
- "make" now builds the GUI executable
- removed useless cruft for building the GUI on Solaris, RedHat 4.x, etc
K.O.

I commited a change to TTriumfFileGUI.cxx to silence the message "No Loaded
Online Histograms". K.O.

Somehow neither Joe nor myself were in the "cvs" group and could not commit
to the miroodas CVS. Fixed by editing root@dasdevpc:/etc/group + NIS reload.
K.O.

I commited fixes for a few annoying problems:
1) get rid of useless "delete/create TCanvas"
2) make the "zones" actually work
3) implement "draw in new canvas", "draw in current pad", "draw in next pad"
and "overplot in current pad"
4) consolidate all drawing into a single "DrawObject()" function.
K.O.

> There are still problems to overcome:
> - the PeakFind panel needs to communicate back to the gui that it has been
deleted (to overcome a segmentation violation error when the pointer is deleted
a second time);

problem confirmed.

> - multiple PeakFind menu items appear when the canvas is split into multiple
pads (even though it is not added if already in the menu???);

problem confirmed.

> - still no way found to get a context menu for the folder icons (Files,
Online, Groups);

right.

> - need to figure out a way to let the user choose the active pad, so he/she
can pick any drawn histogram for peak finding (currently it only works with the
latest drawn histogram).

the current pad (gPad) is selected by clicking on it with the middle mouse
button. This has always worked and it still works (for me).

> - Clear All online histograms has been added to the main menu (it used to be
a button).

right.

K.O.

> > There are still problems to overcome:
> > - the PeakFind panel needs to communicate back to the gui that it has been
> deleted (to overcome a segmentation violation error when the pointer is deleted
> a second time);

This is because you delete it twice- (1) after the users hits the "close" button,
(2) when the destructor is called from TTriumfFileGUI::PeakFind().

I think we should create the peak finder panel once and then hide and show it as
need. I will commit a fix shortly.

> > - multiple PeakFind menu items appear when the canvas is split into multiple
> pads (even though it is not added if already in the menu???);

This is because Joe's check for duplicate menu items is broken (uses the wrong
object name). I simplified this by adding the menu item to the "TH1" class context
menu exactly once in the TTriumfFileGUI constructor. Will commit shortly.
 
K.O.

> > There are still problems to overcome:
> > - the PeakFind panel needs to communicate back to the gui that it has been
> deleted (to overcome a segmentation violation error when the pointer is deleted
> a second time);

Fixed. The peak finder is created once, never destroyed. Window is opened and
closed as needed.

> > - multiple PeakFind menu items appear when the canvas is split into multiple
> pads (even though it is not added if already in the menu???);

Fixed. "PeakFind" menu item is added once in the viewer constructor.

> > - still no way found to get a context menu for the folder icons (Files,
> Online, Groups);

I am looking into it.

In the mean time, I copied&kludged code from TGFrame.cxx to make the popup menu pop
at the pointer position.

Also if histogram is plotted from context menu, the "plot in" menu setting is left
unchanged.

The other problem is multiple selection of histograms. Looking into it.

K.O.

> > > There are still problems to overcome:
> > > - still no way found to get a context menu for the folder icons (Files,
> > Online, Groups);

I do not understand the difficulty- context menus for all menu items work the same way,
so once we know how to implement contect menus for histograms, other context menus are
done the same way. As an example, I added context menus to all non-histogram list tree
items.

> In the mean time, I copied&kludged code from TGFrame.cxx to make the popup menu pop
> at the pointer position.

RTFM of http://root.cern.ch/root/htmldoc/TGListTree.html#TGListTree:description shows
how to correctly position the popup menu without kludging the event handler. Commited.

> The other problem is multiple selection of histograms.

Short answer: Multiple selection of list tree items cannot be done. The code in
TGListTree::HandleButton(Event_t *event) explicitely enforces single-selection by
always unconditionally unselecting all items. I will have to bring this up with the
ROOT team.

K.O.

I commited changes to TTriumfFileGUI.{h,cxx} to add support for looking at
HBOOK files. K.O.

The peak finder context menu item was present only for TH1D histograms and
absent in all other histograms. I fixed this by explicitely adding this item
to the class menu of all TH1X classes. K.O.

Updated build instructions for end-users.

To checkout the miroodas sources use:

setenv CVS_RSH ssh
cvs -d anoncvs@dasdevpc:/usr/local/cvsroot checkout miroodas
(password: anoncvs)
cd miroodas/src
setenv ROOTSYS whatever
make
./TTriumfGui file.root or file.hbook

K.O.

> Access to Roody from anonymous is restored:
> cvs -e ssh -d anoncvs@midas.triumf.ca:/usr/local/cvsroot checkout roody
> pwd: anoncvs

What was the fix? I do not think it was ever broken, except for the name change from "miroodas" to "roody", which I could not document until Pierre restored this Elog forum 
a few hours ago. K.O.

>   We need a simple way of zeroing online spectra, using the roody viewer to
> select which spectra are to be zeroed.

Problem confirmed: there is a button for "clear all", but no buttons for "clear
selected histograms" and "clear just this one histogram". It was suggested that the
right-click context menu for each histogram should have a "clear" action. Maybe same
for a "group".

>    We would also like the histogram view to be unaffected by refreshing. 
> Currently the y axis is autoscaled after a refresh.

I thought this was fixed a long time ago...

>   We would also like a quicker way of manipulating the histogram display, than
> by the awkward, particularly for canvases containing multiple histograms, axis
> manipulation currently available.

I am thinking along the lines of locking the "zooming" of all histograms: on a 2x2
panel of histograms, rezooming any one of them would rezoom the others the same way.

> This could be a toolbar similar to the view
> editor that already exists - are the contents of this customisable, or would a
> separate toolbar be needed?, and would ideally contain the following ...
>    4 buttons, which could each be labelled with a single arrow, for shifting the
> histogram left/right/up/down (e.g. by half the corresponding axis's range).  4
> buttons, which could each be labelled with double arrows, for scaling the x/y
> axes (scaling by factors of 2 and 0.5, about the axis's initial position).  3
> buttons for toggling linear/log scale on each axis (these are in the current
> view editor).  3 more buttons, for resetting the view to default, for retaining
> the current view and for reverting to a previously retained view.

This does not sound like something I can do in 5 minutes, maybe Joe Chuma would take
this on?

>   We would also like to be able to attach markers to a histogram (requiring
> another button to remove markers).  markers would be placed using mouse clicks
> on the histogram, *and* by a text entry box for typing channel numbers.  Markers
> would be labelled with x,y.  There would then be a button to expand an axis
> between the last 2 placed markers.  The markers would also be used for analysis
> such as integral and peakfind/fitting.

Maybe I am missing something, but is this not "standard root" functionality, using
the pad editor and adding "TLabels"?

>   The view manipulation toolbar would be one per canvas, so there would also
> need to be a toggle button to apply the view manipulation commands to all the
> histograms on that canvas, or to just the currently selected histogram[s] (a way
> to select several, rather than just one, histograms would be useful)

I like this: a control for selecting if the action is applied to just one histogram
or to all histograms in a group.

>    This would be very much quicker and easier to use than selecting items from
> long menus, which themselves need to be called by selecting specific, often very
> small, regions of a canvas.

I see: ROOT is geared very much for manipulating ONE graphical object at a time. We
want to manipulate MANY identical objects at the same time and the existing tools
are inadequate, for example because each object is physically very small and it is
hard to point-and-click it.

K.O.

> >    We would also like the histogram view to be unaffected by refreshing. 
> > Currently the y axis is autoscaled after a refresh.
> 
> I thought this was fixed a long time ago...

Never mind that.

Vertical scale of online histograms *has* to change after a refresh- the number of
counts in an online histogram increases as it accumulates more data and the histogram
would grow up out of the visual range unless it is rescaled.

Now, we can be smart about this: for a zoomed histogram, we can freeze the "y" scaling
or we can maintain the zoom ratio while rescaling.

K.O.

Updated CVS instructions for ROODY:

1) cvs anonymous read-only access:
     export CVS_RSH=ssh
     cvs -d anoncvs@dasdevpc.triumf.ca:/usr/local/cvsroot checkout roody
    (username: anoncvs, password: anoncvs)
2) read-write cvs access (requires user account on dasdevpc.triumf.ca)
     export CVS_RSH=ssh
     cvs -d USERNAME@dasdevpc.triumf.ca:/usr/local/cvsroot checkout roody
3) build instructions:
     cvs ... checkout roody
     cd roody/src
     make
     ./roody {file.root,file.hbook,-Hhostname:port}

K.O.

The Makefile bits for building roody on MacOSX have been commited, tested on
MacOSX 10.3.9 with an unknown version of ROOT. Caveats: there is no support for
linking the roody shared library (volunteers are welcome!); there are warnings
about a double-include of libz when linking "roody" (ignore them). K.O.

> 2) the files have been shuffled around

Joe, is there any particular reason why the roody executable is not placed into a
"bin" directory? Just curious. (As one could argue both way: .../bin/roody is more
consistant with MIDAS; .../bin/roody creates a junk directory with only one file
in it).

K.O.

To prevent confusion- according to Joe Chuma and Konstantin Olchanski, we are
still using CVS for Roody development. K.O.