FYI, I am presently working in an updated version of roody.

The user interface, GUI and user-visible functionality I am leaving alone. The under-the-hood handling of 
histogram data I am reworking using our latest understanding of the workings of ROOT (object ownership, 
etc) and C++ (hey, with STL std::map, C++ is as easy as perl!).

The updated version may also fix some of the existing problems- crashes caused by confused object 
ownership rules, long startup times (current code has to look at every existing histogram before starting- 
slow if many histograms in an online folder) and inability to display TGraph objects (that is what started 
me working on the code).

While at it, we will move the Roody code repository from CVS to SVN.

K.O.

The ROODY source code repository has been converted from CVS to SVN.

The new command to "get" the sources is:
svn checkout svn://ladd00.triumf.ca/roody/trunk roody

At this time, I do not know how to "convert" a local CVS checkout tree into an SVN checout tree other than 
by brute force (new svn checout, copy modified files from the cvs checout, erase the old cvs checkout 
tree).

For the latest ROODY insructions, please visit http://daq-plone.triumf.ca/SR/ROODY/

K.O.

I commited the missing images, fixed the doxygen config file and added the "make docs" target. Now 
"make docs" will generate the documentation and place it into the directory "html". K.O.

> FYI, I am presently working in an updated version of roody.

The new version of Roody has been commited.

It has been tested only on Linux (SL4.3) and while we are shaking out the new bugs,
all are welcome to try it and report any problems. It should not eat your data.

If the new version does not work for you at all, the old version was preserved as
an SVN branch, accessible using this SVN command:
svn checkout svn://ladd00.triumf.ca/roody/branches/roody-v1 roody-v1

K.O.

> > FYI, I am presently working in an updated version of roody.
> 
> The new version of Roody has been commited.
> 
> It has been tested only on Linux (SL4.3) and while we are shaking out the new bugs,
> all are welcome to try it and report any problems. It should not eat your data.
> 
> If the new version does not work for you at all, the old version was preserved as
> an SVN branch, accessible using this SVN command:
> svn checkout svn://ladd00.triumf.ca/roody/branches/roody-v1 roody-v1

(the email notification for this message did not work at first, trying again)

K.O.

For the record, ROODY svn rev 236 builds and runs on MacOS 10.6.4 with ROOT 5.26.00c. K.O.

I removed the checks for ROOTSYS being the same at run time and compilation time. 
These checks never worked right and are unnecessary since we always install roody 
separately for each experiment and ROOTSYS settings are always consistent.
K.O.

1) roody has been converted from libxml2 to mxml
2) the files have been shuffled around so the *.cxx, *.cpp files
   are in the roody/src/ directory, the *.h files are in the
   roody/include/ directory, the Makefile is in the top roody/
   directory which is where the roody executable goes while
   roody.so now goes into the roody/lib/ directory. The mxml
   files are in roody/mxml.  The *.o files now go into the
   roody/obj/ directory (which is created by the Makefile if
   it doesn't exist).
3) the Makefile has been redone and simplified, and the windows
   stuff removed, since the windows version has its own makefile.
4) clicking on the Help About menu item now displays a message box
   with the current version.  For now, the code must be edited
   manually for each code revision, but it would be nice to automate
   this. 

> 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.

I have talked with Pierre-Andre and Stefan over the last few days about the need
to be able to display graphical cuts (TCutG) in Roody, and also to be able to
change them and send them back to the analyzer.

I expect to have some sample code for putting cuts into a folder sometime soon.

I have some comments on roody :

1)
The peakfinder is only available when you right click on the histogram line.
This is a very limited area. I would rather make the peakfinder available 
whenever you right click anywhere in the histogram area.

2)
On a canvas with zones:
When you start the peakfinder from a histogram, which is not active, roody 
searches for peaks on the active histo. Therefore, I would make the histogram 
active, whenever you click on the histo, no matter which button you click. Or 
the peakfinder should make the histo active first.

3)
When you change the zones you loose all your histos. I would prefer to have the 
histos, which are already displayed also on the rezoned canvas. 

4)
When I resize the x-axis of a histogram by hand and then plot a new histogram 
in the same pad, I loose the scale I have choosen. There should be a switch, 
with which you can keep the settings of a histogram for further histos.

If you agree upon these requests, let me know if you like me to implement some 
of these features.

> I have some comments on roody :
> 
> [snip]
> If you agree upon these requests, let me know if you like me to implement some 
> of these features.

These all seem like good suggestions and it is fine with me if you want
to work on the code.

I have committed point 1 and 2.

For point 3 you need to save all displayed histos in a stack. So that you can plot 
them into the rezoned canvas. I don't know if you want to do that.

I would prefer if you would do point 4.

Matthias

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

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

  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.  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.
  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.
  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)

   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.

Chris

>   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.

The original "main.cxx" always produced "segmentation fault" on my system. So I 
rewrite a new one as the attached "main_el.cxx". It works stable on my systems. I 
use "getopt.h" to parse the command line options. Also, the options are altered 
as the following:
-------------------
--mhost, -M <mhost>   connect to MIDAS server <mhost>
--rhost, -R <rhost>   connect to ROOT server <rhost>
--port, -p <port>     connect to port <port>
--config, -c <xml>    Using config file <xml> in XML format
-------------------
The main_el.cxx doesn't pass options to TApplication except root file names. 
Please see the source in detail. I hope it may help.