Received: from D0SFB.FNAL.GOV by d0sgi3.fnal.gov via SMTP (951211.SGI.8.6.12.PATCH1042/940406.SGI)
	for <lueking@d0sgi3.fnal.gov> id IAA09590; Fri, 12 Jul 1996 08:44:36 -0500
Date: Fri, 12 Jul 1996 8:44:33 -0500 (CDT)
From: "Oh drat these computers! They're so naughty and complicated I could just pinch them. (Marvin the Martian)" <LUEKING@D0SF24>
To: lueking
Message-Id: <960712084433.2180061b@D0SF24.FNAL.GOV>
Subject: Thoughts on the D0 GUI from the viewpoint of the event graphics

From:	UAZHEP::SHUPE        11-JUL-1996 20:54:37.84
To:	@GUI.DIS
CC:	
Subj:	Thoughts on the D0 GUI from the viewpoint of the event graphics


                                                        July 11, 1996

Dear fellow GUI subgroup members,

I was on vacation in the Bahamas when the GUI subgroup formed and had
its first meeting, so I will try to play catch-up a bit and offer my
thoughts on some of the issues pertaining to Run II graphics.  The graphics
thin layer package, GRAF, currently calls OpenGL, GL, and X11 (and soon
NT graphics) to do its graphical operations.  In OpenGL and GL it makes
use of the full 3d power of these languages.  In X11 and NT it offers 
best approximations to the fancier graphics effects.  Currently, the
working output formats are Postscript and HPGL, and others, such as VRML
and Autocad DXF are under development.  

As provided by vendors, these commercial screen graphics languages are
provided with Fortran and C entry points.  GRAF is written in Fortran, though
C callable entries could be made available if there is a need.  So far there
is no great push in the direction of C++ in the space of commercial languages,
though it is beginning to appear, and I believe is used internally in the
new Direct-X protocol appearing this year in the "internal" graphics driver
space of PC's.  In any case, the PC journals keep characterizing OpenGL as the
best route to platform independent 3D graphics, and this is why the graphics
group went with this standard.

GRAF is cleanly partitioned, so that drawing and attribute (color, style,...)
routines are separate from transformation routines, which (except for the
final device transformation) are in turn separate from the windowing routines.
This latter separation is encouraged by the OpenGL standard, which is not
committed to any particular windowing system. 

However, this disconnect between a graphics language and the window system 
creates a funny situation when it comes to the user interface.  SGI GL (full
3D graphics, just like OpenGL) and X11 (2D graphics library), both include
full specifications for interaction with the keyboard and mouse.  Event
handling is a bit different in the two systems.  GL and X11 both have event
queues for these devices which may be polled, but one often finds in
X11 Motif programs that events are handled by callback to handler routines
for each type of event.  OpenGL doesn't have any event handling routines
in its specification.  For example, when using OpenGL in a multi-windows
Motif environment, we pick currently pick up the GLUT library from SGI (which 
operates on MANY platforms).  GLUT has a standard Motif style callback
structure, which means that it has a BACKGROUND LOOP!  So if other frame
facilities we are considering also have callback structures of their own,
then it seems to me that we could easily find ourselves in the battle of the
background loops.  [Surely this problem is more general than the issue of
graphics.  Has anyone else run into this problem of competing main programs?
Is there a clever solution?]

The current "solution" to this potential background loop problem is to cut
the background loop in the GLUT main routine and turn it into a routine which
gets polled for events (triggering callbacks).  So all versions of GRAF 
(OpenGL, GL, and X11) currently have polled event queues which should be
compatible with any frame, even if it has a background loop of its own.  Of
course a better solution would be to somehow handle all events with a unified 
scheme.

Leaving the issue of event handling, we could ask what graphics manipulators
GRAF currently uses and which ones might be handy if they were available.
In order have all the interactive options which are available in a system
such as the Aleph DALI displays, one needs a tight connection between the
graphics viewer and the mouse.  By "graphics viewer" I mean something like
a scientific visualization frame or VRML browser which has easy viewpoint,
lighting, color, and other attribute manipulation.  If there are menus and
manipulators (sliders, dials, rotors, etc) available in the frame GUI, then
it is convenient to work with these as the mouse interface.  Aleph DALI
does not use any such manipulators.  It has a number of viewpoint and 
selection manipulations interfaced by directly detecting cursor motion and
mouse button states.  Actions are selected by typed command (one or two
character).  This command interface is difficult to learn and use, but once
the actions are invoked, the mouse manipulations are elegant and powerful.

In the current GRAF package, the attempt is to keep the best of two worlds
by realizing all the mouse manipulation features available in Aleph DALI,
while providing a command interface consisting of main menus and popup menus.
Presently, the menus themselves, shaded buttons and all, are drawn by 
menu routines which are themselves other GRAF routines.  But again, this
has been done in a modular fashion so that the whole menu interface could
be replaced by the new D0 frame GUI.  Likewise, some of the motion
manipulations which are currently controlled Aleph-style by cursor position
and mouse button states could be replaced by sliders, rotors, and other 
manipulators of the frame GUI.  But some operations, such as "grab" motions
or "rubber banding", have no manipulator equivalent, and we will always
need to be able to read mouse, and conceivably keyboard, events directly
from the GRAF routines to preserve interactive capability.

So I am asking my fellow subgroup members to keep several things in mind
while shopping through the several frame GUI's under consideration.  At the
very least:

  (1)  What is the event handling structure, and how might it complement or
       collide with event handling in the graphics sector?

  (2)  What is available in the way of manipulators which might be useful
       for viewpoint and attribute manipulation?

  (3)  Can a tight connection be allowed between mouse and keyboard actions
       and the graphics routines which need the information "instantly"?     

There are two extreme program configurations we might keep in mind which help 
clarify these issues:

  I.  The "tightly coupled" representation:  The graphics routines have all
      event handling piped through the frame GUI.  No features intrinsic
      to the commercial graphics language are utilized to pass mouse or
      keyboard information.

  II.  The "uncoupled" representation:  When the frame GUI detects that the
      user wants to view an event, it passes all mouse and keyboard control
      to the graphics viewer routine.  When the user is finished viewing
      the event, control is passed back to the frame.  The graphics routines
      themselves are responsible for all graphics manipulators.

It may be that the optimal solution lies somewhere between these two extremes.
Creative thinking is needed here!

                                            Cheers,

                                                Mike Shupe