e.g.,
It is,
sses
sary
5 as
such
the
Ising
ries.
ond,
ime"
5 the
such
le in
Kes),
id in
al of
ding
ailed
or a
GUI
ul to
tem)
r by
/isor
to it
the
and
nain
user
5 via
the
ing,
the
UX
ser;
ther
'brid
ser.
rver
ation
ning
the
ges,
d by
xDL
L is
specified and created for UX. It has a syntax similar to that
of C++. Semantically, it is kept as far as possible
independent of any current GUI in describing the
functionality requested in abstract terms such as 'Main',
’numVal’, ’analogVal’, 'label', 'stateSwitch', RGB. DIGITAL
etc. There is a series of operators provided for agents to
add or to subtract an element to/from the GUI, to modify it,
to make it accessible/nonaccessible, for inquiry, and so on.
uxDL statements carry detailed specifications for relative
and absolute object positioning, for events to cause
messages to be sent, a string for short help and an entry
in the help database, initial value(s) to be set, etc.
UX builds up a database of these specifications, and it
keeps it up-to-date with regard to agent and user actions.
The part of UX to display the GUI objects on the screen is
doing this via driver-objects dependent on some cross-
platform GUI library - at this point from Zinc Software Inc.
Displayed is a native GUI, i.e. one looking as OSF Motif,
as WINDOWS 95, or as OS/2 etc., depending on the
platform for the version of SCOP (or of some other
application created using XX).
There are two more specifics we would like to mention:
stateSwitches, and commandLine.
StateSwitches are GUI buttons specialized to switch object
states. There goes the saying that constructs not having
states are no objects. There is much truth to this: just
functions do not have states. On the contrary, objects - i.e.
data with corresponding methods (member functions) to
manipulate them - can be, e.g., 'not yet read in', "not yet
displayed', 'displayed' etc. And the functionality inherent in
objects can be configured - 'set up'. With OS/2 and with
WINDOWS 95, GUIs appeared on the market using this
type of user controls (there used to be others earlier,
naturally); they set the standards how to do it, and users
will get used to it: a right mouse click 'opens' the object for
to be set up (i.e. for parameter specification), and different
other actions (carriage return on the active object, left
double mouse click) will ’activate’ the object according to
the current setup specifications. This second action can
switch just two states, and only in one direction: off-to-on.
This shortcomming is still rooting in procedural thinking:
they say they are "running the object" - a contradiction in
itself, not without humour. So we have been forced to
create the ’stateSwitch’, an element doing more than
Tunning the object": it is capable to swith back-and-fort
among object states via keyboard arrows, via pop-up
menue, or via hitting carriage return versus blank "over"
the current stateSwitch; and, naturally, stateSwitches are
capable of opening the object on right mouse-click or as
choice from the pop-up menue.
Shading understood as a large array of pixels (i.e. as data,
as object) yields a good example for switching states. This
complex object is controlled on the screen by a
StateSwitch. A right mouse click at it will open a 'subLevel'
(à window) with parameters for setting up the computation;
in most cases, however, the default setup will suffice, and
therefore, the opening (setup) action will not be needed.
The states allowed for this switch are: OFF, DISPLAYED,
571
FROZEN, EDIT ( OFF and DISPLAYED are self-
explanatory; FROZEN means, that while editing the terrain
data by interactive graphics, the shading should remain
displayed but not re-computed on every change; EDIT
means that pixels of the shading can be interactively
identified and edited).
Concerning the commandLine: it yields the always-present
option of command entries. These are composed of
(shorthands) of the labels written onto/at the different
objects on the screen. To take the above example for
shading, the actions described there could be replaced by
typing
shd, zenDist 30, dsp;//or the similar
This allows for fast and special ways for expert users, for
batch capability, and for writing command procedures.
2.5 Graphics
The graphics component of XX: GX is realizing a subset of
CAD funcionality, and at the same time a superset of it
concerning the special needs of geocoded data. GX can
overlap, edit, and in certain special respects also process
both vector and raster (pixel) type data.
To facilitate fast identification of on-screen objects for
interactive graphics, GX is building up a database of its
own for the addresses and graphical characteristics of
these objects. Otherwise, data are managed by interface
objects - a solution coherent with strict distributed object
technology (see chapter 3). Interface objects are derived
from an abstract interface class specified by GX thus
declaring (and in certain aspects also defining) functionality
as needed by it - such as ‘identify closest to (x,y), ‘data
within area of interest’, 'register/commit alteration by the
user’, etc. To perform such tasks, the interface object can
access, e.g., some database via any network - or, at the
other extreme of the scale, its own separate excerpt from
it. The most primitive examples of such databases are
intermediate (ZWIFT') files; for them, as far as possible,
the methods are written as declared in the abstract GX
interface class. Naturally, based on ZWIFI files this
solution is inefficient and not really capable of any active
graphics functionality. A much more versatile case is some
interface class based on TOPDB tables [Lo91]: here,
manysided selection operations, and efficient identification
are granted, thus allowing for editing the contents of tables
without being forced to duplicate them in another form.
GX has the capability to refresh screen graphics locally,
i.e. to re-draw only those screen regions effected by
changes. This is very important for following in real time
(or at least near-real time) any data editing actions by the
user: re-calculating and updating the currently active
screen contents (e.g. contour lines drawn over hill shading)
should be done only within the area affected by the
change(s). - To solve this, there is much to be done yet in
the (hybrid) SCOP server components.
Beyond interactive graphics, GX is responsible for plotter
and metafile related functionality.
International Archives of Photogrammetry and Remote Sensing. Vol. XXXI, Part B4. Vienna 1996
