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

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

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

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

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++-3.2.3 : the same is ok too. MacOSX-Tiger-(10.4.6)-g++-4.0 : 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 CVSROOT=:pserver:anonymous@cvs.sourceforge.net:/cvsroot/qtwin cvs co qt-4 qconfigure msvc G.Barrand / LAL / AA-26-April-2006

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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-1.3.28 is great). Compatibility with LCG/wrapper ? G.Barrand / LAL / AA-26-April-2006

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