Panoramix Qt4 Interactivity integration through Qt Visualization integration

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

On. X / Qt • Panoramix interactivity handled by Open. Scientist / On. X. 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…) • On. X : 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. On. X 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. • On. X today “GUI drivers” are : Xt/Motif, WIN 32, Next. Step, gtk(1 -2) and Qt. G. Barrand / LAL / AA-26 -April-2006

Panoramix / Qt • Panoramix interactivity being on On. X, 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 WIN 32 and Xt/Open. Motif On. X GUI drivers through the Open. Scientist installations put under /afs/cern. ch/sw/contrib. • But it appears that the Qt 3 On. X GUI driver is in fact also used in UK. • Qt 4 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 (coin 3 d over Open. GL). G. Barrand / LAL / AA-26 -April-2006

On. X / Qt 4 • At LAL, we have looked at Qt 4 on the three interactive platforms. This consisted to migrate the On. X/Qt-driver but also the coin 3 d/So. Qt and HEPVis packages over Qt 4 for Mac, Windows, SLC 3. • All the modifications will come in an OSC-16 delivered “for summer”. • On. X/Qt : still use the “Qt 3 support”. The code run over Qt 4 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 Open. Scientist packages : Coin. GL, Coin. Qt, HEPVis, On. X plus some “CMT Interfaces” packages. G. Barrand / LAL / AA-26 -April-2006

On. X / Qt 4 / platforms • Windows : a “hidden” point in the Trolltech “Qt 4 being open source on Windows” announcement was that the binaries are delivered free only for g++ and not Visual. C++. But, thanks to the reactivity of the open source world, some free build procedure can now be found at least on source forge : set CVSROOT=: pserver: anonymous@cvs. sourceforge. net: /cvsroot/qtwin cvs co qt-4 qconfigure msvc • With the upper, the chain Qt 4, Coin. GL, Coin. Qt, HEPVis, On. X/Qt 4 works on Windows-XP with a vc-71. (At head and delivered in some OSC-16 for summer. ) • SLC 3 -g++-3. 2. 3 : the same is ok too. • Mac. OSX-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 Mac. OSX-Tiger, g++-4. 0, Qt 4. G. Barrand / LAL / AA-26 -April-2006

GUI integration through Qt(4) Graphics integration through Open. GL 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

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 now on Qt or have some “Qt-driver” to operate on Qt. G. Barrand / LAL / AA-26 -April-2006

Hippo / On. X / 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 On. X/Qt GUI had been straightforward. • Now try to integrate also the inspector • And…. G. Barrand / LAL / AA-26 -April-2006

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

Hippodraw / Panoramix / integration through Open. GL 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

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 Qt 4) (integrate the TCanvas) • The graphic (then through Open. GL) (integrate the T? ) • Knowing that, with Open. Scientist, Panoramix has already a (nice) solution… • In fact having first the “Open. GL driver” would be the top priority. G. Barrand / LAL / AA-26 -April-2006

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

Geant 4 / 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/G 4 Qt global steering class. • Have some interfaces/G 4 UIQt minimal terminal GUI for handling commands. • Clone the vis/Open. GL and vis/Open. Inventor Motif class that handles “viewers”. • Any volunteer ? (no, as usual). 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

Conclusions I • LHCb has already a « unified » graphics covering the three kinds of scene in a consistent GUI, and this by heavily exploiting (through Open. Scientist) 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. • Qt 4 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 Mac. OSX). • If satisfactory, LHCb could even avoid the On. X 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

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 Qt 4 but also « Higgs integrated » directly through the graphic with Open. GL. • 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

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 Qt 4 based application the TCanvas : have a QTCanvas widget. • Have an Open. GL driver for the 1 D 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 Qt 4 installation for Windows, Linux and Mac. (by passing along, could be fine to have the same done for freetype 2 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 So. Plotter 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

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)). • Py. Qt status versus Qt 4 ? Py. Qt wraps with SIP. pivy (coin 3 d wrapping) uses SWIG (the SWIG-1. 3. 28 is great). Compatibility with LCG/wrapper ? 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