Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Our target desktop processors will be x86 CPUs running RedHat linux, with the GTK window system (see Details). The executables may be housed on either AFS or NFS filesystems (see Filesystem). Each user (including control room heads) additionally requires their own configuration file area - the precise configuration seen by each head may be unique therefore. This is a feature of XAL and the other desktop technologies we'll use. That configuration file area will be NFS because a long-lived executable (>25hrs - the AFS token lifetime) must be able to write to it at any time.

...

XAL (that is JFC/Swing) and SWT/Jface applications may be used on any X11 equipped workstation (Windows PC, Solaris) with some performance degradation since because JFC/Swing performs poorly over X11 (even in Java >=1.4). These apps could be run "natively" on Windows (since Swing is pure Java, which is platform independent, and any SWT components could be delivered for Windows too, but the added complexity of synchronizing filesystem resources between the Unix filesystem and the Windows filesystem probably makes this option undesirable - see Redflags. Hence, Proposal: no native Windows apps, Windows use only over X.

Overall User Interface

Use Case: A user (physicst or operator) types the name of the main application, say "lips" ("LCLS integrated physics environment" so we can use a word in this doc) at a Linux console. A GUI based application launches. This application can launch any EPICS display (DM, dm2k etc), any XAL application, the SCP (on MCC), or any EPICS extension application like archive browser, alarm handler watchdog, stripchart, cmlog browser etc. These are launched on the correct host for that application or display. The "local" messages generated by each application appear in a console window dedicated to that application - "global" messages appear in the jcmlog browser window. (This functionality has already been developed - see figure 1.)

...

Figure 1 shows a screenshot of representative user applications for LCLS (a larger version of this picture is here). The main application shown is a minimally modified Eclipse Rich Client (that is, basically Eclipse out of the box) in the Resource Perspective, where the Eclipse Workspace has been configured to launch various kinds of program. A number of execution modes are represented (in-process, out-of-process, using Swing and SWT GUI frameworks, plus EPICS display technologies).

Kinds of Eclipse launch modes used by "Lips":

  1. Eclipse external launching (EPICS displays, archive viewer, and MCC SCP are shown launched, but many are available: eg matlab, xterms, DECterms on MCC, Elog, Physics Log).
  2. Eclipse launching external java SWT/Jface application (jcmlog shown in bottom right)
  3. Eclipse launching internal java SWT/Jface (same VM) application (aida probe shown bottom right)
  4. Eclipse launching external java JFC/Swing (XAL) application (NOT SHOWN YET)

Note that a list of common EPICS displays is directly accessible from the project window on the LHS. In fact any display can be added or deleted from the list trrivially - the list is kept in each user's Workspace config.

Graphical User Interface

...

Frameworks.

In addition to XAL will provide the overall lattice modeling framework , and interface to device control, and XAL provides one GUI framework (based on JFC/Swing). All the existing XAL applications can using thise framework will be provided through "lips" such, such as Scan ("Correlation Plots"), SCORE ("configs"), XIO ("z-plots"), or just the XAL root application.

...

Additionally applications may be written which leverage the Eclipse Rich Client Platform, in which case they run in-process and in the same VM as Eclipse. A trivial example shown is the Aida probe shown in bottom left, which was started from the "Controls" menu. Such applications may be expected to run with better performing use interfaces (though there is some controversy over this point in the literature) and have native look and feel (as opposed to JFC/Swing apps that always have the Swing look and feel of the operating platform).

See also Application Framework Architecture

...