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

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.

Attached is a cvs patch to allow roody to display graphical cuts (TCutG).

Does somebody have the permissions to commit this patch to the cvs repository?

It also includes some hooks where code for updating a cut will be implmented.
Updating cuts will be done with another patch, to both roody and midas.  This same
mechanism can be used for creating new cuts and sending them to the analyzer.

The final part of this project will be a change to midas to allow cuts to be booked
into (sub)folders.  I have some code which I am using for testing purposes, but I
don't like where it stores the cuts for persistence between different invocations of
the analyzer.  I'm thinking that cuts should be stored in last.root, and retrieved
from there.

John.

> Attached is a cvs patch to allow roody to display graphical cuts (TCutG).
> 
> Does somebody have the permissions to commit this patch to the cvs repository?
> 
> It also includes some hooks where code for updating a cut will be implmented.
> Updating cuts will be done with another patch, to both roody and midas.  This same
> mechanism can be used for creating new cuts and sending them to the analyzer.
> 
> The final part of this project will be a change to midas to allow cuts to be booked
> into (sub)folders.  I have some code which I am using for testing purposes, but I
> don't like where it stores the cuts for persistence between different invocations of
> the analyzer.  I'm thinking that cuts should be stored in last.root, and retrieved
> from there.
> 
> John.

cvs commit made today to support display of polygons, and sending polygons an analyzer.
A patch for mana.c so that MIDAS analyzers receive polygons has been sent to Stefan.

John.

I have just sent a MIDAS patch to Stefan so that:

(1) cuts should be booked using TCutG *cut_book( const char *name).
    Usage is similar to h1_book etc.

(2) cuts are saved in last.root.

(3) cuts are restored from last.root.

I also fixed a bug in receiving cuts from ROODY.  The search for
cuts should be made only in gManaHistosFolder, not from gROOT.
Should this also be the case for GetPointer etc.?

I believe this implements a first pass at handling TCutG for MIDAS and ROODY.
To create a cut from scratch, one declares it in the analyzer init functions
using cut_book, and saves the pointer for use in the event-by-event code.
Then in ROODY, create a polygon, name it and send it to the analyzer (right click
on the polygon).

I believe the patchs which I have made should also be applied to ROME.

John.

I just downloaded and compiled the latest tarball.

line 98 of DataSourceTNetFolder.h complained about unit32_t.  While I could have
added an include to make this work, I instead changed it to use the ROOT type
UInt_t.

Perhaps this change should be included in the distribution

I'm using Redhat workstation with:
  gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
  ROOT version 5.16/00

it is unlikely that UInt_t will ever be too small.  If it is too small, then ROOT will
break!  It is clearly intended to be 32 bits long.  From Rtypes.h:

#ifdef R__INT16
typedef long           Int_t;       //Signed integer 4 bytes
typedef unsigned long  UInt_t;      //Unsigned integer 4 bytes
#else
typedef int            Int_t;       //Signed integer 4 bytes (int)
typedef unsigned int   UInt_t;      //Unsigned integer 4 bytes (unsigned int)
#endif

Of course, stdint.h is defined in a standard.  However ROOT doesn't really try to follow
the standard (CINT compiles a language similar to C++, but not exactly C++), and indeed
the file stdint.h is not explicitly included in any of $ROOTSYS/include/*.h.

John.

> > I just downloaded and compiled the latest tarball.
> > 
> > line 98 of DataSourceTNetFolder.h complained about unit32_t.  While I could have
> > added an include to make this work, I instead changed it to use the ROOT type
> > UInt_t.
> 
> Uint_t is technically incorrect. The data returned from the socket connection is a
> 32-bit pointer to an object in the remote process (how do they come up with
> communication protocols like this?!?). The type "Uint_t" is not defined to be of any
> particular size and is not necessarily big enough to hold a 32-bit unsigned integer.
> 
> According to the "C99" standard, the correct C data type for 32-bit unsigned
> integers is uint32_t, defined in "#include <stdint.h>", e.g. see
> http://www.oreillynet.com/pub/a/network/2003/10/07/michael_barr.html
> 
> I have now added the missing "#include <stdint.h>" statement to
> DataSourceTNetFolder.h, commited as revision 230.
> 
> I am puzzled why the code compiled without this include statement, possibly on my
> SL4.3 machine with ROOT v5.16.00, some ROOT or system header file included it for
> me. I am curious what system you use where this code failed to compile?
> 
> K.O.

Right click on Offline folder opens the file dialog.

Right click on Online folder opens the hostname dialog.

If only one group exists, you will not be asked to choose the group when adding items to a group.

Command line argument change:
 -h (or -H) followed by nothing shows program usage
 -hhostname or -hhostname:port connect to analyzer on given host (and port)
 -rsavefile restores savefile

Offline items added to a group are new removed from the group if the
file is closed.

Offline item titles are now displayed after the name if different than
the item name.

"Run# number" added to the item title if the filename contains a runnumber.

Command line argument change:
   the space between -h and hostname is optional
   the space between -r and filename is optional

The save file is now an xml file validated with roody.dtd

When saving or restoring, if you enter a filename without an extension,
.xml will be appended.  The previous save file format is no longer
supported.

New files:  RoodyXML.h, RoodyXML.cxx, roody.dtd

Fixed up group problems when an online file is located in a folder.

Makefile modified to support libxml2.

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

When the number of zones (sub-pads) is changed, any histograms on the active
canvas will be redrawn on the new canvas.  Also, more general code clean-up.

To set the x-axis limits, right click anywhere on a histogram frame and choose
"XaxisLimits" from the popup context menu.  This brings up a dialog box where
you can enter the xmin and xmax values. Click "OK" and all pads within the
currently selected canvas will be redrawn with that x-axis scale.  To reset all
histograms so the x-axes are unzoomed, click "Unzoom".

Every overlayed histogram on a currently drawn histogram, will be drawn in a
different color (up to the max number of colors).

When choosing a new pad division for a canvas (from the "Zones" menu), all
currently drawn histograms on that canvas will be redrawn in the new zones. If
there are fewer pads in the new configuration, the extra histograms are not
drawn.  Overlays (with their color) and x-axis scaling are preserved in the new
configuration.

When opening a .root file, if there are more than 1000 histograms in the file,
the display is divided up into folders, where each folder holds 250 histograms
(except for the final folder, which may be smaller).  This was done because of a
problem with TGListTree which only shows up with a large numbers of objects.

A minor update to the previous bug fix...
Modified Roody.cxx to display the histogram name range instead of the counter
range on the subfolders when reading > 1000 histograms from a file.