Search                        Top                                  Index
REF X                                   R. Evans, Adrian Howard Feb 1992
                                            Revised John Gibson May 1993

        COPYRIGHT University of Sussex 1993. All Rights Reserved.

<<<<<<<<<<<<<<<<<<<<<                             >>>>>>>>>>>>>>>>>>>>>>
<<<<<<<<<<<<<<<<<<<<<  OVERVIEW OF X INTERFACES   >>>>>>>>>>>>>>>>>>>>>>
<<<<<<<<<<<<<<<<<<<<<                             >>>>>>>>>>>>>>>>>>>>>>

X is  a  large and  complicated  emerging standard  for  user  interface
software on high resolution displays. From V14, Poplog provides specific
support  for  operation  under  X,  in  particular  (but  not  only)  an
application programmer's interface to the X Toolkit. This file discusses
the overall organisation of X facilities, and provides  cross-references
to more specific documentation of individual packages.

         CONTENTS - (Use <ENTER> g to access required sections)

  1   Introduction
      1.1   IMPORTANT NOTE
      1.2   Overview of X

  2   X Clients: Possible Configurations
      2.1   Generic Support For X Interfaces

  3   Poplog Startup Under X
      3.1   Generic X Hooks

  4   Generic X libraries: LIB POPXLIB and INCLUDE XDEFS

  5   Poplog Image X Link Specification

  6   Poplog And The X Toolkit

  7   Widget Set Interfaces
      7.1   The Poplog Widget Set: Xpw

  8   Poplog And Xlib

  9   Ved And X
      9.1   XVed
      9.2   Terminal Ved

 10   Miscellaneous
      10.1  Poplog And CLX
      10.2  Prolog And X
      10.3  Legal Liability

 11   See Also

1  Introduction

Many of  the  documentation  cross-references  in  this  file  refer  to
X-specific REF files.  These will  only be easily  accessible after  you
have loaded LIB * POPXLIB. If  you are reading this  file from Ved,  you
are therefore advised  to load this  library now, even  if you are  only
browsing the documentation. Simply type

         <ENTER> uses popxlib

Note also  that the  addition  of X-related  facilities to  Poplog  have
increased the need for  mixed-case library and documentation  filenames.
This  is  somewhat  at  odds  with  previous  conventions  for  filename
references, which have used all-uppercase  (for prominence in the  text)
to refer  to all-lowercase  actual filenames.  To retain  compatibility,
text references  in  all-uppercase  refer to  all-lowercase  files,  but
mixed-case references should  be taken as  verbatim. This strategy  does
not  cope  with  all-uppercase  filenames,  and  for  this  reason  such
filenames have been (and should be by users) avoided.

1.2  Overview of X
X is a specification for the user-interface component of programs  which
wish to  use  typical  workstation  hardware  (high  resolution  screen,
keyboard and mouse.) The idea is to provide facilities for many programs
to use  the same  screen,  keyboard and  mouse simultaneously,  and  the
standardisation required to offer a  high degree of portability  between
different hardware.

An implementation of X  is a software  package typically comprising  two
main parts. Firstly, software for a self-contained program called an  'X
server' which maintains complete control  over the screen, keyboard  and
mouse. Secondly software  libraries designed to  form part of  programs,
called 'X  clients', which  wish  to make  use of  these  user-interface
facilities. It  is largely  this latter  component that  is of  interest
here. The facilities  discussed below  allow Poplog to  operate as  an X
client of  an  X server  which  is managing  the  actual  user-interface

X was originally developed in a  research project based at MIT.  However
development involved a number of  major computer manufacturers, and  the
system is rapidly becoming a standard for user-interface software. It is
supported by many of the  main workstation producers and in  particular,
most of the  main Poplog platforms  (including Sun, Hewlett-Packard  and
DEC workstations). Hence from V14 Poplog includes a range of  facilities
for interfacing to X at different levels.

2  X Clients: Possible Configurations

The basis of X  Windows operation is that  all access to  user-interface
hardware by 'ordinary' user programs is mediated by the X server. So any
program desiring user-interface facilities obtains them by becoming an X
client,  that   is,   establishing  a   communication   link   (called a
'connection') to an X server (or possibly more than one, an X client can
use more than  one screen.)  X servers and  clients communicate  using a
byte-stream protocol:  messages between  them  consist of  sequences  of
bytes, coded to  represent commands, requests  and replies. Examples  of
messages from  client to  server include  "Create a  new window  on  the
screen", "Tell  me  what  fonts  are available",  "Write  text  at  this
location in  this  window", "Display  this  bitmap image".  Examples  of
messages from server to  client include "The user  just pressed the  'A'
key in  this window",  "This window  has just  become visible  -  please
refresh it", "The mouse cursor just entered this window".

In principal, an X client can operate directly at this level, by  simply
opening a connection to a server, and talking in terms of the low  level
protocol.  The  advantage  of  this  level  of  interface  is   complete
independence of all  the design assumptions,  restrictions and  possible
bugs of  the higher  level support.  The disadvantage  is that  all  the
client software must  be written  from scratch, and  common ground  with
other X software is minimal. An example of such an interface is the  CLX
package, which  provides  Common  Lisp  functions  for  controlling  the
user-interface, and converts them directly  into X server messages.  CLX
is available under Poplog Common Lisp (see 'Poplog and CLX' below),  and
so using these facilities Poplog can operate as a low level X client  of
this sort.

X offers two  layers of higher  level support as  part of the  standard.
Both are provided in the form  of C libraries which can be  incorporated
into other programs.

The lower of these two levels is called 'Xlib', and consists of a  large
number of procedures,  each roughly  corresponding to  the sending  of a
protocol message to the server. This level avoids the need to explicitly
code up  and  dispatch  protocol messages,  and  supports  decoding  and
queuing of  incoming messages  from  the server.  It provides  a  purely
procedural interface, but at  about the same  level of functionality  as
the protocol  language  itself. Thus  it  offers flexible  and  portable
support for  application programs,  but still  requires substantial  low
level user-interface programming,  even for  quite simple  applications.
The Poplog library  LIB * XLIB (see  Poplog and  Xlib below)  provides a
basic interface to this level, implemented via LIB * NEWEXTERNAL.

The higher level interface  is called the 'X  Toolkit' (or simply  'Xt',
pronounced EX-TEE). This  is built  on top of  Xlib, and  offers a  high
level object oriented view of the user interface. It allows programs  to
be designed in terms of  user-interface objects (called 'widgets')  such
as menus, scrollbars,  text edit buffers,  confirmation boxes,  graphics
tablets  etc.,  without  having  to   be  concerned  about  details   of
implementations (screen appearance,  low level keyboard  interpretation,
response to server refresh requests etc.).

In fact, the X Toolkit level itself divides into two parts. It  provides
facilities for  creating new  classes of  user-interface object  (called
widget classes) --- for example, defining a new kind of scrollbar.  This
is generally called 'widget class programming' and currently there is no
specific support for it in Poplog. The Toolkit also provides  facilities
for using and customising predefined user-interface objects, for example
setting up a  menu. This is  generally called 'application  programming'
and is  supported in  Poplog, and  indeed is  the primary  component  of
Poplog's current X Windows support (see Poplog and the X Toolkit below).

However, application programming using the X Toolkit clearly needs  some
predefined widget class definitions to  be available to the  programmer.
The X Toolkit  standard itself  includes only  a few  very basic  widget
class definitions,  solely  to support  more  sophisticated  definitions
supplied  independently  by  widget  class  programmers.  Widget   class
definitions tend to  be grouped  into sets (called  widget sets),  and a
particular software supplier will supply a widget set (generally in  the
form of a C library) providing user-interface objects conforming to that
supplier's look and  feel (that  is, visual  appearance and  conventions
about keyboard and mouse button usage etc.) Poplog provides support  for
accessing such externally  defined widget sets  generally, and  detailed
support for a number of available widget sets (see Widget Set Interfaces

In addition, Poplog includes a widget set specifically designed to cover
some basic interface  needs for  Poplog applications.  This widget  set,
called Xpw,  takes  the form  of  a  C library  archive  (included  with
Poplog), and  provides  simple  text  and  graphics  facilities  under X
Windows (see The Poplog  Widget Set: Xpw  below). These facilities  are
sufficient for  a wide  range of  common requirements,  allowing  Poplog
applications to be  constructed without any  externally supplied  widget
set definitions (see  TEACH * RC_GRAPHIC for examples  using the  Poplog
widget set).

Finally, in addition to these various direct interfaces to an X  server,
Poplog can be run  'inside X', but without  actually being an X  client.
Most X implementations include programs which act as terminal emulators.
That is, they are X client programs which create a single window on  the
screen which functions just as if it were an ordinary terminal. Examples
of such programs include  'xterm', 'cmdtool', 'shelltool' and  'hpterm'.
Such programs  allow Poplog  to be  run just  as if  it was  run  from a
terminal. Nevertheless, some aspects of Poplog's operation, most notably
Ved customisation,  need to  be sensitive  to the  fact that  Poplog  is
running under X. To accommodate  this, Poplog includes support for  this
aspect of interaction with X (see Ved and X below).

2.1  Generic Support For X Interfaces
It will be clear from the preceding discussion, that there are a  number
of ways a Poplog system might operate as an X client. Indeed as well  as
the standard interface layers discussed  above, there are already  other
defined interfaces and  toolkits (such as  Sun's 'XView' library)  which
might  be  candidates  for  a  Poplog  interface,  and  doubtless   more
possibilities will emerge in the future. It is important, therefore,  to
distinguish between generic  aspects of Poplog's  X interface (that  is,
the small  number of  facilities intended  to accommodate  any  chosen X
interface package),  and  aspects which  are  specific to  a  particular
chosen interface. This is particularly  relevant to discussion of  the X
Toolkit interface, this is the primary supported interface in Poplog and
some system hooks (eg sysxsetup, see REF * SYSTEM) assume it by default.
But it  is just  one possible  interface, and  ultimately the  generic X
support does not favour it over any other.

Generally  speaking,  the  identifiers   associated  with  the   generic
facilities contain a lower  case 'x' in  their name. This  distinguishes
them from other X facilities, for example the X Toolkit identifiers have
'Xt' or 'Xpt' as a prefix. (REF * XTOOLKIT has a section describing  the
naming conventions used by the toolkit interface.)

3  Poplog Startup Under X

The first of the generic X facilities provided in Poplog is a  mechanism
for specifying that  X is  present (and hence  that an  X interface  can
sensibly be activated),  and for passing  parameters to that  interface,
for example from the command line. This mechanism centres on the  system
variable popunderx, and is described fully in REF * SYSTEM. The variable
popunderx is  initially false,  but  if set  to  a non-false  value,  it
indicates that  Poplog is  running  under X,  and various  system  hooks
(described below) use this  to compile X-specific initialisation  files,
run X-specific startup routines, and so forth. Furthermore, the value of
popunderx  (when  non-false)  may  be  used  to  provide  initialisation
parameters for X interface startup.

popunderx can be set in one of two ways:

    (1) From the  command line: Invoking Poplog  with the  %x flag  (for
        details see REF * SYSTEM). In this case its value can be set  to
        a list  of  string  parameters,  using  the  "(  ...  )"  syntax
        described in REF * SYSTEM. For example the Unix shell command:

          % pop11 %x \( -display mysun -font 6x10 \)

        will cause Poplog to start up in pop11 with popunderx set to

          ['-display' 'mysun' '-font' '6x10']

        If no parenthesised arguments are specified, popunderx is set to
        [],  indicating  the  presence  of   X,  but  with  no   initial
        parameters. Note that all the standard Poplog startup  commands,
        ved, prolog, clisp etc.., respect the %x flag in this way.

    (2) By a user or library program: popunderx is a perfectly  ordinary
        variable which can be  set manually to  influence X startup.  Of
        course, the value assigned  must make sense  to the X  interface
        package in use.  For  example the  X Toolkit  interface  expects
        a (possibly empty) list of  strings as would have been passed on
        the command line as above. Also the assignment must occur before
        any X-related system hooks are run  if it is to have its  proper
        effect. (Note: the  user's init.p  file is  compiled before  any
        such X-related  hooks  are  encountered, so  manual  setting  of
        popunderx in init.p will catch them all correctly).

It is worth noting that it  is not possible for Poplog to  automatically
determine that X support is required:  X clients can be run on  machines
with no  local X  server support  at all,  communicating with  a  remote
server over a network, and conversely a user running X might want to run
Poplog without any X features.

Also X interfaces  themselves should generally  not depend on  popunderx
being set: if it is set then  they may use its value for  initialisation
information, but  they  should  work if  initialised  directly  even  if
popunderx is false.

3.1  Generic X Hooks
While setting popunderx is an indication that X support is required,  it
does not  itself cause  any X-related  activity. It  merely causes  some
standard Poplog system hooks to  run X-specific variants (thus  syssetup
will run  sysxsetup  etc.).  This  section  describes  those  X-specific
variants and the contexts in which they are called.

initx.p                                                           [file]
        If popunderx is non-false, and the %noinit flag (for details see
        REF * SYSTEM) is not specified, then  sysinitcomp will look  for
        the file '$popsys/initx.p'  and compile  it if  found, and  then
        '$poplib/initx.p' and compile it if found. If the latter file is
        not found, it will look  for 'initx.p' in the current  directory
        and  compile  it  if  found.  This  process  takes  place  after
        compilation of the corresponding 'init.p' files.

xpopexit                                            [procedure variable]
        If popunderx is non-false, this procedure is called by  sysexit,
        just after popexit.

4  Generic X libraries: LIB POPXLIB and INCLUDE XDEFS

A single library  in the main  Pop-11 library directory  is intended  to
provide the  initial access  point  for all  Poplog X  facilities.  This
library is called LIB * POPXLIB (ie '$usepop/pop/lib/lib/popxlib.p') and
will need to be compiled by almost  any user of any of the X  facilities
discussed here.

LIB * POPXLIB extends  Poplog's  various search  paths  with  additional
directories  containing  X-specific  files.  Thus  the  X   autoloadable
directory  is  added  to  popautolist,   the  X  library  directory   to
popuseslist, the X  help directory  to vedhelplist etc..  Once this  has
been done, most of the  X facilities become directly accessible.  (Note:
many of the REF files  referred to in this  file are X-specific, and  so
will only be found after

        uses popxlib;

has been run. So even if you are just browsing the X documentation,  you
will need to have loaded this library.)

LIB * POPXLIB obtains all of  the potentially site-specific  information
it  needs   from  the   include   file  INCLUDE * XDEFS.   The   default
INCLUDE * XDEFS file defines a set of constants giving the location of X
facilities within Poplog, and probably will not need alteration in  most
cases. If needed, it can be  customised to the local site  requirements;
the  recommended  way   to  achieve   this  it   to  make   a  copy   of
$usepop/pop/lib/include/ called $poplocal/local/include/
(which will then override the system one), and then edit in  appropriate
local changes.

XPOP -> filename                                              [constant]
        The directory contain all the  X-specific files within the  main
        Poplog tree. Default '$usepop/pop/x'.

XPOPSTB -> filename_or_false                                  [constant]
        If non-false, this is the name of the 'stb' file to be used with
        Poplog when running  under X. By  default the X  code is  linked
        into the standard Poplog image, and the standard stb file can be
        used. However some sites  may wish to  have two separate  Poplog
        executables, one without X (and  hence smaller) and one with  X.
        This can be achieved by renaming the executable linked WITH X to
        a new name (say 'xpop11'), and defining this constant to be  the
        FULL-PATHNAME of the .stb file (say 'xpop11.stb') created by the
        link process. Running LIB * POPXLIB will then set $popexlinkbase
        to  the   correct   stb   file   for   external   loading   (see
        REF * EXTERNAL).

XPOPBIN -> filename                                           [constant]
        The directory containing X-specific  binaries (the Xpw  archive,
        etc.). Default <XPOP>/bin.

XPOPAUTO -> filename                                          [constant]
        The   directory   containing   X-specific   Pop-11  autoloadable
        libraries. Default <XPOP>/pop/auto.

XPOPLIB -> filename                                           [constant]
        The  directory  containing  X-specific  Pop-11  non-autoloadable
        libraries. Default <XPOP>/pop/lib.

XPOPXLIB -> filename                                          [constant]
        The  directory   containing   the  'Xlib'   libraries.   Default

XPOPINCLUDE -> filename                                       [constant]
        The directory containing  X-specific Pop-11  include files  (but
        NOT INCLUDE *XDEFS !). Default <XPOP>/pop/include.

XPOPHELP -> filename                                          [constant]
        The directory containing  X-specific Pop-11 HELP files.  Default

XPOPTEACH -> filename                                         [constant]
        The directory containing X-specific Pop-11 TEACH files.  Default

XPOPDOC -> filename                                           [constant]
        The directory  containing X-specific Pop-11 DOC  files.  Default

XPOPREF -> filename                                           [constant]
        The directory  containing X-specific Pop-11 REF  files.  Default

XPOPSRC -> filename                                           [constant]
        The directory containing X  Toolkit interface source files  (not
        available on all systems). Default <XPOP>/pop/src.

XPOPDEMO -> filename                                          [constant]
        The  directory  containing  X-specific  Pop-11  demos.   Default

5  Poplog Image X Link Specification

The standard Poplog image  (e.g. as created by  the * NEWPOP link  step)
will include support for X (unless  you override it with the NEWPOP  nox
option, for example). Linking for  X requires access to your  system's X
Toolkit and Xlib  archive libraries.

Because  the  names  and  locations   of  these  libraries  are   highly
system-dependent, the way  in which a  Poplog image is  linked for X  is
controlled  by  Unix   environment  variable   settings  (logical   name
translations in VMS), containing specifications of the form

        x= xtype / xversion : library-arguments

(the information in these specifications  is described more fully  under
* sys_translate_exlibs below). For example, in Unix:

        setenv POP_XOL_EXLIBS \
            "x=openlook/3000: -L$OPENWINHOME/lib -lXol -lXt -lX11"

and in VMS:

        define POP_XM_EXLIBS -
            "x=motif/1001: sys$share:decw$xmlibshr/shareable"

As the examples illustrate, the variable names have the form


where XPREFIX is a short prefix corresponding to the X link type. NEWPOP
may be  given an  argument  -xprefix (i.e.  the  same in  lowercase)  to
specify that the  X link  type should  be taken  from the  corresponding

The default  used by  NEWPOP (and  other  parts of  the system)  is  the
variable  POP_XLINK_EXLIBS   (i.e.  -xlink):   this  may   specify   the
information explicitly,  but  more  usually  `dereferences'  to  another
variable, by having a translation starting with "==", e.g.

        setenv POP_XLINK_EXLIBS "==POP_XOL_EXLIBS"      (Unix)
        define POP_XLINK_EXLIBS "==POP_XM_EXLIBS"       (VMS)

The Poplog login shell script files

        $popcom/popenv                      (Unix)                   (VMS)

(which are sourced automatically by $popcom/poplog etc) provide default
host-specific definitions for the following variables:

        POP_XM_EXLIBS                       (Motif)
        POP_XOL_EXLIBS                      (OpenLook)
        POP_XT_EXLIBS                       (MIT)
        POP_XLINK_EXLIBS                    (== default)

Note that while POP_XM_EXLIBS and POP_XOL_EXLIBS may be set to something
on a particular system, this does not imply that Motif or OpenLook,  etc
is actually available on that system. POP_XLINK_EXLIBS is always set for
the appropriate host system default.  If required, you can override  any
of these settings in your own local files, i.e.

        $poplocal/local/com/popenv          (Unix)
        poplocal:[]      (VMS)

The information from the X link  specification is made available in  the
run-time system by the following identifiers:

XLINK_TYPE -> string                                          [constant]
popxlink_motif    -> true                                     [constant]
popxlink_openlook -> true                                     [constant]
popxlink_mit      -> true                                     [constant]
        These constants are defined if and only if the Poplog image  was
        linked with the X part of the system.

        XLINK_TYPE contains a string describing which X system the image
        was linked against (i.e. relating to the value of  XLINK_EXLIBS,
        see below). At the same time, the constant


        is also defined, with value true.

        Standard values for XLINK_TYPE include:

                XLINK_EXLIBS includes the Motif widget set library.

                XLINK_EXLIBS includes the OpenLook widget set library.

                XLINK_EXLIBS contains only  the standard  MIT X  Toolkit

XLINK_VERSION -> int                                          [constant]
        This constant is  defined only  if the Poplog  image was  linked
        with the X  part of  the system  (and then  only if  the X  link
        specification supplied  it). It  represents the  version of  the
        libraries specified in XLINK_EXLIBDIRS/XLINK_EXLIBFILES.

        It usually has the form

            (major-release-number * 1000) + minor-release-number

        However, being  X  implementation-specific, this  is  meaningful
        only in relation  to XLINK_TYPE;  you should  therefore NOT  use
        XLINK_VERSION  directly,  but  instead  use  the   corresponding
        widgetset identifier, e.g. XOL_VERSION, XM_VERSION, etc.

XLINK_EXLIBDIRS  -> string_list                               [variable]
XLINK_EXLIBFILES -> string_list                               [variable]
XLINK_EXLIBS     -> string_list                               [variable]
        These variables are only defined  in a Poplog image linked  with
        X, and contain  lists of  strings describing the  X Toolkit  and
        Xlib library archives against which the image was linked.  Their
        contents are system-dependent.

        XLINK_EXLIBDIRS  contains  any  preceding  Unix  '-L'  directory
        specifications, e.g.

            [ '-L/usr/openwin' ]

        This is always [] in VMS.

        XLINK_EXLIBFILES contains the  actually library file  arguments,

            [ '-lXol' '-lXt' '-lX11' ]

        in Unix, or

            [ 'sys$share:decw$xmlibshr/share' ]

        in VMS.

        XLINK_EXLIBS is an autoloadable variable which is a concatention
        of the other two via their identifiers, i.e.

            [% ident XLINK_EXLIBDIRS, ident XLINK_EXLIBFILES %]

        Thus  when  used  as  an   external  library  list  to   exload,
        XptLoadProcedures, etc,  the  identifiers  are  dereferenced  to
        produce the composite list,  and will automatically include  any
        additions  you   might   have   made   to   XLINK_EXLIBDIRS   or
        XLINK_EXLIBFILES after system startup.

XLINK_EXT_EXLIBS -> string_list                               [variable]
        This is an autoloadable list of additional external libraries to
        be used  (in  exload, XptLoadProcedures,  etc)  when  externally
        loading MIT  toolkit  extensions.  Its default  value  for  Unix
        systems is

            [ '-lXmu' '-lXext' ]


            [ 'decw$xmulibshr/share' 'decw$xextlibshr/share' ]

        in VMS.

sys_translate_exlibs(varname) -> (xtype, xversion, exlibs)   [procedure]
        This procedure takes a Unix environment variable or VMS  logical
        name varname  (a  string),  and  returns  its  translation  from
        systranslate as  a list  of external  library file  strings.  In
        addition, if the translation is  a Poplog X link  specification,
        the type and version from that are returned as well.

        First, if the  translation string  trans begins  with '==',  the
        remainder  of  trans  is  assumed  to  be  another   environment
        variable/logical  name,  and  the  results  are  the   recursive
        translation of that variable with sys_translate_exlibs.

        Otherwise, if  trans does  not begin  with 'x=',  the xtype  and
        xversion results are both false, and the exlibs result is

            sysparse_string(trans, false)

        i.e. the list of  strings got by  splitting trans at  whitespace

        X Link Specification
        However, if trans begins with 'x=', it is taken to be a Poplog X
        link specification of the form

            x= xtype / xversion : library-arguments

        (where the  '/ xversion'  and ':  library-arguments' parts,  and
        spaces between the parts, are optional).

            This  field  is  a  single  keyword  used  to  identify  the
            particular X  implementation  against which  the  image  was
            linked, and is returned as the xtype result (a string).

            (When used by  the Poplog linker,  this information is  made
            available in the running  image as the  string value of  the
            constant   XLINK_TYPE.    In    addition,    the    constant
            popxlink_xtype is also defined, with value true.)

            This field gives the version number of the X implementation,
            usually defined as:

              (major-release-number * 1000) + minor-release-number

            This information can be omitted; if present, it is  returned
            as the xversion result (an integer), otherwise false.

            (When used by the Poplog linker, this information if present
            is made available in the running  image as the value of  the
            constant XLINK_VERSION.)

            This field is some arbitrary sequence of arguments, returned
            in the exlibs result as

              sysparse_string(library-arguments, false)

            i.e. the list of strings  got by splitting it at  whitespace

            (When used by the Poplog linker, this information is  passed
            to  the   operating-system   linker,  and   identifies   the
            particular X libraries to use. The information is also  made
            available in the running image as the value of the variables
            XLINK_EXLIBDIRS and XLINK_EXLIBFILES -- see above.)

        See the introduction to this section above for a description  of
        the naming  conventions for  X link  environment variables,  and
        other example settings.

        The most basic X configuration would be:

              x= mit : -lXt -lX11                         (Unix)
              x= mit : sys$share:decw$xtshr/shareable     (VMS)

        The xtype  and xversion  fields can  have any  values;  however,
        there   are   three   xtypes   for   which   the   corresponding
        popxlink_xtype  identifier  is  tested   for  in  the   Poplog X

                implies use of the Motif Widget Set and Toolkit

                implies use of Sun's OLIT

                implies use of a standard MIT distribution

        The :library-arguments part is optional: In Unix, omitting  this
        is only meaningful if  all the relevant X  libraries are in  the
        standard directories  (/lib, /usr/lib,  and /usr/local/lib),  or
        the LD_LIBRARY_PATH environment  variable is set  appropriately.
        It is  usually more  reliable to  supply specific  -L  directory
        qualifiers, e.g. to use Version 2.5 of OLIT without  necessarily
        running in the OpenWindows environment:

              x= openlook/2005: -L/usr/openwin/lib -lXol -lXt -lX11

        In VMS, you should  always supply :library-arguments giving  the
        relevant DECwindows shareable image(s).

6  Poplog And The X Toolkit

It is expected  that most  Poplog applications  will make  use of  the X
Toolkit to implement X  based user interfaces.  For this reason,  Poplog
provides  an  extensive  application  programmer's  interface  to  the X
Toolkit. The entry point into reference documentation for this interface
is REF * XTOOLKIT. Tutorial introductions to some of the facilities  can
be found in TEACH * XTOOLKIT, TEACH * Xpw, TEACH * RC_GRAPHIC (which use
the Poplog widget  set, available  on all  systems), TEACH * MOTIF  (for
those with access to  the Motif widget  set), and TEACH * OPENLOOK  (for
those with  access  to  the  OLIT  widget  set,  available  under  Sun's
OpenWindows system).

No explicit  support  for widget  class  programming is  available  yet,
although all of the low-level primitives required are present in  Poplog

7  Widget Set Interfaces

Predefined C  widget classes  can be  externally loaded  like any  other
external data. However, Poplog provides  direct support for the  Poplog,
Motif, OLIT  and Athena  widget sets  -- see  Widget Set  Interfaces  in
REF * XT_LIBS for more details, as well as

     # HELP * Xpw
     # HELP * OpenLook,
     # REF * OpenLook
     # HELP * Motif,
     # REF * Motif
     # REF * Athena.

7.1  The Poplog Widget Set: Xpw
The Poplog widget  set is a  small collection of  simple widget  classes
provided with  Poplog  (although  written in  C).  It  includes  general
purposes graphics and  text handling  widgets, aimed  to support  simple
graphics and bitmap operations, and multi-window Ved.

The Poplog widget set is available on all X-supported platforms, and  is
self-contained (aside from the standard toolkit facilities),  allowing a
range of  applications  to be  constructed  (see TEACH * RC_GRAPHIC  for
examples of use).

The Xpw documentation  presupposes knowledge  of the  general X  toolkit
interface, and the  entry point is  HELP * Xpw. A tutorial  introduction
can be found in TEACH * Xpw.

8  Poplog And Xlib

LIB * XLIB  (see  HELP * XLIB)  provides  access  to  a  collection   of
libraries which externally load the  Xlib interface layer to X  Windows.
This  provides  a  full   interface  to  Xlib,   defined  in  terms   of
LIB * NEWEXTERNAL  (see  HELP * NEWEXTERNAL).  This  interface  is   not
integrated into Poplog to the same  extent as the Toolkit interface  ---
for example  the data  structure  management is  purely as  provided  by
LIB * NEWEXTERNAL and event handling must be catered for explicitly.

Nevertheless there is  a degree of  interchangeability between the  two.
The external-class data structures of either will be acceptable for  the
other, IF type  checks are bypassed.  Thus it is  quite feasible to  use
this Xlib  interface  with  care to  augment  Toolkit  functionality  if

It is anticipated that the Xlib  and Xt interfaces will be more  closely
integrated in future releases of Poplog.

9  Ved And X

9.1  XVed
From Version 14.1, Poplog includes a multi window X based version of the
Ved editor called XVed. See TEACH * XVED for details.

9.2  Terminal Ved
Use of  terminal Ved  under X  operates largely  independently of  other
notions of  running  Poplog as  an  X client.  That  is, if  X  terminal
emulators are available (as they are in most X implementations),  Poplog
can be run within X just as it would be on a terminal, and this is quite
independent of whether  such a Poplog  instance is itself  an X  client.
Nevertheless, Ved needs to  be customised to  operate in this  scenario,
and such customisation  is X-dependent  in the sense  that the  terminal
emulator in use will generally be part of the X system.

A Ved customisation for  the most common of  such X terminal  emulators,
'xterm' is  currently  available.  (Customisations  for  other  terminal
emulators will be provided  in the near  future.) This customisation  is
contained in LIB * VEDXTERM and documented in HELP * VEDXTERM.

An additional library for use with LIB * VEDXTERM which allows the mouse
buttons to act  like function  keys is  provided by  LIB * VEDXGOTOMOUSE


(1) To take full advantage of these terminal emulators, in particular of
    the function keys available on the range of possible keyboards, some
    site-specific customisation of the X system is desirable. These  are
    discussed in HELP * VEDXTERM.

(2) xterm is  unfortunately not  available under  all X  systems. It  is
    present in the MIT distribution, and exists in the 'demo'  directory
    of the OpenWindows 2.0 (SunOS 4.1.1) system. Users of other terminal
    emulators may find suitable 'generic' Ved customisations work (VT100
    emulations   are   common,   for   example   -   see   HELP * VT100,
    HELP * VEDVT100).

10  Miscellaneous

10.1  Poplog And CLX
CLX  (see  HELP * CLX   from  within  Common   Lisp)  is   essentially a
stand-alone Common-Lisp interface to X Windows, with probably no overlap
with the  other X  facilities  described here.  It establishes  its  own
connection to the server, has its own data structures and procedures and
is completely  Lisp  oriented. It  is  available to  Poplog  users  as a
package in the 'contrib' area (see HELP * CONTRIB)

10.2  Prolog And X
Poplog V14 does not provide any explicit support for a Prolog  interface
to X  Windows.  However a  prototype  of  a package  offering  a  Prolog
interface to the Poplog Widget Set can be found in the contrib area, see
'$popcontrib/x/prolog/xpw/README' for more information.

10.3  Legal Liability
The Poplog X interfaces are just  that - interfaces to code produced  by
third parties.  Some  of this  code  is public  domain,  some of  it  is
proprietary. Almost all  of it  is covered by  copyrights, warranty  and
liability limitations  and  sometimes restrictions  on  use. It  is  the
user's responsibility  to ensure  that  their use  of such  software  in
conjunction with Poplog does not violate any of these restrictions.  The
University of  Sussex,  Integral  Solutions Ltd.,  and  their  appointed
agents offer no  warranty and accept  no liability for  the use of  such
third party  code.  The provision  of  interface support  within  Poplog
should not  be taken  as an  indication that  the relevant  third  party
software is present, supported or legally available for use.

Much of the  documentation on  the Poplog/X  interface is  based on  the
following documentation:

                     Xlib - C Language X Interface,
                       MIT X Consortium Standard,
                         X Version 11, Release 4

        Copyright (C) 1985, 1986, 1987, 1988, 1989 Massachusetts
        Institute of Technology,  Cambridge, Massachusetts,  and
        Digital Equipment Corporation, Maynard, Massachusetts.

               X Toolkit Intrinsics - C Language Interface
                             X Window System
                         X Version 11, Release 4

        Copyright (C)  1985,  1986,  1987,  1988,  Massachusetts
        Institute of Technology,  Cambridge, Massachusetts,  and
        Digital Equipment Corporation, Maynard, Massachusetts.

We have used this material under the terms of its copyright which grants
free use under the following conditions:

        "Permission to  use, copy,  modify and  distribute  this
        documentation [ie. those volumes  listed above] for  any
        purpose and without fee is hereby granted, provided that
        the above  copyright notice  appears in  all copies  and
        that both  the  copyright  notice  and  this  permission
        notice appear in supporting documentation, and that  the
        name of M.I.T. or Digital not be used in advertising  or
        publicity pertaining  to  distribution of  the  software
        without specific, written, prior permission. M.I.T.  and
        Digital makes no  representations about the  suitability
        of the software described herin  for any purpose. It  is
        provided "as is" without express of implied warranty."

11  See Also

    A comprehensive list of X publications
    General pointers for the Poplog/X interface

--- C.all/ref/x
--- Copyright University of Sussex 1993. All rights reserved.