Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/std_unix/volume.31/text0024.txt

Text File | 1993-07-15 | 9.9 KB | 241 lines

Submitted-by: [e-mail] (Scott E. Preece)

         Towards a Uniform API for GUI Programming

Four years ago the IEEE began an effort to produce a
standard GUI API based on X.  After about 30 months of
debate over whether the result should be OPEN LOOK or
OSF/Motif, working group P1201.1 changed course, its new
mission to write a standard for a multi-GUI API, an API that
would be implementable on top of a wide range of GUI bases.
The API must be independent of the look and feel of the
delivered interface, yet must support a wide range of
interface functionality.

P1201.1 has gotten technical input from the authors of a
wide range of multi-GUI toolkits and UIMS systems.  The
group has focused its work on developing a programming
language independent model of GUI programming, on which
language specific bindings will be based.  The model
abstracts core elements of the computational model of
several existing multi-GUI toolkits, including XVT, Galaxy,
and THINGS, expressed in an object-based computational model
similar to the programming style of the Xview toolkit.
Interface components are modeled by objects manipulated by
simple object management services (create, destroy, get-
attribute, set-attribute).  The user interface is event-
driven; events are directed to event handlers associated
with each object.

P1201.1 has recently released Draft 7 of its document in
progress.  This draft is the first to present the bones of
the entire model (though some areas have only a little flesh
covering the bones).  At the next IEEE POSIX meeting (19-23
April in Irvine, CA) the group will review the entire
document and work on the details of several key areas and
will also begin serious consideration of the C language
binding.

At this point the group is looking for an expanded core of
interested parties to validate our model and to contribute
to the completion of the standard.  IEEE standards are
supposed to represent a consensus of opinion of a reasonable
slice of the industry; the current working group is diverse,
but small.  We invite the participation of new members; this
meeting would be an especially useful time to join in, as we
will be reviewing the whole document to figure out writing
assignments for completing the language-independent
specification and will be making decisions about the form of
the C API.

We would especially appreciate participation of vendors,
implementors, and users of multi-GUI toolkits, who could
apply their experience to identifying problems or gaps in
our model.

The meeting is 19-23 April 1993 and will be held at the
Irvine Marriott Hotel, in Irvine, CA.  The room rate for
this meeting is $88, single occupancy, if reserved before 26
March (the hotel telephone number is 714-553-0100, specify
the IEEE P1003 meeting).

Although IEEE TCOS meetings are open to all, they are not
free.  The IEEE charges $200 ($230 with four days lunches
included) to attend TCOS meetings.  To get a registration
form, call Brenda Williams at the IEEE Computer Society
(telephone [phone]); she can also provide forms for
subscribing to the mailing service that distributes work
group documents.

I am the Chair of P1201.1.  I would be happy to try to
answer questions about the meetings and to provide copies of
the current draft to those who plan to participate or who
would like to review it and comment electronically.

If you do decide to come to the meeting, please let me know
(preferably by e-mail), so I can track copying and space
requirements.

           Scott Preece
           Motorola Computer Group
           1101 E. University Avenue,
           Urbana, IL   61801

           Internet e-mail:  [e-mail]
           Telephone:        [phone]
           Fax:              217-384-8550


The remainder of this posting is a low-resolution overview
of our computational model.

===========================================================

    The P1201.1 Uniform API for GUI Programming

The Uniform API (UAPI) defines a set of services for defining
an application's user interface.  An interface programmed to
the UAPI sufficiently abstract that it can be mapped into any
of a wide range of native window systems.

The UAPI remains abstract by limiting the application's
ability to specify low-level visual details and by allowing
the application to use opaque representations of primitives
obtained, by the implementation, from the native window
system.

This model defers many decisions about placement, visual
representation, and other aspects of the user interface to
the implementation, which must support the UAPI primitives
in a way appropriate to the native window system.  In
principle, the application uses the UAPI primitives to say
what interactions are possible between the user and the
application, without saying very much about how those
interactions are implemented or what they look like to the
user.

Application Model > The UAPI presents an event-driven model
of interaction between the application code and the user
interface.

The UAPI toolkit reacts to user actions by calling
application-provided event handler routines corresponding to
the individual actions each visual object supports.  Each
user action represented in the UAPI model has a
corresponding event.

When the application instantiates a window or control, it
can provide handlers for any events that object supports.

The UAPI implementation provides an event loop, to which the
application hands control after constructing the needed
objects and handlers and setting up any required initial
state.  The event loop waits for user actions (or
notifications from time or data driven application
components) and dispatches them to the appropriate event
handlers.

Objects and Attributes > An application defines its interface
in terms of objects that appear on the user's display.  Each
object belongs to an object class that defines what the
behavior of the object is and what internal state it
contains.

Most interaction between objects in the UAPI or between the
application and the objects defining its user interface
occurs through the manipulation of attributes of the object.
All objects of a given class contain the same attributes.
The toolkit provides operations to get or set the value of
each attribute.

     Some attributes represent the object's stored data;
     setting such an attribute determines the value which
     will be retrieved by subsequently getting the value of
     the same attribute.

     Some attributes represent structural information about
     the object, provided by the toolkit; setting the value
     of such an attribute may not be allowed or may have
     side effects beyond changing the value.

     Some attributes are handles through which the
     application can determine the behavior of the object;
     setting such an attribute has side effects which may
     not be directly reflected in the value retrieved by
     getting the value of the attribute.

An enclosure object corresponds to an screen area displayed
to the user in which the application may place other visual
objects.

A control is an object corresponding to a visual element
with which the user may interact.

Non-visual objects provide supporting functionality for the
application to use, such as lists and timers, but do not
directly correspond to anything visible on screen.

Events >            Each class of object recognizes a
defined set of user actions as indicating events which
should be transmitted to the application.  The application
may associate one or more event handler routines with each
event the object can generate.  When a user action occurs,
the toolkit calls all the event handlers for the
corresponding event, providing each with a piece of data
supplied by the application and with information describing
the exact nature of the event.

The application can also send events to objects and objects
may send events to other objects.

Fonts >             A font is an object designating a
particular style of text display.  The UAPI provides
services for obtaining a native font object by attribute
matching or by user interaction.  A UAPI implementation is
required to provide font objects with certain common names,
so that a portable application may request certain common
text style distinctions.

Color >             A color is an object designating a
particular style of visual presentation of an area of a
screen.  The UAPI provides services for obtaining a native
color object by attribute matching or by user interaction.
A UAPI implementation is required to provide color objects
with certain common names, so that a portable application
may request certain common visual distinctions.

Help System >       The UAPI will include interfaces for
registering and providing help services; this area is still
under discussion.  The goal is to support delivery using (a)
a native help system, (b) an enterprise help system, or (c)
a toolkit-provided help system.

Resources >         Resources are object definitions defined
and stored external to the application and used to provide
attribute values when objects are instantiated.

A UAPI toolkit must provide a tool which reads resource
definitions in a standard format and sets the stored
resources for an application appropriately.

Selections >        A selection is a named piece of data
made available to the application.  A selection may be made
available by the application or by the UAPI implementation;
the toolkit may provide a selection either as a result of an
interaction with the user designating a value as a selection
or as a result of external events, including actions of
other applications.

An implementation provides one or more selection lists, each
containing one or more named selections, each of which is
available in one or more named formats.

Selections also provide a protocol for exchanging data
dynamically, using a sequence of events passed back and
forth between the provider of the selection and the
application.  This dynamic exchange also provides drag-and-
drop capabilities.

Volume-Number: Volume 31, Number 27