steve@unidata.ucar.edu (Steve Emmerson) (02/08/90)
To Whom it may concern:
We (the Unidata Program Center) wish to announce the creation of a
mailing-list for the maintenance, enhancement, and evolution of the
XGKS package, which was created by the University of Illinois under
contract with IBM and is distributed as part of X11R4.
The XGKS package allows GKS applications to operate in an X windowing
environment. It is a full 2C GKS implementation.
We have been using the XGKS package for approximately one year and have
recently made several modifications to it. The modifications include
Enhancements:
Colormap handling:
Resource support:
Bug Fixes:
Metafile handling:
Miscellaneous:
Lint(1) Removal (lots):
Serious lint:
Non-serious lint:
Arbitrary, Capricious, and Gratuitous changes:
Patches for these modifications and accompanying text can be found in
the file "~ftp/pub/xgks.1.PATCH.Z, which is available via anonymous FTP
from host unidata.ucar.edu.
Besides releasing these modification to the general public out of
altruism, we feel that a mailing-list will result in faster and better
evolution of the XGKS package -- to our eventual benefit.
To join the mailing-list, send a request to
xgks-request@unidata.ucar.edu
Thereafter, to submit an article send it to
xgks@unidata.ucar.edu
To prime the pump -- so to speak -- here are some potential further
modifications (i.e. discussion topics):
Update documentation to reflect changes.
Modify the C-binding of the GKS interface to reflect the
soon-to-be-agreed-upon standard.
Add a mechanism by which an application program can pass the
invocation arguments to XGKS so that it can obtain the normal X11
command-line options such as "-name <prog>".
Modify XGKS to return the actual size of the obtained window,
rather than the hard-coded 1280 by 1024.
Defer the mapping of the XGKS window till a call to ACTIVATE
WORKSTATION is made. This enables the actual window size to be
returned to the GKS application.
One further note. We're maintaining the XGKS package because we use it
and our clients, therefore, will also be using it. Should something
better come down the pike, however, we may no longer need to support
it -- in which case we'll drop it. I don't expect, however, that this
will happen within a year's time-frame, and when it does, I expect to
give plenty of warning so that someone else can pick up where we left off.
Regards,
Steve Emmerson steve@unidata.ucar.edu
Steve Emmerson steve@unidata.ucar.edu ...!ncar!unidata!steve