The main objective of roottalk is to have discussions on issues that may impact the medium and long term evolution of ROOT, rather than submitting bug reports that should be submitted to root-bugs@root.cern.ch. The current discussion on GUIs is important. In this context, I would like to express my own views. First, some bits of history. When we started the development of ROOT in 1995, we worked on the command line & script interface and we converged towards a common platform-neutral pad-graphics via TVirtualPad. Shortly after, we implemented a first GUI (pad-oriented) with quite primitive interfaces like TButton, TDialogCanvas. The "Screen" graphics was via a mini abstraction called TGXW (that became later TVirtualX). TGXW was developed mainly for the needs of the pad graphics. Many functions for implementing a GUI were missing in this first abstract interface. We had unfortunately two divergent implementations starting to appear for a GUI: one on Unix, the other one on Windows. Valery Fine worked very hard to port ROOT versions 0.xx, then 1.xx to Windows via the Win32 interface. Valery was a Windows expert and a Windows enthusiast. We had conflicting views on the way to proceed. Valery was of the opinion that one should not reinvent the wheel under Windows. He was in favour of using the native MS browser, dialogs, etc, with high level interfaces to the MS utilities as the expense og having a different look&feel on all platforms. Myself and Fons were convinced, at the contrary, that a low level interface was more important. I would like to explain why. High level interfaces seem obviously attractive at a first glance. You can save a lot of coding, reuse ideas and classes, etc. If your problem is a short term problem and you must make money next week (P.Lippa's case), you have no other choice than to use this high level interfaces. I want to make very clear that our objective is to develop a system with a chance to survive, say at least 10 or 15 years. We have achieved this goal in the past with our previous products, eg Geant3 and PAW. When you have such objectives, you know very well, by experience, than you will have to adapt your software to new developments (hopefully!) in many areas: languages, graphics layers, GUIs, OS, etc. When we started the development of PAW in 1985, I was told that the graphics interface should be provided by GKS. GKS was becoming a de facto international standard and it was out of question to implement our own interface. We had to suffer from this dictat imposed by some bureaucrats who like to seat in committees all their life. In fact, GKS was mainly a European standard. Another standard (the CORE system) had also been developed in the US, but rapidly losing ground because a new technology with workstations, bitmap graphics and X11 was just emerging. We were couragous enough to resist to the standardisation dictat and came with the HIGZ layer in PAW that made PAW really portable on many platforms. At the end, it was far much less work to implement this low-level layer than continuously adapt PAW to several high level interfaces. I could also mention all the saga with MOTIF. This one also was supposed to be the solution for ever! The same history is happening with ROOT. First of all, when we started, systems like Qt, Swing, etc, did not exist. In 1997, many people thought that the way to go was to use Java,Swing for the GUI. If you look 4 years later, the penetration of Java in HEP is very marginal despite all the sex-appeal of the Web. It would be interesting to analyze why. There is now a broad consensus that Java-based applications are slow. Have you ever seen a convincing GUI based on Swing? The recent decisions by Microsoft to kill Java and banish it from Windows in favour of their new "great idea" (C#, .NET,SOAP, etc) may well succeed. It will be, yet, another standard to support. Qt is clearly more interesting and a large effort by very good people is invested in this line. We cannot ignore this. That is why we see with interest initiatives like at GSI (thanks Denis Bertini). If Qt was to become an "X11-like" system providing a common interface to GUI and graphics (a super X11), it would be obvious that ROOT should provide a solid Qt interface. It is too early to say so. There are alternatives to Qt. What we can do now is to make sure that if you choose to use Qt as a GUI, you can embed the ROOT canvases/pad in your GUI. This option must be consolidated. Now, let me come to the question of the current efforts with the ROOt GUI under Windows. As already discussed many times, you know that Bertrand Bellenot from Alcan Switzerland is working on this topic since a few months. It is very disappointing, to say the least, to read some comments on his work. I hope that his impulse will not be affected by what I consider very unfair appreciations. Bertrand is doing a GREAT WORK. There are still several technical difficulties that must be addressed: performance and threads. We are perfectly aware of the problems with threads under Windows and these problems typically require the assistance of windows gurus. As pointed out by Brett, we are not the only ones to face these kind of problems. We are currently discussing what is the best way to help Bertrand to complete his work. Remember that when discussing GUIs and graphics, we should not discuss only GUIs on a local screen. There are many more issues involved. - First, as mentionned by Fons, even if Qt was adopted as a standard, one still has to develop the high level interfaces ROOT-aware such as objects browsers, treeViewers, etc. - Graphics is not only graphics on the screen. You may want to run with no GUI in batch mode and still produce PS (or the emerging SVG) files. - Graphics is not only 2-d graphics. When dealing with 3-D, there are also other considerations to be taken into account. - GUis and graphics can be used in a client-server mode (was the success and simplicity of the X11 approach). Now, Some dreams, may be ? A project like ROOT cannot be developed without an ambitious and motivating goal. We are comitted to develop and maintain the best possible data analysis, data access, data visualisation environment. Our objective is not short term. I continue to think that our approach with TVirtualX is correct. This will make sure than when system XX fashionable today will be gone, than we can continue to work, possibly adapting our system to cooperate with the new systems YY or ZZ. I personaly see the development of ROOT GUI/Graphics in the following context. We must be able to operate in a network environment. Many people run the server thousands of kilometers away from their laptop. X11 is difficult to use in these conditions and it does not exist on Windows (except slow emulations). We have all the machinery in ROOT to transport in a very compact and efficient way complex objects. We also have all the dialogs (via sockets, etc) to dialog between N bodies. We must be able to exploit this to provide a better (and portable) environment. If we had such a tool, one could run real distributed applications independently of the OS. The existing GUI should be rationalized. I agree with the request by Brett and George that one should be able to produce, eg, a high resolution Postscript (SVG) file from your entire canvas, including the GUI. One should be able to automatically generate the code corresponding to your screen layout. All this machinery is already at the TVirtualPad level or in most non-GUI ROOt objects via TObject::SavePrimitive. We should develop a coherent abstract interface (extented TVirtualPad) involving also 3-d graphics. It is mainly a matter of getting one or two full time people working with us to achieve this ambitious goal. I have good hopes that this will happen. Rene Brun
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:05 MET