FairRunOnline: Support for non-jsroot monitoring?

[klenze]

While I have to concede that jsroot works, I would still prefer (optional) support for some non-web GUI.

During the last two decades, a vaguely FAIR-related Helmholtz center created a software which allows monitoring online histograms using a QT based GUI.

That software is called Go4. While -- as traditional for all software projects based on ROOT -- it features its own event loop and event processing base classes, it also supports a mode where it simply spawns a TCP server transmitting histograms filled elsewhere to the GUI.

(
I am not known to enthusiastically praise software, but the Go4 Gui is probably what TBrowser wants to grow up to be. Key features include the ability to compose multi-histogram views ad-hoc by selecting multiple histograms and then superimposing them or displaying them side by side. (Using some gentle API hooking, I one can also make the bins of an overview TH2 (displaying the number of events in 1k channels) open a particular channel when clicked. In principle, this could also be done in js, of course.)

As it uses native ROOT GUI primitives, it is rather more intuitively usable for long-term ROOT users (who consider it perfectly normal to right-click on the canvas background instead of an axis to toggle logness).

As the Go4 GUI keeps a local copy of the histograms around, the memory requirements of it are typically higher than jsroot. However, a recent breakthrough in GUI architecture allows forwarding X11 programs over secure shell, so it is perfectly feasible to run the GUI on a beefy server while viewing it on a normal desktop.

I do not propose replacing jsroot, but claim that both jsroot and Go4 come with advantages and disadvantages over the other.
)

We could (optionally) allow linking FairRoot with the relevant parts of Go4. It should not be terribly difficult: in FairRunOnline::AddObject, recursively add the contents of TFolders using TGo4Analysis::AddHistogram()/AddObject while keeping track of the folder path. Put the actual handling of Go4 classes behind some #ifdef GO4.

Would you consider merging a PR doing such a thing?

Cheers,
Philipp

[MohammadAlTurany]

Dear Philipp,

First of all it is nice to see that you like what Denis Bertini and me did 20 years ago (Qt-Interface to ROOT and Go4 GUI). However, as you realise yourself what the Go4 GUI is doing is to give the user a different way of accessing the same functionality in ROOT.
Now to your suggestion about including/integrating Go4/FairRoot I do not think it is possible in a clean way and:

1. Go4 and FairRoot follow a very different concept (In FairRoot we rely on tree entries and Go4 tries to hide the tree from user and deal with histograms directly)
2. Adding a dependancy on FairRoot level will have consequences to all experiments and need to be tested and integrated in all our testing pipelines

That said, I would recommend to implement this dependancy on your experiment code and not on FairRoot level, i.e: you can sub-class the FairRunOnline in your experiment code and add what ever dependancy you like.

Best,

Mohammad

[klenze]

Hi Mohammad,
okay. To implement this cleanly with sub-classing, it would be very helpful if FairRunOnline::AddObject was virtual. (Otherwise, I would have to either replace FairRunOnline::Instance() in all the histogram-generating classes or -- more likely -- override FairRunOnline::AddObject in the dynamic linker using LD_PRELOAD.)
Cheers,
Philipp