1. Evolution of GUI approach, the research and commercial paradigms by V.Fine

2. 2 What is GUI A graphical user interface (or GUI) is a method of interacting with a computer through a metaphor of direct manipulation of graphical images and widgets in addition to text. The user of the computer utilizes a pointing device, like a mouse, to manipulate these images and widgets. This is considerably different from the command line interface (CLI) in which the user types a series of text commands to the computer (Wikipedia)interacting with a computer metaphordirect manipulationwidgetspointing device command line interface

3. 3 GUI vs “Visualization” Visualization is the graphical representation of the some data. Even though GUI is a special visualization, it is the graphical language between human and computer. (For example OpenGL is a powerful visualization tool, however it is not suitable to create the “regular” GUI)

4. 4 “Intuitive” GUI They say to be success the good GUI has to be “intuitive”. What does this mean? “Intuitive’ means the GUI user should be able to predict the program response without reading the code documentation, based on his/her intuition. In other word based on the past experience.

5. 5 GUI and HENP research. Event tough there is a strong need to introduce new ideas and methods, and the good portion of computational force (and price) of the modern computer, first of all, the so- called Desktop PC, belongs its sophisticated video card with advanced 2D/3D accelerators. this vast power did not play any major role in the High Energy Physics research due lack of the software, that can be feed by the HEP data.

6. 6 First GUI Doug Engelbart's Augmentation of Human Intellect project at SRI in the 1960s developed the On-Line System (NLS), which incorporated a mouse-driven cursor and multiple windows. Engelbart had been inspired, in part, by the memex desk based information machine suggested by Vannevar Bush in 1945. Much of the early research was based on how young humans learn. (see: http://wikipedia.org )Doug EngelbartAugmentation of Human IntellectSRI1960sOn-Line Systemmemex Vannevar Bushhttp://wikipedia.org

7. 7 NLS GUI demo (1968) Many of the things demonstrated in this marathon session seemed to come from decades in the future, and most of the people watching it were hard pressed to even understand all of what they were seeing. The demo featured hypertext linking, full-screen document editing, context-sensitive help, networked document collaboration, e-mail, instant messenging, even video conferencing!

8. 8 NLS GUI demo 1968 (cont) See: http://arstechnica.com/articles/paedia/gui.arshttp://arstechnica.com/articles/paedia/gui.ars

9. 9 GUI timeline Just before the end of the 1980s, new GUIs started appearing on Unix workstations manufactured by AT&T and Sun (Open Look) and DEC and HP (Motif Open Software Foundation or OSF). These ran on top of a networked windowing architecture known as X, which would later be the foundation for GUIs on Linux. CERNLIB port to 32-bit MS DOS with gcc CERNLIB port to Linux Windows NT End of the mainframe / workstation epoch

10. 10 PC approach –> cheap GUI No time sharing, no multitasking No terminal No special graphical output hardware command No speed problem No I/O  Leave the programmer brains free to think about the final user

11. 11 Mainframe and workstation (X11, network) environment GUI applications are expansive proprietary applications Dedicate proprietary GUI library – expansive license + expansive “run-time license”. The software commercial company life time – shorter the HENP application life cycle. Needs a special expansive graphical station (for mainframe) All above made the graphical application for HENP leave alone wide use of the GUI, quite expansive and rare use outside of some advanced computer center (like CERN) At the time GUI was a small portion of the total price tag the end user paid for the graphical hardware and application software. The HENP problems above did not bother much the mainframes workstations producers yet.`

12. 12 Batch and interactive stages GUI is not the first concern of the HENP frameworks. We worry whether we are capable to collect, preserve, re-distribute our hard- earned TBytes. However the final stages of the job are mainly interactive. The very first steps of the data-taking in the “control rooms” are interactive also In addition, the production code debugging is the interactive process too.

13. 13 Operating system “model” for HENP cross-platform applications “pro” It is not unusual when the life cycle of the major HENP applications last for dozens years. In other words it is much more then the life cycle of any known “system components” like operating system, file system, GUI etc. and hardware as well. To survive the sophisticated and expansive research applications must be in possession of some (tiny) layer to separate the HENP applications and the concrete system environment evolvement. It is possible by introducing some sort of the “virtual operating system model” the applications rely on; and providing the implementation of that model as soon as operating environment evolves.

14. 14 Even though it does allow to prolong the life cycle of the software package that comes for the price. One is still required to learn and maintain the specific pieces of the code for many different platforms, and the different versions of one and the same platform for the entire application life. Sometimes the magnitude of this task entails the narrowing the number of different platforms the package is available for. On the other hand many features one has to deal with are not application specific. This implies that the good layer can be ''borrowed'' from some third party dedicated packages and make people free from the wheel re-inventing (at least in theory) Operating system “model” for HENP cross-platform applications “cons”

15. 15 GUI vs Command mode GUI leaves no trace. It hard to formalize and transfer the knowledge how some result that required the complex “human-computer” interactions via GUI was achieved. Solution - “scripting”, “auto-scripting”,”event logging” - still no generic solution yet. Often abused as a cheap and quick replacement for the normal GUI design and build process. Side effect of the mismatch between the scripting language and the package “main” language – it requires an extra translation (all but ROOT)

16. 16 GUI timeline Just before the end of the 1980s, new GUIs started appearing on Unix workstations manufactured by AT&T and Sun (Open Look) and DEC and HP (Motif Open Software Foundation or OSF). These ran on top of a networked windowing architecture known as X, which would later be the foundation for GUIs on Linux. CERNLIB port to 32-bit MS DOS with gcc CERNLIB port to Linux Windows NT End of the mainframe / workstation epoch SunMicrosystem started JAVA TrollTech released Qt OO GUI library Rene Brun started ROOT

17. 17 Linux + 32-bit Intel CPU + OO + “g++”=> generic free cross GUI high quality toolkits Free Unix on the cheap Intel platform = desktop on UNIX platform niche Linux was looked “plain” vs “well-dressed” MS Windows. “Unix Server” market was limited and pre- occupied by m,ore poweful at the time “worskstations” “Street consumer” has unlimited capacity. It took next 10 year (1995-2005) for technology to become mature and match HEPN application demands.

18. 18 Toward affordable GUI Event though the GUI designing and coding remains the extremely man-power consuming software to work out, the free (Open) source busyness models widely adopted by many IT companies made the expansive GUI toolkit libraries and GUI applications affordable (free in fact) for large scale research (HENP) collaborations.

19. 19 How to choose from ? The review http://www.geocities.com/SiliconValley/Vista/7184/guitool.html of the more then 100 different GUI packages : http://www.geocities.com/SiliconValley/Vista/7184/guitool.html

20. 20 How to choose from ( gnomes vs trolls ) One needs: Cross platforms Documentation Open Source (including Win32) The “native” development tool integration “Native” GUI (Win32, Mac) integration Free (GPL’ed) Interactive GUI “builder” Object-Oriented Support the signal/slot paradigm Intuitive Support “localization” Rich set of the available GUI widget libraries and the related functions Migration tools (optional, we have very few applications to migrate): Microsoft Foundation classes migration Motif migration

21. 21 “Intuitive” GUI (again :) We said to be success the good GUI has to be “intuitive”. What does this mean? “Intuitive’ means the GUI user should be able to predict the program response without reading the code documentation, based on his/her intuition. In other word based on the past experience. However the different users have the different past experiences.

22. 22 “Perfect” GUI components ? NextStep “perfect menu” NextStep “perfect scrollbar” See more accolades: http://www120.pair.com/mccarthy/nextstephttp://www120.pair.com/mccarthy/nextstep

23. 23 The complex research applications need too many things at once., and combination the code from the may separate component is quite fragile” It needs the special technique and approaches. Very often it is more simple to create and maintain the consistent system that contains and owns all necessary things built-in (see Rene Brun presentation) All components have to be available for all members of the collaboration for all platforms.

24. 24 Classical GUI component Scrollbar Drop down menu Menu Spin box Combo box List box Slider

25. 25 Winners At the moment it is safe to claim there are at least two commercial toolkits those satisfy all requirements mentioned above: Java Sun Microsystem Qt from TrollTech to be successfully used by research application. However, the C++ nature of the current HENP applications (see Rene’s talk) singles out the Qt.

26. 26 Approaching Qt Qt “outside” - GO4 approach (GSI) Qt “just inside” - Acat2002 (BNL) Qt “side by side” - Qt CINT approach (Masa Goto) Qt “deep inside” - ACAT2004 (BNL) Goals: Immediate man-power conservation – “experiment target” Insure the package long healthy life (25 years?) – “developer target”

27. 27 Conclusion There are enough evidences The quality, price (free) and scale of the modern object-oriented commercial GUI toolkits do allow using it effectively to create the interactive HEPN offline production and online applications Development of the new approaches to implement the intermediate abstract layer to separate the research application and concrete GUI should open unrestricted access to a rich set of ready-to-use commercial GUI componet. X11 protocol developed and optimized with  remote client / server  Slow network  Doom terminal is going to be replaced by Web-like client / server model based on some sort of the “active components” (Java-script, Macromedia Flush ?). We should see more and more the script-based Web-application powered by Java-like scripts. (reviving the idea of the Postscript terminal).

28. 28 Conclusion (cont) As result the people involved in the research software development and support will spend less of their precision time and talent re-inventing the wheel rather devote it to resolve the genuine research problems and task. To make it happens one has to think today how to choose and effectively accommodate the coming commercial solution.

29. 29 Questions ?

30. 30