1. G.Barrand / LAL / AA-26-April-2006
Panoramix / Qt(4)
Interactivity integration through Qt. Visualization integration through OpenGL.
G.Barrand / LAL / AA-26-April-2006

2. G.Barrand / LAL / AA-26-April-2006
OnX / Qt
Panoramix interactivity handled by OpenScientist / OnX. See CHEP’04 papers.
We remember that the GUI “problem” had been identified for long ; no GUI standard emerged from “desktop providers” (Apple, Microsoft, KDE, GNOME, etc…)
OnX : describe the GUI with an “home-made” XML and exploit native GUI of desktop providers (for performance reason).
The XML GUI description includes also the “callbacks” that are then scripted. OnX handles in a very clean way multiple GUI toolkits and scripting systems. For scripting, the “DLD” (simple string API to the dynamic loading) and Python ones are used in Panoramix.
OnX today “GUI drivers” are : Xt/Motif, WIN32, NextStep, gtk(1-2) and Qt.
G.Barrand / LAL / AA-26-April-2006

3. G.Barrand / LAL / AA-26-April-2006
Panoramix / Qt
Panoramix interactivity being on OnX, then, in principle all GUI drivers are at hand : the delivery of them in the “final application” is a question of release / installation procedures.
LHCb supports Windows and Linux.
Then in practice, is regularly released the WIN32 and Xt/OpenMotif OnX GUI drivers through the OpenScientist installations put under /afs/cern.ch/sw/contrib.
But it appears that the Qt3 OnX GUI driver is in fact also used in UK.
Qt4 being free on Windows clearly changes the game : at last we have now a good “cross platform” GUI candidate satisfying a lot of criterions including : natively C++, free versions on all today “interactive platforms” and integrating nicely the LHCb graphics (coin3d over OpenGL).
G.Barrand / LAL / AA-26-April-2006

4. G.Barrand / LAL / AA-26-April-2006
OnX / Qt4
At LAL, we have looked at Qt4 on the three interactive platforms. This consisted to migrate the OnX/Qt-driver but also the coin3d/SoQt and HEPVis packages over Qt4 for Mac, Windows, SLC3.
All the modifications will come in an OSC-16 delivered “for summer”.
OnX/Qt : still use the “Qt3 support”. The code run over Qt4 but not yet fully exploiting the new widgets.
It had been needed also to migrate the coin related code to more recent code. This touched the OpenScientist packages : CoinGL, CoinQt, HEPVis, OnX plus some “CMT Interfaces” packages.
G.Barrand / LAL / AA-26-April-2006

5. G.Barrand / LAL / AA-26-April-2006
OnX / Qt4 / platforms
Windows : a “hidden” point in the Trolltech “Qt4 being open source on Windows” announcement was that the binaries are delivered free only for g++ and not VisualC++. But, thanks to the reactivity of the open source world, some free build procedure can now be found at least on source forge :
With the upper, the chain Qt4, CoinGL, CoinQt, HEPVis, OnX/Qt4 works on Windows-XP with a vc-71. (At head and delivered in some OSC-16 for summer.)
SLC3-g : the same is ok too.
MacOSX-Tiger-(10.4.6)-g : the same is ok now too. (End of 2005 had been a pain on Mac due to the arrival at the same moment of major releases of MacOSX-Tiger, g++-4.0, Qt4.
set
cvs co qt-4
qconfigure msvc
G.Barrand / LAL / AA-26-April-2006

6. GUI integration through Qt(4) Graphics integration through OpenGL
G.Barrand / LAL / AA-26-April-2006

7. HEP visualization (and then GUIs)
HEP graphics / interactivity needs to handle three kinds of “scenes” :
Event visualization (experiment specific)
Detector visualization (experiment / HEP specific)
Plotting : histograms, functions, tuples visualization (not experiment / HEP specific)
At the engineering point of view, what needs to be put in place so that someone can manipulate the uppers is the same : a rendering layer, a scene-manager layer, a GUI layer, a viewer layer, a scripting layer.
Panoramix, through OSC, comes now with a solutions for the three kinds of visualizations, but it appears that for the last kind of scene, which is not really experiment or even HEP specific, some dedicated applications / libraries can also be found and people may be glad to have them at hand and, if possible, to have a tight integration of them in a consistent GUI.
An example is hippodraw and ROOT.
G.Barrand / LAL / AA-26-April-2006

8. G.Barrand / LAL / AA-26-April-2006
Example
G.Barrand / LAL / AA-26-April-2006

9. GUI organization paradigm
Having a GUI toolkit is fine, but not sufficient ; someone needs a GUI paradigm to organize things.
“Flying around windows” paradigm : bof. Within LHCb, it had been demonstrated that from a Python shell, someone can : create some Panoramix-GUI panel to visualize an event or a piece of detector, spawn hippodraw that will create then its own GUI “shell” windows driven with its own logic and even create some ROOT/TCanvas coming then also in its own “shell window” and with its own logic. OK, FINE. But do we really want that ? No : at the end we pass time to “hunt windows” on a crowded desktop and fight with piece of GUIs having heterogeneous logics : a pain.
Panoramix GUI done by using the document paradigm found in a lot of applications now and in particular in the various familiar “office applications”.
Having a common GUI backend clearly permits to do that and a lot of software are now on Qt or have some “Qt-driver” to operate on Qt.
G.Barrand / LAL / AA-26-April-2006

10. Hippo / OnX / integration through Qt
Hippodraw GUI is Qt.
Due to the good coarse graining design of hippodraw, the integration of the hippo Qt canvas within a OnX/Qt GUI had been straightforward.
Now try to integrate also the inspector
And….
G.Barrand / LAL / AA-26-April-2006

11. Hippo / OnX / integration through OpenGL
Hippodraw graphic is done with Qt
but due to a good coarse graining design of hippodraw, it had been easy to have an
OpenGL driver of its graphic (LAL contribution).
G.Barrand / LAL / AA-26-April-2006

12. Hippodraw / Panoramix / integration through OpenGL or Qt
Mainly a question of release synchronisation scheduling « of everything »
Could be delivered before the start up.
G.Barrand / LAL / AA-26-April-2006

13. G.Barrand / LAL / AA-26-April-2006
Panoramix / ROOT
I WANT TO BE ABLE TO DO THE SAME WITH ROOT.
Be able to integrate the plotting at the level of :
The GUI (then through Qt4) (integrate the TCanvas)
The graphic (then through OpenGL) (integrate the T?)
Knowing that, with OpenScientist, Panoramix has already a (nice)
solution…
In fact having first the “OpenGL driver” would be the top priority.
G.Barrand / LAL / AA-26-April-2006

14. G.Barrand / LAL / AA-26-April-2006
Panoramix / SoPlotter
(Sorry people, but with ROOT, I can’t do that…)
G.Barrand / LAL / AA-26-April-2006

15. G.Barrand / LAL / AA-26-April-2006
Geant4 / Qt
There is definitely now user interest in having Qt “drivers for the
visualization”…
In principle nothing prevent to do it ; the whole structure (build
system, interfaces and visualization categories organization) is ready
for it.
Job consists mainly in cloning what had been done for Motif :
Having some interfaces/G4Qt global steering class.
Have some interfaces/G4UIQt minimal terminal GUI for handling commands.
Clone the vis/OpenGL and vis/OpenInventor Motif class that handles “viewers”.
Any volunteer ? (no, as usual).
G.Barrand / LAL / AA-26-April-2006

16. G.Barrand / LAL / AA-26-April-2006
Online / Qt
PVSS is going to be on Qt (right ?)
A Panoramix/Qt (with event, detector, plot scenes) would be then
embeddable in this environment ; which would be great ! (A lot of
things could be explored here…)
G.Barrand / LAL / AA-26-April-2006

17. G.Barrand / LAL / AA-26-April-2006
Conclusions I
LHCb has already a « unified » graphics covering the three
kinds of scene in a consistent GUI, and this by heavily
exploiting (through OpenScientist) the open source world resources
(which minimize the home made developments).
The « plotting scene » not yet exploited, probably due to the strong
psychological « idée reçue » that only one software in the world
can plot histogram.
Qt4 is the best GUI candidate that, at last, emerged. LHCb has to
consider this « thread » seriously. It could be put in place before the
end of the year for Windows and Linux (and MacOSX).
If satisfactory, LHCb could even avoid the OnX package
which would aleviate the LAL engineering task (for LHCb) and do
everything by using the python wrapping for Qt and Inventor.
G.Barrand / LAL / AA-26-April-2006

18. G.Barrand / LAL / AA-26-April-2006
Conclusions II
« weak integration » through a python shell of hippodraw and ROOT
in a Gaudi context already demonstrated.
With some reachable efforts, LHCb could have hippodraw « strongly
integrated » within Panoramix through the GUI with Qt4 but also
« Higgs integrated » directly through the graphic with OpenGL.
This had been possible because hippodraw is not some kind of
quantum entanglement of everything ; then because it has a good
coarse graining architecture.
The delivering to the users is more now a synchronisation release
question which is more in the hand of the « infrastructure » then in
LCG/SPI. This could be done before the start up.
G.Barrand / LAL / AA-26-April-2006

19. G.Barrand / LAL / AA-26-April-2006
Conclusions IV
Concerning ROOT, engineering requests are :
Be able to integrate the plotting in applications for which the GUI is not based
over the TGUI classes.
Be able to integrate in a Qt4 based application the TCanvas : have a QTCanvas widget.
Have an OpenGL driver for the 1D plotting and in fact for the whole ROOT
graphics (which would permit integration at the level of the graphics (and not
only at the level of the GUI)).
Have all that coming with regular releases of ROOT.
Within the LCG release area, have all that delivered over a common Qt4
installation for Windows, Linux and Mac. (by passing along, could be fine to have the
same done for freetype2 and CINT).
Is the organization of ROOT ready for that ? (It is long now that I have made my
mind on that…).
Developments around the SoPlotter will continue… (because, in fact the
real problem in HEP graphics is here). (and mainly because I have no illusions on
what is going to be done by CERN/LCG/ROOT in the upper list).
G.Barrand / LAL / AA-26-April-2006

20. G.Barrand / LAL / AA-26-April-2006
Conclusions V
Nothing had been said about the python wrapping of all that.
And there are issues here, especially knowing that, for example, the
LCG reinvention of a C++ / Python wrapper is unable to treat
properly the Inventor API (in fact CINT can’t do it too (strange)).
PyQt status versus Qt4 ? PyQt wraps with SIP.
pivy (coin3d wrapping) uses SWIG (the SWIG is great).
Compatibility with LCG/wrapper ?
G.Barrand / LAL / AA-26-April-2006

21. G.Barrand / LAL / AA-26-April-2006
Meta-conclusions
Apple-Jobs and Micro-Gates are not on Qt…
Which means that the GUI story is not finished and due to the long
life time of experiments, people must arrange things in order to be
able to move on that point (then be able to discard today GUI solution
to move on something else if needed).
G.Barrand / LAL / AA-26-April-2006