From ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!decwrl!vixie Thu Jan  4 08:54:33 PST 1990
Subject: Re: X11R4 Distribution; EXPO is the LEAST efficient place to get the distribution.
Status: RO

Article 16988 of comp.windows.x:
Path: ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!decwrl!vixie
>From: vixie@decwrl.dec.com (Paul A Vixie)
Newsgroups: comp.windows.x
Subject: Re: X11R4 Distribution; EXPO is the LEAST efficient place to get the distribution.
Message-ID: <VIXIE.90Jan4005524@jove.pa.dec.com>
Date: 4 Jan 90 08:55:24 GMT
References: <9001032217.AA00831@max.crl.dec.com> <75693@uunet.UU.NET>
Sender: news@decwrl.dec.com
Organization: DEC Western Research Lab
Lines: 19

Gatekeeper.dec.com was down from 10pm/3Jan to 1am/4Jan due to bugs in its NFS
service which have never been seen before.  The fix, finally, was to disallow
NFS completely until I find out why Ultrix 3.1 cannot deal with 200 people
all over the NSFNET (and probably elsewhere) all trying to mount /archive
and copy files from it.

This means that FTP will be the only supported export mechanism for a while.
It also means that decwrl's UUCP and Easynet neighbors can't access R4 for now.

I'm not too worried about Gatekeeper only exporting via FTP, since it sent
out 2 gigabytes of FTP traffic in the first four hours after R4's release.
(We normally do less than 100 megabytes for an entire 24-hour period.)

Paul Vixie
DEC WRL
--
Paul Vixie
DEC Western Research Lab	<vixie@decwrl.dec.com>
Palo Alto, California		{ames,att,uunet}!decwrl!vixie


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!jim Thu Jan  4 09:03:50 PST 1990
Subject: size of R4
Status: O

Article 16968 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!jim
>From: jim@EXPO.LCS.MIT.EDU (Jim Fulton)
Newsgroups: comp.windows.x
Subject: size of R4
Message-ID: <9001032235.AA03714@kanga.lcs.mit.edu>
Date: 3 Jan 90 22:35:39 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: X Consortium, MIT Laboratory for Computer Science
Lines: 343


Here's the README file that can be ftp'ed from the various sites listed in the
previous announcement.  The uncompressed size of each tape is roughly 35
megabytes, and compiling adds between 50-120% depending on your architecture.


                                  *  *  *  *  *


Here is a roadmap to the R4 sources:

        README           this file
        RELNOTES.PS      R4 release notes in PostScript
        RELNOTES.txt     R4 release notes in plain text
        RELNOTES.lpt     R4 release notes in lpt format
        R4notice         R4 announcement (also where to get X)
        ERRATA           helpful hints
        tape-1/          core software for X Window System      (required)
        tape-2/          contrib clients and core doc           (recommended)
        tape-3/          contrib libraries and other toolkits   (optional)
        tape-4/          contrib Andrew, games, etc.            (optional)

The split pieces are all 512k (524288 bytes) long (except for the last one in
each directory) and must be transfered in image mode (use the ftp "binary"
and "mget" commands).  If you are doing an "mget" you'll probably want to 
restart ftp with the "-i" option to prevent it from asking you about every
file.

Each directory contains a CHECKSUMS file containing both BSD- and SYSV-style
checksums (generated with the "sum" command) and a FILES.Z file containing a
compressed listing of the files stored in that directory.

To extract the sources into another directory (e.g. /usr/local/src/R4/), make
sure you have LOTS of disk space and type the following in each of the
directories that you have copied over:

	%  cat *.?? | uncompress | (cd /usr/local/src/R4/; tar xvf -)

While you are waiting for it to finish, get lunch and read the release notes!


                                    Donna Converse, Jim Fulton, Michelle Leger,
                                   Keith Packard, Chris Peterson, Bob Scheifler
                                                                   X Consortium
                                            MIT Laboratory for Computer Science


                                                                    Ralph Swick
                                                             MIT Project Athena


  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *


				    tape-1

concatenated size:	12293470 bytes  (24 split files)

BSD checksums:		45313 12006

	50648   512 tape-1.01
	43469   512 tape-1.02
	24762   512 tape-1.03
	42127   512 tape-1.04
	22945   512 tape-1.05
	53579   512 tape-1.06
	51509   512 tape-1.07
	20971   512 tape-1.08
	26600   512 tape-1.09
	18861   512 tape-1.10
	00288   512 tape-1.11
	28792   512 tape-1.12
	01524   512 tape-1.13
	50430   512 tape-1.14
	09847   512 tape-1.15
	07136   512 tape-1.16
	02572   512 tape-1.17
	34602   512 tape-1.18
	25305   512 tape-1.19
	20719   512 tape-1.20
	57745   512 tape-1.21
	14588   512 tape-1.22
	63461   512 tape-1.23
	17193   230 tape-1.24


SYSV checksums:		43058 24011

	43558 1024 tape-1.01
	64418 1024 tape-1.02
	24329 1024 tape-1.03
	36946 1024 tape-1.04
	15752 1024 tape-1.05
	54607 1024 tape-1.06
	64719 1024 tape-1.07
	3023 1024 tape-1.08
	4309 1024 tape-1.09
	23142 1024 tape-1.10
	62259 1024 tape-1.11
	2376 1024 tape-1.12
	5600 1024 tape-1.13
	28424 1024 tape-1.14
	61922 1024 tape-1.15
	29004 1024 tape-1.16
	57549 1024 tape-1.17
	56426 1024 tape-1.18
	11220 1024 tape-1.19
	49608 1024 tape-1.20
	64456 1024 tape-1.21
	7857 1024 tape-1.22
	22008 1024 tape-1.23
	35966 459 tape-1.24



  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

				    tape-2


concatenated size:	19128073 bytes  (37 split files)

BSD checksums:		29802 18680

	56139   512 tape-2.01
	01072   512 tape-2.02
	63522   512 tape-2.03
	55032   512 tape-2.04
	31058   512 tape-2.05
	10383   512 tape-2.06
	11222   512 tape-2.07
	36447   512 tape-2.08
	39153   512 tape-2.09
	61979   512 tape-2.10
	34792   512 tape-2.11
	36664   512 tape-2.12
	25787   512 tape-2.13
	17287   512 tape-2.14
	42555   512 tape-2.15
	02519   512 tape-2.16
	13127   512 tape-2.17
	51167   512 tape-2.18
	25426   512 tape-2.19
	14934   512 tape-2.20
	19059   512 tape-2.21
	29695   512 tape-2.22
	34951   512 tape-2.23
	16127   512 tape-2.24
	61158   512 tape-2.25
	06665   512 tape-2.26
	63456   512 tape-2.27
	29939   512 tape-2.28
	47632   512 tape-2.29
	46697   512 tape-2.30
	27760   512 tape-2.31
	07899   512 tape-2.32
	40750   512 tape-2.33
	41883   512 tape-2.34
	15103   512 tape-2.35
	64296   512 tape-2.36
	38303   248 tape-2.37


SYSV checksums:		62156 37360

	15720 1024 tape-2.01
	16146 1024 tape-2.02
	12122 1024 tape-2.03
	39543 1024 tape-2.04
	38341 1024 tape-2.05
	52617 1024 tape-2.06
	23031 1024 tape-2.07
	15865 1024 tape-2.08
	6645 1024 tape-2.09
	49561 1024 tape-2.10
	27982 1024 tape-2.11
	47223 1024 tape-2.12
	29597 1024 tape-2.13
	32589 1024 tape-2.14
	39991 1024 tape-2.15
	65002 1024 tape-2.16
	41439 1024 tape-2.17
	29746 1024 tape-2.18
	12901 1024 tape-2.19
	33546 1024 tape-2.20
	56671 1024 tape-2.21
	18531 1024 tape-2.22
	18470 1024 tape-2.23
	43758 1024 tape-2.24
	42371 1024 tape-2.25
	25705 1024 tape-2.26
	34971 1024 tape-2.27
	51485 1024 tape-2.28
	10649 1024 tape-2.29
	44011 1024 tape-2.30
	34235 1024 tape-2.31
	47407 1024 tape-2.32
	42800 1024 tape-2.33
	46736 1024 tape-2.34
	26291 1024 tape-2.35
	4863 1024 tape-2.36
	63225 496 tape-2.37


  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

				    tape-3


concatenated size:	14722121 bytes  (29 split files)

BSD checksums:		53082 14378

	38338   512 tape-3.01
	18542   512 tape-3.02
	22624   512 tape-3.03
	16865   512 tape-3.04
	59223   512 tape-3.05
	22381   512 tape-3.06
	15270   512 tape-3.07
	51679   512 tape-3.08
	57196   512 tape-3.09
	25650   512 tape-3.10
	22790   512 tape-3.11
	54992   512 tape-3.12
	45023   512 tape-3.13
	59619   512 tape-3.14
	61259   512 tape-3.15
	48917   512 tape-3.16
	05523   512 tape-3.17
	40927   512 tape-3.18
	46813   512 tape-3.19
	50079   512 tape-3.20
	15548   512 tape-3.21
	20935   512 tape-3.22
	30402   512 tape-3.23
	57696   512 tape-3.24
	14291   512 tape-3.25
	25359   512 tape-3.26
	48976   512 tape-3.27
	03138   512 tape-3.28
	62171    42 tape-3.29


SYSV checksums:		39659 28755

	1145 1024 tape-3.01
	38679 1024 tape-3.02
	6856 1024 tape-3.03
	58266 1024 tape-3.04
	9941 1024 tape-3.05
	780 1024 tape-3.06
	6339 1024 tape-3.07
	48325 1024 tape-3.08
	35735 1024 tape-3.09
	18551 1024 tape-3.10
	45037 1024 tape-3.11
	28963 1024 tape-3.12
	7396 1024 tape-3.13
	12816 1024 tape-3.14
	6591 1024 tape-3.15
	9102 1024 tape-3.16
	7861 1024 tape-3.17
	54781 1024 tape-3.18
	21679 1024 tape-3.19
	1583 1024 tape-3.20
	55226 1024 tape-3.21
	16818 1024 tape-3.22
	892 1024 tape-3.23
	4136 1024 tape-3.24
	39881 1024 tape-3.25
	55948 1024 tape-3.26
	29794 1024 tape-3.27
	53220 1024 tape-3.28
	18668 83 tape-3.29



  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

				    tape-4


concatenated size:	13395995 bytes  (26 split files)

BSD checksums:		61845 13083

	36856   512 tape-4.01
	50866   512 tape-4.02
	01566   512 tape-4.03
	54919   512 tape-4.04
	44600   512 tape-4.05
	46105   512 tape-4.06
	02827   512 tape-4.07
	37927   512 tape-4.08
	34372   512 tape-4.09
	44904   512 tape-4.10
	36405   512 tape-4.11
	26165   512 tape-4.12
	02152   512 tape-4.13
	28207   512 tape-4.14
	22885   512 tape-4.15
	15242   512 tape-4.16
	49103   512 tape-4.17
	50503   512 tape-4.18
	12189   512 tape-4.19
	58165   512 tape-4.20
	17886   512 tape-4.21
	23281   512 tape-4.22
	34960   512 tape-4.23
	54397   512 tape-4.24
	18486   512 tape-4.25
	41749   283 tape-4.26


SYSV checksums:		22346 26165

	1666 1024 tape-4.01
	15291 1024 tape-4.02
	9909 1024 tape-4.03
	25622 1024 tape-4.04
	20557 1024 tape-4.05
	3568 1024 tape-4.06
	16879 1024 tape-4.07
	29657 1024 tape-4.08
	1386 1024 tape-4.09
	13427 1024 tape-4.10
	11299 1024 tape-4.11
	10693 1024 tape-4.12
	6884 1024 tape-4.13
	17868 1024 tape-4.14
	21695 1024 tape-4.15
	61566 1024 tape-4.16
	65452 1024 tape-4.17
	44425 1024 tape-4.18
	63514 1024 tape-4.19
	38579 1024 tape-4.20
	38336 1024 tape-4.21
	59971 1024 tape-4.22
	38366 1024 tape-4.23
	49022 1024 tape-4.24
	14750 1024 tape-4.25
	62849 565 tape-4.26


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!jim Thu Jan  4 09:05:02 PST 1990
Subject: Announcing Release 4 of the X Window System from MIT
Status: RO

Article 16964 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!jim
>From: jim@EXPO.LCS.MIT.EDU (Jim Fulton)
Newsgroups: comp.windows.x
Subject: Announcing Release 4 of the X Window System from MIT
Message-ID: <9001032159.AA29537@expo.lcs.mit.edu>
Date: 3 Jan 90 21:59:31 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: X Consortium, MIT Laboratory for Computer Science
Lines: 141


The MIT X Consortium is proud to announce Release 4 of the X Window System,
Version 11.  Highlights of this version include:

     o	many bugs fixes
     o	the sample server has been heavily optimized, particularly for
		monochrome and 8-bit color frame buffers
     o	support for several additional displays
     o	correct (and faster) wide lines
     o	more fonts
     o	new color database
     o	non-rectangular windows extension
     o	support for X Display Manager Control Protocol in server and xdm
     o	client support for System V, Release 3.2 and STREAMS
     o	function prototypes and experimental C++ support in Xlib
     o	security hooks for passing authentication information, plus a
		sample secret token-based implementation
     o	enhanced Xt Intrinsics with gadgets and varargs interfaces
     o	support the ICCCM in libraries, clients, and window managers
     o	greatly improved Xaw widgets, including menu widget
     o	many new utility routines for standard colormaps, converters, etc.
     o	new window managers, including support for a revised twm
     o	greatly improved xmh interface
     o	8-bit and on-the-fly font setting in xterm
     o	new ditroff previewer
     o	new versions of Andrew, InterViews, and Xw toolkits
     o	XView toolkit and OPEN LOOK window manager
     o	Serpent User Interface Management System
     o	XGKS library
     o	XJ, Wnn, kinput, xterm Internationalization utilities


The software in this release is not in the public domain, but is freely
available without restrictions.  No license is required and there are no
royalties; vendors are actively encouraged to base products upon this software.

This release is available from a variety of sources, including:

     o	the Internet and UUCP sites listed below 
     o	the MIT Software Distribution Center (address below)
     o	and a variety of consulting/mail-order firms


The software is organized into two main distributions: the core X Window System
software supported by the staff of the MIT X Consortium, and user- contributed
software that is provided (without support) as a public service.  Sites that
have access to the Internet or UUCP can retrieve the release from the location
nearest them listed below.  The indicated directories contain a README file
with further instructions and copies of the release notes.

                                                               Anonymous
                        Machine                  Internet      FTP
    Location            Name                     Address       Directory
    --------            -------                  --------      -------------

(1) West USA            gatekeeper.dec.com       16.1.0.2      pub/X11/R4
    Central USA         mordred.cs.purdue.edu    128.10.2.2    pub/X11/R4
(2) Central USA         giza.cis.ohio-state.edu  128.146.8.61  pub/X.V11R4
    Southeast USA       uunet.uu.net             192.48.96.2   X/R4
(3) Northeast USA       crl.dec.com              192.58.206.2  pub/X11/R4

(4) UK Janet            src.doc.ic.ac.uk         129.31.81.36  X.V11R4
    UK niftp            uk.ac.ic.doc.src                       <XV11R4>*

(5) Australia           munnari.oz.au            128.250.1.21  X.V11/R4


Notes:

(1)  The release is also available to UUCP neighbors of decwrl as
     decwrl!~/pub/X11/R4/... and to DEC Easynet sites as DECWRL::"/pub/X11/R4".
     The partition on which the anonymous ftp/uucp/dcp software is kept is
     exported read-only as /archive for public access through NFS.

(2)  The release is also available for general UUCP as follows:

	L.sys (aka Systems) lines follow; the directory tree under
	X.V11R4 will be accessible as osu-cis!~/X.V11R4/.

	#
	# Direct Trailblazer
	#
	osu-cis Any ACU 19200 1-614-292-5112 in:--in:--in: Uanon
	#
	# Micom port selector, at 1200, 2400, or 9600 bps.
	# Replace ##'s below with 12, 24, or 96 (both speed and phone number).
	#
	osu-cis Any ACU ##00 1-614-292-31## "" \r\c Name? osu-cis nected \c GO \d\r\d\r\d\r in:--in:--in: Uanon


(3)  The release is available to DEC Easynet sites as CRL::"/pub/X11/R4".

(4)  For now, the release is only available to UK users of Janet; other 
     European sites are asked to set up their own redistributions.

(5)  Australian sites are strongly urged not to try to get the release from
     the United States.  "Fetchfile" may also be used to retrieve the release
     from the same directory.

(oo) Avoid the temptation to get the release from expo.lcs.mit.edu, esp.
     between the hours of 9am and 6pm.  Connections to expo during those hours
     will be subject to termination without warning.


If you are unable to retrieve the release yourself, a set of four 1600bpi tapes
in UNIX tar format plus printed versions of the major manuals and a copy of the
new Gettys, Newman, and Scheifler book "X Window System: C Library and Protocol
Reference" are available from the MIT Software Center for the following rates
(prices include shipping):

                                                     tapes,
                                 manuals,           manuals,
                                   book               book
                                ----------         ----------

          North America            $125               $400

         Everywhere Else           $175               $500


To order, please send a letter and a check payable to MIT in US currency for
the appropriate amount to:


                        MIT Software Distribution Center
                        Technology Licensing Office
                        room E32-300
                        77 Massachusetts Avenue
                        Cambridge, MA  02139


For ordering information, call the "X Ordering Hotline" at +1 (617) 258-8330.


                                    Donna Converse, Jim Fulton, Michelle Leger,
                                   Keith Packard, Chris Peterson, Bob Scheifler
                                                                   X Consortium
                                            MIT Laboratory for Computer Science

                                                                    Ralph Swick
                                                             MIT Project Athena


From ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!mstar!mstar.morningstar.com!bob Thu Jan  4 09:11:11 PST 1990
Subject: Re: Speeding up Sun 4 X?
Status: O

Article 16998 of comp.windows.x:
Path: ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!mstar!mstar.morningstar.com!bob
>From: bob@MorningStar.Com (Bob Sutterfield)
Newsgroups: comp.windows.x
Subject: Re: Speeding up Sun 4 X?
Message-ID: <BOB.90Jan4101020@volitans.MorningStar.Com>
Date: 4 Jan 90 15:10:20 GMT
References: <50334@bbn.COM> <9001032317.AA02189@expire.lcs.mit.edu>
Sender: news@MorningStar.COM (USENET Administrator)
Reply-To: bob@MorningStar.Com (Bob Sutterfield)
Organization: Morning Star Technologies
Lines: 17
In-reply-to: rws@EXPO.LCS.MIT.EDU's message of 3 Jan 90 23:17:50 GMT

In article <9001032317.AA02189@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes:
   The R4 server is significantly smaller in data size than the R3
   server, at least in my experience.  It's a little larger in text
   size (about 20%);

Hmmm...  glancing at servers running on SPARC machines hereabout:

9:50am> size /usr/local/bin/X11/Xsun bin.sun4/Xsun* 
text    data    bss     dec     hex
557056  32768   13544   603368  934e8   /usr/local/bin/X11/Xsun	(a)
704512  40960   4832    750304  b72e0   bin.sun4/Xsun.cc	(b)
753664  32768   5056    791488  c13c0   bin.sun4/Xsun.gcc	(c)
9:50am>

(a) was built with gcc 1.33 or 1.34 under SunOS 4.0.1	X11R3 + Purdue 2.1
(b) "   "     "    Sun's cc under SunOS 4.0.3c		X11R4
(c) "   "     "    gcc 1.36 under SunOS 4.0.3c		X11R4


From ucla-cs!usc!snorkelwacker!mit-eddie!bu.edu!bu-cs!buit4!rwd Mon Jan  8 12:58:54 PST 1990
Subject: Re: Getting X11R4 up and running.
Status: O

Article 17054 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!mit-eddie!bu.edu!bu-cs!buit4!rwd
>From: rwd@buit4.bu.edu (Robert Deroy)
Newsgroups: comp.windows.x
Subject: Re: Getting X11R4 up and running.
Message-ID: <50107@bu.edu.bu.edu>
Date: 5 Jan 90 02:18:43 GMT
References: <12670@phoenix.Princeton.EDU> <RUSTY.90Jan4173234@garnet.berkeley.edu>
Sender: news@bu.edu.bu.edu
Reply-To: rwd@buit4.bu.edu (Robert Deroy)
Followup-To: comp.windows.x
Organization: Boston University Center for Remote Sensing
Lines: 30

In article <RUSTY.90Jan4173234@garnet.berkeley.edu> rusty@garnet.berkeley.edu writes:
>In article <12670@phoenix.Princeton.EDU> reed@olympus.Berkeley.EDU writes:
>
>   From: reed@olympus.Berkeley.EDU
>   Subject: Getting X11R4 up and running.
>   Date: 5 Jan 90 00:18:41 GMT
>
>   I was wondering if anyone could help me out with this problem.  Although I
>   was able to compile almost all of the release, all of the executables that
>   I try to run have the following results.
>
>		   ld.so: libXmu.so.4: not found
>
>This also happened to me; sparcstation 1, sunos 4.0.3c, with gcc.
>I've decided to try not using gcc and am now doing another "make
>world".

Since this is the second question of this type, I will post the
answer.  You need to run /usr/etc/ldconfig as root.  This will update
the link-editor directory cache (see /etc/rc.local).  Of course, this
assumes you did a "make install" which installs the shared executables
in /usr/lib.

	-Bob Deroy
	 Boston University
	 Center for Remote Sensing

--
UUCP:	...!harvard!bu-cs!bu-it!rwd  INTERNET: rwd@bu-it.bu.edu
CSNET: rwd%bu-it@bu-cs  	       BITNET: engbd3c@buacca


From ucla-cs!usc!zaphod.mps.ohio-state.edu!uwm.edu!mailrus!purdue!decwrl!chico.pa.dec.com!klee Mon Jan  8 12:59:16 PST 1990
Subject: Re: Getting X11R4 up and running.
Status: O

Article 17058 of comp.windows.x:
Path: ucla-cs!usc!zaphod.mps.ohio-state.edu!uwm.edu!mailrus!purdue!decwrl!chico.pa.dec.com!klee
>From: klee@chico.pa.dec.com (Ken Lee)
Newsgroups: comp.windows.x
Subject: Re: Getting X11R4 up and running.
Message-ID: <2398@bacchus.dec.com>
Date: 5 Jan 90 02:14:55 GMT
References: <12670@phoenix.Princeton.EDU>
Sender: news@decwrl.dec.com
Reply-To: klee@decwrl.dec.com
Organization: DEC Western Software Laboratory
Lines: 12

In article <12670@phoenix.Princeton.EDU>, reed@olympus.Berkeley.EDU writes:
> 		ld.so: libXmu.so.4: not found
> 
> I am compiling on a Sun Sparc with OS 4.0.3 using gcc.

Your shared libraries are broken or not set up properly.  Could be that
gcc doesn't do Sun-style shared libraries properly.

Ken Lee
DEC Western Software Laboratory, Palo Alto, Calif.
Internet: klee@decwrl.dec.com
uucp: uunet!decwrl!klee


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!keith Mon Jan  8 13:00:06 PST 1990
Subject: Re: problem starting X11R4; what's (not so) obvious?
Status: O

Article 17061 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!keith
>From: keith@EXPO.LCS.MIT.EDU (Keith Packard)
Newsgroups: comp.windows.x
Subject: Re: problem starting X11R4; what's (not so) obvious?
Message-ID: <9001050247.AA11553@expo.lcs.mit.edu>
Date: 5 Jan 90 02:47:14 GMT
References: <1130@ursa-major.SPDCC.COM>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 21


> Symptom: "xinit" invoked manually from another terminal brings up the
> gray stipple and mouse cursor, but then terminates with no errors other
> than "waiting for X server to terminate.." which it then does.  I
> suspect that "xterm" is failing, but I'm not sure where to look next.
> There are no messages betraying why it's failing.

xinit is a pretty awful program to use when debugging things like this; when
you've got a remote terminal to debug with, I'd suggest starting the server
by hand and then try to run xterm (also by hand):

$ /usr/bin/X11/Xqdss &
(wait until the cursor appears)
$ setenv DISPLAY :0
$ /usr/bin/X11/xterm

At this point, xterm has a chance to display the troubles it's having and
give more meaningful error messages.

Keith Packard
MIT X Consortium


From ucla-cs!usc!cs.utexas.edu!mailrus!ncar!groucho!davis Mon Jan  8 13:00:29 PST 1990
Subject: Re: Getting X11R4 up and running.
Status: O

Article 17064 of comp.windows.x:
Path: ucla-cs!usc!cs.utexas.edu!mailrus!ncar!groucho!davis
>From: davis@groucho.ucar.edu (Glenn P. Davis)
Newsgroups: comp.windows.x
Subject: Re: Getting X11R4 up and running.
Message-ID: <5895@ncar.ucar.edu>
Date: 5 Jan 90 03:14:41 GMT
References: <12670@phoenix.Princeton.EDU> <RUSTY.90Jan4173234@garnet.berkeley.edu>
Sender: news@ncar.ucar.edu
Reply-To: davis@groucho.UCAR.EDU (Glenn P. Davis)
Organization: Unidata/UCAR, Boulder CO
Lines: 12

> ld.so: libXmu.so.4: not found

You need to run '/usr/etc/ldconfig' (or wait for cron to do it) on
the workstation where you attempting the compile, after you have installed
a new version of a shareable lib.

Glenn P. Davis
UCAR / Unidata
PO Box 3000                   1685 38th St.
Boulder, CO 80307-3000        Boulder, CO  80301

(303) 497 8643


From ucla-cs!usc!snorkelwacker!bloom-beacon!THINK.COM!rlk Mon Jan  8 13:07:53 PST 1990
Subject: X11R4 -- congratulations!
Status: O

Article 17115 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!THINK.COM!rlk
>From: rlk@THINK.COM (Robert L. Krawitz)
Newsgroups: comp.windows.x
Subject: X11R4 -- congratulations!
Message-ID: <9001051925.AA15747@underprize.think.com>
Date: 5 Jan 90 19:25:14 GMT
Sender: rlk@think.com
Organization: The Internet
Lines: 17

I'm up and running with X11R4 on my Sparcstation, and I must say that
this is really zippy compared to R3.

I had very few problems (modulo a few NFS timeouts, a botched attempt to
put the distribution somewhere other than /usr/???/X11, and the like).
Note that it is essential to run ldconfig (on Suns running 4.0) before
attempting to use R4, due to the shared libraries.

A few minor incompatibilities:  specifying xterm*utmpInhibit: on or
xterm*titlebar: off causes xterm to fail to come up and to exit after a
few seconds with status 0.

All in all, I'm very happy with it!

ames >>>>>>>>>  |	Robert Krawitz <rlk@think.com>	245 First St.
bloom-beacon >  |think!rlk	(postmaster)		Cambridge, MA  02142
harvard >>>>>>  .	Thinking Machines Corp.		(617)876-1111


From ucla-cs!usc!apple!bionet!turbo.bio.net!lear Mon Jan  8 13:10:59 PST 1990
Subject: Re: Getting X11R4 up and running.
Status: O

Article 17145 of comp.windows.x:
Path: ucla-cs!usc!apple!bionet!turbo.bio.net!lear
>From: lear@turbo.bio.net (Eliot Lear)
Newsgroups: comp.windows.x
Subject: Re: Getting X11R4 up and running.
Message-ID: <Jan.5.17.56.34.1990.11511@turbo.bio.net>
Date: 6 Jan 90 01:56:34 GMT
References: <12670@phoenix.Princeton.EDU> <9001051308.AA03313@expire.lcs.mit.edu>
Organization: GenBank Computing Resource for Mol. Biology
Lines: 10

Let me just post one caveat that I ran into.  When I first started up,
I wanted to leave the sharable libraries in /usr/lib/X11, as opposed
to placing them in /usr/lib or /usr/local/lib.  To do this, one would
presume you could simply set the variable LD_LIBRARY_PATH, and go on,
but this turns out not to be the case, as a number of the programs,
and in particular Xterm, are setuid.  When a program is setuid, ld.so
will ignore the environment variable for security reasons.
-- 
Eliot Lear
[lear@turbo.bio.net]


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws Mon Jan  8 13:16:02 PST 1990
Subject: Re: can't make libXt.a
Status: O

Article 17078 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
>From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: can't make libXt.a
Message-ID: <9001051243.AA03269@expire.lcs.mit.edu>
Date: 5 Jan 90 12:43:43 GMT
References: <9001050017.AA09335@garnet.berkeley.edu>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 27


    make: Fatal error: Don't know how to make target `stdarg.h'

You should have gotten an earlier complaint from makedepend about not
finding stdarg.h.

Why it didn't find stdarg.h:

My guess is that your gcc include files are in a different place than
makedepend expects.  makedepend tries to find them in
	/usr/local/lib/gcc-include
If yours are in a different place, go edit line 197 of util/makedepend/main.c.
(Yes, we know this should be configurable; it got fixed too late in the cycle.)
Rebuild makedepend, try running "make depend" in the lib/Xt directory again,
and see if it stops complaining.

Why it even tried to find stdarg.h:

Support for using multiple compilers is imperfect. (You're using cc for
the libraries, to make them shareable, and gcc for the rest.)  makedepend
inherits its attributes from whatever compiler is used to build it; in
this case, gcc.  Those attributes are then applied when building all
dependencies, even for directories that will be using a different compiler.
gcc defines __STDC__, which means dependencies (e.g. the varargs stuff in
Xt) will get done differently than for cc.  Normally this shouldn't be a
problem, since typically only system include files are involved, and they
rarely change.


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws Mon Jan  8 13:16:50 PST 1990
Subject: Re: can't make libXt.a
Status: O

Article 17080 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
>From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: can't make libXt.a
Message-ID: <9001051255.AA03285@expire.lcs.mit.edu>
Date: 5 Jan 90 12:55:46 GMT
References: <43178@lll-winken.LLNL.GOV>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 9


    What is SaberC?

"Saber-C is an interpreter-based programming environment for the C language".
It's simply mahvelous for debugging; our toolkit people use it all the time.

    Does it matter in compiling the core distribution?

No, it simply adds some stuff to the Makefiles that Saber can use for loading.


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!keith Mon Jan  8 16:11:09 PST 1990
Subject: Re: What are we doing wrong?
Status: O

Article 17039 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!keith
>From: keith@EXPO.LCS.MIT.EDU (Keith Packard)
Newsgroups: comp.windows.x
Subject: Re: What are we doing wrong?
Message-ID: <9001042326.AA03869@xenon.lcs.mit.edu>
Date: 4 Jan 90 23:26:16 GMT
References: <2511@jato.Jpl.Nasa.Gov>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 14


Sounds like you haven't used the gcc shell script 'fixincludes' which
whacks the system header files to make them work with an ansi compiler.

When building R3, most people used -traditional for the server; R4 no
longer needs that flag, except for the system header files (which use
a rather broken mechanism to specify the arguments to ioctl).  Run
fixincludes and rebuild server/ddx/sun, lib/X, clients/xterm and any
other portion you built with gcc and which uses ioctl.

Good luck!

Keith Packard
MIT X Consortium


From ucla-cs!usc!snorkelwacker!mit-eddie!bbn!diamond.bbn.com!mlandau Mon Jan  8 16:14:28 PST 1990
Subject: Faster version of lndir
Status: O

Article 17150 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!mit-eddie!bbn!diamond.bbn.com!mlandau
>From: mlandau@bbn.com (Matt Landau)
Newsgroups: comp.windows.x
Subject: Faster version of lndir
Message-ID: <13335@garnet.BBN.COM>
Date: 6 Jan 90 01:31:51 GMT
Distribution: comp
Organization: BBN Systems and Technologies Corporation, Cambridge, MA
Lines: 126

The idea of using lndir to create a tree of links to the X11R4 sources
for compilation on different machines is a nice one, but when you try
to put it into practice, you find that lndir is painfully slow (being
a recursive shell script and all... :-)

Here's a program that does the same thing, using the same syntax, but
running about 3 times faster because it's written in C.  (It's still
too slow, but profiling shows that most of the time is spent in the
symlink system call, and I don't really know how to speed that up...)

Caveat user: this program is a quick little hack because I needed
something that would build a link tree in 45 minutes instead of 2.5
hours.  It works on my Suns and VAXen, and hasn't been tested on
anything else.  It probably won't work on an Amiga, which doesn't 
have ".." directories :-)

Share and enjoy...
--
 Matt Landau			Waiting for a flash of enlightenment
 mlandau@bbn.com			  in all this blood and thunder


------------------------ Cut here to get linktree.c ---------------------

/*
 * The program builds a tree of symbolic links, like the X11R4 lndir.sh
 * script, but much faster.  Share and Enjoy...
 *
 *				- Matt Landau  (mlandau@bbn.com)
 *				  BBN Systems and Technologies Corp.
 *				  1/6/90
 */

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/dir.h>
#include <sys/param.h>

static int is_directory(name, sp)
char *name;
struct stat *sp;
{   

    if (stat(name, sp) < 0)
    {   
	perror(name);
	return (0);
    }
    return (sp->st_mode & S_IFDIR);
}


static void link_dir(from_name, to_name)
char *from_name, *to_name;
{   
    struct stat s1, s2;
    DIR *dir;
    struct direct *dir_entry;
    char name[MAXPATHLEN];
    char src_path[MAXPATHLEN], dst_path[MAXPATHLEN];
    
    if (!is_directory(from_name, &s1) || !is_directory(to_name, &s2))
	return;

    if (s1.st_dev == s2.st_dev && s1.st_ino == s2.st_ino)
    {   
	fprintf(stderr, "%s and %s are identical\n", from_name, to_name);
	return;
    }
    
    if ((dir = opendir(from_name)) == NULL)
    {   
	perror(from_name);
	return;
    }
    
    printf("%s:\n", from_name);
    while ((dir_entry = readdir(dir)) != NULL)
    {   
	strcpy(name, dir_entry->d_name);
	if (!strcmp(name, ".") || !strcmp(name, ".."))
	    continue;
	sprintf(src_path, "%s/%s", from_name, name);
	if (!is_directory(src_path, &s1))
	{   
	    sprintf(dst_path, "%s/%s", to_name, name);
	    if (symlink(src_path, dst_path) < 0)
		perror(dst_path);
	}
	else
	{   
	    sprintf(dst_path, "%s/%s", to_name, name);
	    if (mkdir(dst_path, 0777) < 0)
	    {   
		perror(dst_path);
		continue;
	    }
	    if (chdir(dst_path) < 0)
	    {   
		perror(dst_path);
		continue;
	    }
	    sprintf(src_path, "../%s/%s", from_name, name);
	    link_dir(src_path, ".");
	    if (chdir("..") < 0)
	    {   
		perror("Panic!  Cannot return to parent directory");
		exit(2);
	    }
	}
    }
}

	
main(argc, argv)
int argc;
char *argv[];
{   
    if (argc != 2)
    {
	fprintf(stderr, "usage: %s from\n", argv[0]);
	exit(1);
    }
    link_dir(argv[1], ".");
}


From ucla-cs!usc!zaphod.mps.ohio-state.edu!think!mintaka!bloom-beacon!EXPO.LCS.MIT.EDU!rws Mon Jan  8 16:17:17 PST 1990
Subject: Re: Can some explain shared libs?
Status: O

Article 17283 of comp.windows.x:
Path: ucla-cs!usc!zaphod.mps.ohio-state.edu!think!mintaka!bloom-beacon!EXPO.LCS.MIT.EDU!rws
>From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: Can some explain shared libs?
Message-ID: <9001081700.AA00895@expire.lcs.mit.edu>
Date: 8 Jan 90 17:00:49 GMT
References: <1990Jan6.050638.1097@agate.berkeley.edu>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 25


    There is nothing I've found in the X documentation 
    that really explains the difference.

There is nothing about X that is particularly special wrt shared libraries.

    Is there any difference in run-time memeory use (RAM) by programs that use
    shared libraries?

Yes, if you run different clients using a given shared library, they will
share the library text and data.  If you link the library statically into
each client, the code and data gets replicated.  The tradeoff depends on
how much of the library each client uses (one copy of the entire library,
vs. several pieces of the library).  In general, for the X libraries, I
suspect the shared form is better.

    Can I, as an application programmer, use these libraries,

Of course.

    and is there any difference in the linking syntax,
    or for that matter the code I must write?

No.  There are differences in how dependencies are specified, but if you
use Imakefiles, everything is taken care of for you.


From ucla-cs!usc!zaphod.mps.ohio-state.edu!think!mintaka!bloom-beacon!EXPO.LCS.MIT.EDU!rws Mon Jan  8 16:20:10 PST 1990
Subject: Re: error in sunCG3.c
Status: O

Article 17196 of comp.windows.x:
Path: ucla-cs!usc!zaphod.mps.ohio-state.edu!think!mintaka!bloom-beacon!EXPO.LCS.MIT.EDU!rws
>From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: error in sunCG3.c
Message-ID: <9001061924.AA09173@expo.lcs.mit.edu>
Date: 6 Jan 90 19:24:23 GMT
References: <9001060537.AA09821@expo.lcs.mit.edu>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 8

If you upgraded to SunOS 4.0.3, you wouldn't have this problem.
I don't have an official fix for you, but someone else has suggested
adding these to sunCG3C.c if your build fails:

#define CG3AC_MONOLEN (128*1024)
#define CG3AC_ENBLEN  CG3AC_MONOLEN
#define CG3BC_MONOLEN CG3AC_MONOLEN
#define CG3BC_ENBLEN  CG3AC_MONOLEN


From ucla-cs!usc!samsung!think!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!keith Mon Jan  8 16:22:04 PST 1990
Subject: Re: error in sunCG3.c
Status: O

Article 17163 of comp.windows.x:
Path: ucla-cs!usc!samsung!think!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!keith
>From: keith@EXPO.LCS.MIT.EDU (Keith Packard)
Newsgroups: comp.windows.x
Subject: Re: error in sunCG3.c
Message-ID: <9001060537.AA09821@expo.lcs.mit.edu>
Date: 6 Jan 90 05:37:19 GMT
References: <9001060116.AA26239@NMSU.Edu>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 18


Sun 3's don't ever have CG3 displays, they only exist on 386i and sun4
machines.  Thus, the CG3 does not even have header files under sunOS 3.5 on
your sun 3/60.  To temporarily avoid the problem, hack the sources as
follows:

Trivial fix:

	Remove sunCG3.o from the Imakefile
	Remove the CG3 related lines from sunInit.c (i.e. lines
	which contain 'CG3' in them).

	remake the Makefile (make Makefile; make depend)

	remake the directory (make)

Keith Packard
MIT X Consortium


From ucla-cs!usc!samsung!aplcen!haven!umd5!steveg Mon Jan  8 16:27:53 PST 1990
Subject: Possible bug in server code?
Status: O

Article 17185 of comp.windows.x:
Path: ucla-cs!usc!samsung!aplcen!haven!umd5!steveg
>From: steveg@umd5.umd.edu (Steve Green)
Newsgroups: comp.windows.x
Subject: Possible bug in server code?
Message-ID: <5883@umd5.umd.edu>
Date: 6 Jan 90 17:25:26 GMT
Reply-To: steveg@umd5.umd.edu (Steve Green)
Organization: University of Maryland, College Park
Lines: 7

in server/ddx/mi/mispritest.h

		      . should this not be y1??
#define LINE_SORT(x1,y2,x2,y2) \
{ int _t; \
  if (x1 > x2) { _t = x1; x1 = x2; x2 = _t; } \
  if (y1 > y2) { _t = y1; y1 = y2; y2 = _t; } }


From ucla-cs!uci-ics!jarthur!bridge2!mips!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!rusty Mon Jan  8 16:29:43 PST 1990
Subject: Re: xtools & x11r4 & sunos 4.0.3
Status: O

Article 17232 of comp.windows.x:
Path: ucla-cs!uci-ics!jarthur!bridge2!mips!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!rusty
>From: rusty@garnet.berkeley.edu
Newsgroups: comp.windows.x
Subject: Re: xtools & x11r4 & sunos 4.0.3
Message-ID: <RUSTY.90Jan6211234@garnet.berkeley.edu>
Date: 7 Jan 90 05:12:34 GMT
References: <9001070016.AA12530@garnet.berkeley.edu>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: /garnet_a/rusty/.organization
Lines: 27
In-reply-to: rusty@GARNET.BERKELEY.EDU's message of 7 Jan 90 00:16:24 GMT

In article <9001070016.AA12530@garnet.berkeley.edu> rusty@GARNET.BERKELEY.EDU writes:

   Path: ucbvax!GARNET.BERKELEY.EDU!rusty
   From: rusty@GARNET.BERKELEY.EDU
   Newsgroups: comp.windows.x
   Subject: xtools & x11r4 & sunos 4.0.3
   Date: 7 Jan 90 00:16:24 GMT
   Sender: daemon@ucbvax.BERKELEY.EDU
   Lines: 9

   I can't seem to get xtools to work on my sparcstation.  It compiles
   fine but when I try to run it dies with

   ld.so: Undefined symbol: _XtToolkitInitialize

   It doesn't matter whether I use gcc or cc.  It does work if I link it
   with -Bstatic.

The problem was because I when made symbolic links from where the X
libraries are to /usr/local/lib I made links for the .a and the .so
files but I neglected to make them for the .sa files.  Nyah, just a
minor detail.
--

--------------------------------------
	rusty c. wright
	rusty@violet.berkeley.edu ucbvax!violet!rusty


From ucla-cs!usc!bbn!diamond.bbn.com!mlandau Mon Jan  8 16:35:51 PST 1990
Subject: Re: Faster version of lndir
Status: O

Article 17264 of comp.windows.x:
Path: ucla-cs!usc!bbn!diamond.bbn.com!mlandau
>From: mlandau@bbn.com (Matt Landau)
Newsgroups: comp.windows.x
Subject: Re: Faster version of lndir
Message-ID: <13338@garnet.BBN.COM>
Date: 8 Jan 90 03:54:07 GMT
References: <13335@garnet.BBN.COM>
Distribution: comp
Organization: BBN Systems and Technologies Corporation, Cambridge, MA
Lines: 3

Yes, Virginia, you DO need to add a "closedir(dir)" at the end of 
the link_dir routine, outside the while loop, lest you run out of 
file descriptors when building a copy of then entire X11 tree...


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws Mon Jan  8 16:39:20 PST 1990
Subject: warning about gcc 1.36 (on 680x0 only?)
Status: O

Article 17272 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
>From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: warning about gcc 1.36 (on 680x0 only?)
Message-ID: <9001081420.AA00672@expire.lcs.mit.edu>
Date: 8 Jan 90 14:20:38 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 8

>From a bug report:

    Versions 1.34 and 1.36 of GCC incorrectly compile the expression
    ``"..." == 0 ? exp1 : exp2'' into "exp1".

This expression is used by XtNewString (in lib/Xt/Intrinsic.h).

(As I stated before, we only tested R4 on gcc 1.35.)


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!keith Mon Jan  8 16:42:14 PST 1990
Subject: Re: xdm Imakefile needs DONT_USE_DEF
Status: O

Article 17231 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!keith
>From: keith@EXPO.LCS.MIT.EDU (Keith Packard)
Newsgroups: comp.windows.x
Subject: Re: xdm Imakefile needs DONT_USE_DEF
Message-ID: <9001070430.AA23068@expo.lcs.mit.edu>
Date: 7 Jan 90 04:30:29 GMT
References: <4578@helios.ee.lbl.gov>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 60


> The Imakefile for xdm is (IMHO) missing a preprocessor flag for the case
> where the machine does NOT have DES encryption.

> Here is a patch:

> *** xdm/Imakefile.orig	Wed Dec 13 12:26:21 1989
> --- xdm/Imakefile	Sat Jan  6 19:29:31 1990
> ***************
> *** 10,20
>   #if HasDESLibrary
>   DESDEFS = -DHASDES
>   DESOBJS = xdmauth.o
>   DESSRCS = xdmauth.c
>   #else
> ! DESDEFS = 
>   DESOBJS =
>   DESSRCS = 
>   #endif
>   
>      XDMCONFIGDIR = XdmConfigurationSubdirectory
> 
> --- 10,20 -----
>   #if HasDESLibrary
>   DESDEFS = -DHASDES
>   DESOBJS = xdmauth.o
>   DESSRCS = xdmauth.c
>   #else
> ! DESDEFS = -DDONT_USE_DES
>   DESOBJS =
>   DESSRCS = 
>   #endif
>   
>      XDMCONFIGDIR = XdmConfigurationSubdirectory
> 

This patch is not correct.  HASDES is defined for machines which have
implemented a client library which does DES in the way expected for
XDM-AUTHENTICATION-1 and XDM-AUTHORIZATION-1 authentication/authorization
schemes.  As no machines have such a library (the sample implementation
written here at MIT is not distributable outside of the US), HasDESLibrary
should always be false.

On the other hand, DONT_USE_DES is defined for machines which have neither
setkey/encrypt nor crypt in libc.  These functions are used to generate
cryptographically secure random numbers and do not depend on whether DES is
used in those functions, just that the perturb the bits around when called.
Machines which are exported from the US typically do not have any DES
routines at all (even for password checking) and so this option allows those
machines to use a less secure mechanism for generating the keys (less secure
is rather misleading in this context; without HASDES the only authorization
scheme supported is MIT-MAGIC-COOKIE-1 which passes these carefully crafted
cryptographically secure random numbers in the clear over the network).

If the commerce departement ever allows us to distribute DES implementations
(or even code which uses some other DES implementation), HASDES will become
useful, and session authorization will be more secure.

Keith Packard
MIT X Consortium


From ucla-cs!usc!cs.utexas.edu!sun-barr!newstop!texsun!convex!convex.com!datri Tue Jan  9 08:01:34 PST 1990
Subject: Error in R4 xtroff
Status: O

Article 17315 of comp.windows.x:
Path: ucla-cs!usc!cs.utexas.edu!sun-barr!newstop!texsun!convex!convex.com!datri
>From: datri@convex.com (Anthony A. Datri)
Newsgroups: comp.windows.x
Subject: Error in R4 xtroff
Message-ID: <4428@convex.UUCP>
Date: 8 Jan 90 12:41:40 GMT
Sender: usenet@convex.UUCP
Reply-To: datri@convex.com (Anthony A. Datri)
Organization: Convex Computer Corporation, Richardson, Tx.
Lines: 21


The xtroff found in the R4 contrib tree has a simple error (at least,
it looks like an error to me):

xwindows.c has a differing idea of capitalization than
mit/lib/Xaw/Scrollbar.c -- XawScrollbarSetThumb in xwindows.c vs.
XawScrollBarSetThumb in Scrollbar.c.

Simple fix:

34c34
< # define XtScrollBarSetThumb XawScrollbarSetThumb
---
> # define XtScrollBarSetThumb XawScrollBarSetThumb





(please forgive me if the diff isn't in the usual format; I've never
 had the nerve to post a patch before)


From ucla-cs!usc!brutus.cs.uiuc.edu!uakari.primate.wisc.edu!ames!amdahl!nsc!voder!zok!mark Tue Jan  9 08:09:08 PST 1990
Subject: rgb/Imakefile patch
Status: O

Article 17332 of comp.windows.x:
Path: ucla-cs!usc!brutus.cs.uiuc.edu!uakari.primate.wisc.edu!ames!amdahl!nsc!voder!zok!mark
>From: mark@zok.UUCP (Mark W. Snitily)
Newsgroups: comp.windows.x
Subject: rgb/Imakefile patch
Message-ID: <400@zok.UUCP>
Date: 9 Jan 90 06:56:56 GMT
Organization: The distant planet Zok
Lines: 35

The X11R4 mit/rgb/Imakefile has a glitch similar to the one in
mit/lib/Xt/Imakefile pointed out by Isaac Salzman (salzman@rand.org).

If the rgb database is not installed in /usr/lib/X11 the new destination
directory is not compiled into to rgb and showrgb.  Here's a patch to
mit/rgb/Imakefile that fixes the problem:

*** Imakefile.org	Sat Nov 18 12:44:51 1989
--- Imakefile	Mon Jan  8 13:28:56 1990
***************
*** 1,5 ****
        DEPLIBS = 
!       DEFINES = NdbmDefines
       INCLUDES = -I$(TOP) -I$(SERVERSRC)/include
   INSTALLFLAGS = $(INSTLIBFLAGS)
          SRCS1 = rgb.c
--- 1,11 ----
+ #ifdef DefaultRGBDatabase
+    SITE_RGB_DB = -DRGB_DB=\"DefaultRGBDatabase\"
+ #else
+    SITE_RGB_DB = /* as nothing */
+ #endif
+ 
        DEPLIBS = 
!       DEFINES = NdbmDefines $(SITE_RGB_DB)
       INCLUDES = -I$(TOP) -I$(SERVERSRC)/include
   INSTALLFLAGS = $(INSTLIBFLAGS)
          SRCS1 = rgb.c

-- Mark

Mark W. Snitily                 Consulting Services:
894 Brookgrove Lane             Graphics, Operating Systems, Compilers
Cupertino, CA 95014             (408) 252-0456
mark@zok.uucp


From ucla-cs!usc!cs.utexas.edu!sun-barr!newstop!sundc!npg@sundc.east.sun.com Tue Jan  9 08:11:46 PST 1990
Subject: Open {Windows,House} at UniForum and USENIX
Status: O

Article 17342 of comp.windows.x:
Path: ucla-cs!usc!cs.utexas.edu!sun-barr!newstop!sundc!npg@sundc.east.sun.com
>From: npg@sun.com (Neil Groundwater - Sun Consulting)
Newsgroups: comp.windows.x,comp.windows.news,comp.org.usenix
Subject: Open {Windows,House} at UniForum and USENIX
Message-ID: <10867@sundc.East.Sun.COM>
Date: 9 Jan 90 14:45:12 GMT
Sender: news@sundc.East.Sun.COM
Reply-To: npg@sundc.east.sun.com
Followup-To: comp.windows.x
Organization: Sun Microsystems, Vienna, VA
Lines: 16
Xref: ucla-cs comp.windows.x:17342 comp.windows.news:1928 comp.org.usenix:1370

The evening of January 23rd there will be an OpenWindows Open House at
the Ramada Renaissance, East Salon Ballroom, Techworld, 999 9th Street
NW, Washington, DC.  The Ramada is located near the Washington
Convention Center, the site of the UniForum show.  Come and talk to
Bill Joy and other Sun personnel about X11, NeWS, and Sun.  For more
information stop by the Sun booth at UniForum.

   ...Neil

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Neil Groundwater			ARPA    : npg@sun.com
Sun Microsystems, Inc.			Internet: npg@sundc.East.Sun.COM
8219 Leesburg Pike			Usenet  : ...!uunet!sun!sundc!npg
Suite #700				AT&T    : (703) 883-1221
Vienna, VA  22182			FAX     : (703) 893-0576
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


From ucla-cs!usc!brutus.cs.uiuc.edu!samsung!think!mintaka!bloom-beacon!EXPO.LCS.MIT.EDU!kit Wed Jan 10 13:59:38 PST 1990
Subject: Re: Error in R4 xtroff
Status: O

Article 17350 of comp.windows.x:
Path: ucla-cs!usc!brutus.cs.uiuc.edu!samsung!think!mintaka!bloom-beacon!EXPO.LCS.MIT.EDU!kit
>From: kit@EXPO.LCS.MIT.EDU (Chris D. Peterson)
Newsgroups: comp.windows.x
Subject: Re: Error in R4 xtroff
Message-ID: <9001091827.AA08935@expo.lcs.mit.edu>
Date: 9 Jan 90 18:27:06 GMT
References: <4428@convex.UUCP>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 27


> The xtroff found in the R4 contrib tree has a simple error (at least,
> it looks like an error to me):

This one is my fault.  I noticed just before R4 went out that the name of this
convience routine did not match the convention used by the rest of the Scrollbar
widget code, and changed it to be more consistent.  I figured that since the
name was already different, a small change would bite anyone.

Here is how the name changed:

R3:	XtScrollBarSetThumb()		R4:	XawScrollbarSetThumb()


> please forgive me if the diff isn't in the usual format...

We usually suggest using context diffs (diff -c) since they contain more
information.  You also need to include the name of the file that is to be
patched.


						Chris D. Peterson     
						MIT X Consortium 

Net:	 kit@expo.lcs.mit.edu
Phone:   (617) 253 - 9608	
Address: MIT - Room NE43-213


From ucla-cs!usc!snorkelwacker!bloom-beacon!ATHENA.MIT.EDU!swick Wed Jan 10 14:00:29 PST 1990
Subject: Re: "Standard" way of getting a widget name?
Status: O

Article 17351 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!ATHENA.MIT.EDU!swick
>From: swick@ATHENA.MIT.EDU (Ralph R. Swick)
Newsgroups: comp.windows.x
Subject: Re: "Standard" way of getting a widget name?
Message-ID: <9001091809.AA03544@lyre.MIT.EDU>
Date: 9 Jan 90 18:09:17 GMT
References: <900109063047.22e00127@CCC.NMFECC.GOV>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: DEC/MIT Project Athena
Lines: 18

> Is there some standard way of getting a widget name and/or classname?

In R4-based Xt, there is XtName().  No corresponding XtClassname(), though.

> Is dotting into the core widget structure sufficient

yep.

> could the
> core widget change in future releases?)

The order of the fields in the structure is not (any longer)
specified by the standard but the field names and datatypes are
and therefore will remain backward compatible.  Where standard
access functions/macros are defined (e.g. XtName(), XtClass())
it's probably still a good idea to use them rather than directly
referencing structure members.  Non-widgets should certainly
try to avoid referencing structure contents.


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!kit Wed Jan 10 14:01:19 PST 1990
Subject: Re: titles in twm's IconManager
Status: O

Article 17353 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!kit
>From: kit@EXPO.LCS.MIT.EDU (Chris D. Peterson)
Newsgroups: comp.windows.x
Subject: Re: titles in twm's IconManager
Message-ID: <9001091903.AA10311@expo.lcs.mit.edu>
Date: 9 Jan 90 19:03:54 GMT
References: <6520016@hpihoah.HP.COM>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 30


> I use the -n option, which specifies icon name for twm to use.

This option also changes the resource names so that the command:

xterm -name xclock

would match the following resources:

xclock*Background:		Blue
xclock*Foreground:		Red

instead of these:

xterm*Background:		Blue
xterm*Foreground:		Red

> Almost always, my -title and my -n string are the same, but it's nice to set
> them separately.

This is why ``title'' and ``name'' are seperate options, they really do
different things.


						Chris D. Peterson     
						MIT X Consortium 

Net:	 kit@expo.lcs.mit.edu
Phone:   (617) 253 - 9608	
Address: MIT - Room NE43-213


From ucla-cs!usc!samsung!think!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!kit Wed Jan 10 14:02:25 PST 1990
Subject: Re: app-defaults or xrdb?
Status: O

Article 17354 of comp.windows.x:
Path: ucla-cs!usc!samsung!think!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!kit
>From: kit@EXPO.LCS.MIT.EDU (Chris D. Peterson)
Newsgroups: comp.windows.x
Subject: Re: app-defaults or xrdb?
Message-ID: <9001091842.AA09507@expo.lcs.mit.edu>
Date: 9 Jan 90 18:42:29 GMT
References: <4468@hemuli.tik.vtt.fi>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 24


> Am I correct in assuming that you are supposed to achieve site-wide
> defaults by loading resources from some file via xinit or xdm, not by
> editing files in /usr/lib/X11/app-defaults? 

There is no reason not to modify the app-defaults file for site configurations,
that is what is was originally intended for.  Although, You may want to put in a
comment so that people know what you have done locally. 

>  I.e. the app-defaults
> files are to be considered part of the corresponding program's source
> code, and shouldn't be edited to provide site-wide settings.

The app-defaults file is certainly as important to many programs as the source
files, but many applications also have a ``config.h'' file that is also part of
the source...


						Chris D. Peterson     
						MIT X Consortium 

Net:	 kit@expo.lcs.mit.edu
Phone:   (617) 253 - 9608	
Address: MIT - Room NE43-213


From ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!decwrl!shelby!portia!jessica!stergios Wed Jan 10 14:04:53 PST 1990
Subject: Rename X man pages script & add extra man references
Status: O

Article 17363 of comp.windows.x:
Path: ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!decwrl!shelby!portia!jessica!stergios
>From: stergios@jessica.Stanford.EDU (stergios marinopoulos)
Newsgroups: comp.windows.x
Subject: Rename X man pages script & add extra man references
Summary: long man page names, all citings
Keywords: long man page names, all citings
Message-ID: <8081@portia.Stanford.EDU>
Date: 9 Jan 90 19:09:10 GMT
Sender: USENET News System <news@Portia.stanford.edu>
Reply-To: stergios@jessica.Stanford.EDU (stergios marinopoulos)
Organization: Stanford University
Lines: 63

#! /bin/csh -f

# cxml - Create X Manual Links
#
# create links to X manual pages with long file names, and with all cited
# similar topics.
#
# cxml < X man source directory >
#
# To run, cd to the directory where you want the links created.
# Run this shell script with an argument of where the X man pages are.
# For example:
#
#	(cd /usr/local/man/man3 ; cxml /usr/local/X11R4/man/man3)
#
# BUGS: if an item is cited in more than one man page then only
# 	the first citation is used.  This may cause errors messages
#	from ln, but you may disregard them: I know I do.
#
#	You might have to replace "cut" with an appropriate command
#	on your system.
#
# Enjoy, Stergios Marinopoulos
#
# stergios@jessica.stanford.edu
#
#

if ( $#argv != 1 ) then
	echo usage:  cxml \<X man source directory\>
	exit 1
endif

if ( ! -d $1 ) then
	echo bad man source directory: $1
	exit 1
endif

set sourcedir = $1
set length

foreach file ($sourcedir/*)

echo $file
set suffix = $file:e

set startline = `egrep -n ".SH NAME" $file`
set startline = `echo $startline | cut -d: -f1`
@ startline += 1

set endline = `egrep -n ".SH SYNTAX"\|".SH STRUCTURES" $file`
set endline = `echo $endline | cut -d: -f1`

@ length = $endline - $startline

set names = `tail +${startline} $file | head -${length} | tr -d "," `

	foreach name ($names)
	if ( $name == "\-" || $name == "\" ) break
	echo "         " ${name}
	ln -s $file ${name}.${suffix}
	end
end


From ucla-cs!usc!cs.utexas.edu!jarvis.csri.toronto.edu!helios.physics.utoronto.ca!ists!mike Wed Jan 10 14:05:43 PST 1990
Subject: If you install outside of /usr ... (Xmu Imakefile bug)
Status: O

Article 17369 of comp.windows.x:
Path: ucla-cs!usc!cs.utexas.edu!jarvis.csri.toronto.edu!helios.physics.utoronto.ca!ists!mike
>From: mike@ists.ists.ca (Mike Clarkson)
Newsgroups: comp.windows.x
Subject: If you install outside of /usr ... (Xmu Imakefile bug)
Message-ID: <3959@ists.ists.ca>
Date: 9 Jan 90 21:17:46 GMT
Organization: Institute for Space and Terrestrial Science
Lines: 29

It looks like the location of the bitmaps files is hardwired into
mit/lib/Xmu/Imakefile, with no corresponding rule in the templates.
If you install outside the  normal place, then you'll need to add these:

In mit/lib/Xmu/Imakefile, add

7a8,13
> #ifdef BitmapDir
>       BITMAPDIR = BitmapDir
>         DEFINES = -DBITMAPDIR=\"$(BITMAPDIR)\"
> #endif BitmapDir
> 
> 

and in site.def, add

#define BitmapDir $(INCDIR)/bitmaps

or whatever.



Mike.

-- 
Mike Clarkson					mike@ists.ists.ca
Institute for Space and Terrestrial Science	uunet!attcan!ists!mike
York University, North York, Ontario,		FORTRAN - just say no. 
CANADA M3J 1P3					+1 (416) 736-5611


From ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!hplabsz!dayoung Wed Jan 10 14:10:19 PST 1990
Subject: Example Motif Programs
Status: O

Article 17382 of comp.windows.x:
Path: ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!hplabsz!dayoung
>From: dayoung@hplabsz.HPL.HP.COM (Doug A. Young)
Newsgroups: comp.windows.x
Subject: Example Motif Programs
Message-ID: <4607@hplabsz.HPL.HP.COM>
Date: 9 Jan 90 22:09:42 GMT
Reply-To: dayoung@hplabsz.hp.com (Doug A. Young)
Organization: Hewlett-Packard Laboratories
Lines: 15

I've just placed the sources to the examples from the Motif edition of
my Xt book on expo. It is in ~ftp/contrib/young.motif.tar.Z. Once you
retrieve the code, uncompressing and untarring the file will create a
directory for each chapter in the book, along with a short README, a
master Makefile, etc. The book is supposed to become available this
week, although I've not yet seen a copy myself.  Quantum Books in
Cambridge (617-494-5042) is hoping to have a supply on hand for the X
conference next week. I appreciate the fact that Prentice Hall has
continued to allow (and encourage) me to make this code freely
available. Feel free to redistribute it to any other locations that
would be appropriate. I'd appreciate bug reports, which can be sent to
me at dayoung@hplabs.hp.com. I'll try to update the files periodically
if any significant bugs or problems turn up.

Doug Young


From ucla-cs!usc!venera.isi.edu!raveling Wed Jan 10 14:12:55 PST 1990
Subject: Code for quantization algorithm
Status: O

Article 17385 of comp.windows.x:
Path: ucla-cs!usc!venera.isi.edu!raveling
>From: raveling@isi.edu (Paul Raveling)
Newsgroups: comp.graphics,comp.windows.x
Subject: Code for quantization algorithm
Message-ID: <11309@venera.isi.edu>
Date: 10 Jan 90 00:38:43 GMT
Sender: news@venera.isi.edu
Reply-To: raveling@isi.edu (Paul Raveling)
Organization: USC Information Sciences Institute
Lines: 30
Xref: ucla-cs comp.graphics:9808 comp.windows.x:17385


	To answer what's quickly becoming a common request, C
	code for the new color quantization algorithm I described
	WILL be publicly available, but probably not until about
	the start of February.

	Before being unleashed, it needs some final detailing
	and more testing.  It'll be merged into an updated copy
	of the Img Software set that should also fix some minor
	bugs in the copy distributed with X11R4.


	Since about 50% of the email requests I've received asks
	about PC's, please note that one of those unfinished details
	is trying out 5-bit and 4-bit prequantization, instead of
	6-bit.  This could shrink a 1 megabyte color pointer array
	to 128K or 16K, respectively.  Another detail on PC's is
	that certain critical code uses if/then/else logic that
	flies on my 68K-based workstation, but it'll bog an 80x86
	down badly due to queue flushes.

	Performance loss due to queue flushes will probably be
	about a factor of 10 in critical per-pixel logic.  I'm sure
	not everyone with an 80x86 is ready to buy something better,
	so I'll (again) sweat some blood to minimize flushing.


----------------
Paul Raveling
Raveling@isi.edu


From ucla-cs!usc!cs.utexas.edu!asuvax!ncar!ames!ai.etl.army.mil!mike Wed Jan 10 14:20:27 PST 1990
Subject: problem compiling InterViews under R4
Status: O

Article 17455 of comp.windows.x:
Path: ucla-cs!usc!cs.utexas.edu!asuvax!ncar!ames!ai.etl.army.mil!mike
>From: mike@ai.etl.army.mil (Mike McDonnell)
Newsgroups: comp.windows.x
Subject: problem compiling InterViews under R4
Keywords: InterViews R4
Message-ID: <391@ai.etl.army.mil>
Date: 10 Jan 90 17:49:54 GMT
Organization: USAETL, Fort Belvoir, Virginia
Lines: 23


When I compile InterViews, I get type clashes for all the
src/libInterViews/X11-*.c functions.  A small section of the voluminous
error printout is:

compiling ../X11-bitmap.c
rm -f X11-bitmap.o
CC -c    -I.. -I../Generated -I../../.././src/InterViews/Std -I../../.././src    ../X11-bitmap.c
In file included from ../../.././src/InterViews/X11/painterrep.h:31, from ../X11-bitmap.c:30:
../../.././src/InterViews/X11/Xlib.h:244: conflicting types for `void XCloseDisplay (struct _XDisplay *)'
../../.././src/InterViews/X11/Xlib.h:253: conflicting types for `void XSetScreenSaver (struct _XDisplay *, int, int, int, int)'
../../.././src/InterViews/X11/Xlib.h:254: conflicting types for `void XForceScreenSaver (struct _XDisplay *, int)'
../../.././src/InterViews/X11/Xlib.h:255: conflicting types for `void XActivateScreenSaver (struct _XDisplay *)'


So where is the problem with conflicting types coming from?  Things compiled 
okay under X11 rel. 3.  Did some of the X11 include files change from release
3 or what? 

I'm using g++ 1.36.1 as my "CC".  Thanks for any help.
-- 
Mike McDonnell at the U.S. Army Engineer Topographic Laboratories, Bldg. 2592
Fort Belvoir, VA 22060-5546   TEL:(202)355-2716   NET: mike@etl.army.mil


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!jim Thu Jan 11 09:53:57 PST 1990
Subject: Re: twm bitmap file path
Status: O

Article 17489 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!jim
>From: jim@EXPO.LCS.MIT.EDU (Jim Fulton)
Newsgroups: comp.windows.x
Subject: Re: twm bitmap file path
Message-ID: <9001111421.AA03276@kanga.lcs.mit.edu>
Date: 11 Jan 90 14:21:06 GMT
References: <9001102303.AA14497@NMSU.Edu>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: X Consortium, MIT Laboratory for Computer Science
Lines: 8


You would typically set it in the resources that get loaded into the 
server with xrdb.  For example, if your resources file were called .Xres:

	%  cat >>.Xres
	bitmapFilePath:  /users/jim/icons:/x/include/bitmaps
	^D
	%  xrdb -load .Xres


From ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!mstar!mstar.morningstar.com!bob Thu Jan 11 18:21:05 PST 1990
Subject: xcpustate - helpful label
Status: O

Article 17510 of comp.windows.x:
Path: ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!mstar!mstar.morningstar.com!bob
>From: bob@MorningStar.Com (Bob Sutterfield)
Newsgroups: comp.windows.x
Subject: xcpustate - helpful label
Message-ID: <BOB.90Jan11130329@volitans.MorningStar.Com>
Date: 11 Jan 90 18:03:29 GMT
Sender: news@MorningStar.COM (USENET Administrator)
Reply-To: bob@MorningStar.Com (Bob Sutterfield)
Organization: Morning Star Technologies
Lines: 18

This makes a pile of xcpustate bars (each running on a different
machine) easier to decipher:

*** X.V11R4/contrib/clients/xcpustate/s-bsd.c.dist      Thu Jan  4 18:28:06 1990
--- X.V11R4/contrib/clients/xcpustate/s-bsd.c   Thu Jan 11 12:56:25 1990
***************
*** 33,38 ****
--- 33,43 ----
  {
      static char *name[] = {"CPU states"};

+     if ((gethostname(name[0], MAXHOSTNAMELEN)) < 0)
+       {
+         perror("gethostname");
+       }
+
      return name;
  }


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws Thu Jan 11 18:23:11 PST 1990
Subject: new R4 ERRATA file
Status: O

Article 17524 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
>From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: new R4 ERRATA file
Message-ID: <9001112011.AA06456@expire.lcs.mit.edu>
Date: 11 Jan 90 20:11:29 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 136

A revised R4 ERRATA file has been placed on expo; here it is.  Most of this
has already been discussed on xpert, although you may find a few things you
missed.  Please note that any source code changes described will come out as
"official" patches in the future, so if you make them now, be prepared for
patch failures later.  The file by no means describes everything we know
that's wrong with R4. :-)



			     R4 Errata


1.  You are building servers on 680x0 or VAX platforms, you should probably
    use GCC if you have it, especially for the server.  However, please note
    that the system has only been tested with gcc version 1.35.  It is known
    that the XtNewString macro in Xt miscompiles under gcc 1.36.  It is also
    known that some parts of the system miscompile under gcc 1.36 on the SPARC.
    Make sure you have run "fixincludes" from the gcc distribution before you
    build the system, or ioctl() calls will miscompile.  If you have installed
    your gcc-include files somewhere besides /usr/local/lib/gcc-include, you
    will have to edit line 197 of the file mit/util/makedepend/main.c to
    point at the proper directory.


2.  If you are trying to install library files into a directory other than
    /usr/lib/X11, you'll need to change XFILESEARCHPATHDEFAULT and ERRORDB
    in the file mit/lib/Xt/IntrinsicI.h to point at the correct directories.
    You'll also need to change SYSTEM_INIT_FILE in mit/clients/twm/parse.c.
    You'll also need to add the following line to mit/lib/Xmu/Imakefile:

	DEFINES = -DBITMAPDIR=\"$(INCDIR)/bitmaps\"


3.  Do not turn on InstallXdmConfig as there is no longer a default directory
    under mit/clients/xdm/config/.  Install xdm configuration files by hand.


4.  Some versions of tcsh erroneously set the eighth bit on characters they 
    emit.  If you are not seeing text in your xterm windows and are using 
    tcsh, try using a different shell (e.g. xterm -e /bin/sh).


5.  Sites running BSD 4.3 on vaxes will need to enable the qvss and/or qdss
    servers and will need to specify -DX11R4 in the ServerDefines line in
    mit/config/bsd.cf if building the qdss server:

	#ifdef VaxArchitecture
	#define XqvssServer Xqvss
	#define XqdssServer Xqdss
	#define ServerDefines StandardDefines ExtensionDefines -DXDMCP -DNOSTDHDRS -DX11R4
	#endif


6.  If you are building on a macII without gcc, you need to define CcCmd in 
    mit/config/macII.cf as follows:

	#define CcCmd	cc -B /usr/lib/big/

7.  If you are building on a vax, the lucida typewriter fonts will not
    display correctly.  To correct this, change line 410 of the file
    mit/fonts/bdftosnf/fontutil.c from:

	inwidth = GLWIDTHBYTESPADDED (pCI->metrics.characterWidth, glyphPad);

    to:

	inwidth = GLWIDTHBYTESPADDED (pCI->metrics.rightSideBearing -
				      pCI->metrics.leftSideBearing, glyphPad);


8.  If you are building with shared libraries on a Sun (we suggest that you
    do), remember that you need to run "ldconfig" as root after installing
    the shared libraries.  While building and installing the distribution,
    you need to be careful to avoid linking against any existing X shared
    libraries you might have (e.g. those distributed with OpenWindows).  You
    should make sure you do not have LD_LIBRARY_PATH set in your environment
    during the build or the installation.  If you are going to keep xterm and
    xload as setuid programs, please note that the shared libraries must be
    installed in /usr/lib or /usr/5lib for these programs to work (or else 
    those programs must be linked statically).


9.  The IBM server does run on the RT under AIX.  It should work under AOS
    on the RT, and under AIX on the PS/2.


10. Make sure your own resource files don't try to specify xterm geometry with
	xterm*geometry: <...>
    This will cause menu geometries to be incorrect.  Instead, use one of:
	xterm.geometry: <...>
	xterm*VT100.geometry: <...>
    The same problem may exist with other clients.


11. Various R3 clients will get protocol errors when run against an R4 server.
    If you need to run these clients without fixing them, try "xset bc".


12.  When the "utmpInhibit" resource is turned on, xterm exits with no error
     message.  To fix, change lines 1784 and 1785 of mit/clients/xterm/main.c
     to:
	if ((pw = getpwuid(screen->uid)) &&
	    !resource.utmpInhibit &&
     Also change line 1855 to read:
	if (geteuid() == 0 && pw)


13.  If you are building the server on an old SunOS (e.g. 3.5), you will have
     to add the following defines to mit/server/ddx/sun/sunCG3C.c to get it
     to compile:

	#define CG3AC_MONOLEN (128*1024)
	#define CG3AC_ENBLEN  CG3AC_MONOLEN
	#define CG3BC_MONOLEN CG3AC_MONOLEN
	#define CG3BC_ENBLEN  CG3AC_MONOLEN


14.  The twm feature to use window borders to highlight the active window is
     broken.  The fix is to replace lines 2458-2471 of 
     mit/clients/twm/menus.c with the following:

	if (onoroff) {
	    XSetWindowBorder (dpy, tmp->frame, tmp->border);
	    if (tmp->title_w)
	      XSetWindowBorder (dpy, tmp->title_w, tmp->border);
	} else {
	    XSetWindowBorderPixmap (dpy, tmp->frame, tmp->gray);
	    if (tmp->title_w)
	      XSetWindowBorderPixmap (dpy, tmp->title_w, tmp->gray);
	}


15.  The AsciiDiskSource compatibility has bugs that may cause contributed
     clients to fail.  Change the expression "TWO" to "ONE" on line 1309 of 
     mit/lib/Xaw/AsciiSrc.c, and move the call to XtMergeArgLists from 
     line 1302 to line 1307 (just before the call to XtCreateWidget).


From ucla-cs!usc!zaphod.mps.ohio-state.edu!swrinde!emory!stiatl!meo Thu Jan 11 18:24:02 PST 1990
Subject: kbd_mode
Status: O

Article 17537 of comp.windows.x:
Path: ucla-cs!usc!zaphod.mps.ohio-state.edu!swrinde!emory!stiatl!meo
>From: meo@stiatl.UUCP (Miles O'Neal)
Newsgroups: comp.windows.x
Subject: kbd_mode
Message-ID: <8526@stiatl.UUCP>
Date: 12 Jan 90 00:35:10 GMT
Organization: Sales Technologies Inc., "The Little Shop of Horrors..."
Lines: 22

(Gary Bisaga  x4219) writes:
|Use 'kbd_mode -a' command.  Keyboard is set up to return internal key codes
|(similar to the IBM PC's scan codes) so that X can pick up, for example,
|shift keys separately (both presses and releases).

It is usually best to invoke xinit from a script, followed
by this (unless you ran xinit in background), so that as
soon as the server goes away (intentionally or otherwise)
your keyboard is restored.

For already hosed keyboards, go to another terminal, login,
and type

kbd_mode -a </dev/console >& /dev/console  # in csh

or

kbd_mode -a < /dev/console >/dev/console 2>&1  # in sh


-Miles O'Neal
{yr fave backbone here}!emory!stiatl!meo


From ucla-cs!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!GARNET.BERKELEY.EDU!rusty Fri Jan 12 08:58:36 PST 1990
Subject: x11r4 xbiff tricks
Status: O

Article 17550 of comp.windows.x:
Path: ucla-cs!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!GARNET.BERKELEY.EDU!rusty
>From: rusty@GARNET.BERKELEY.EDU
Newsgroups: comp.windows.x
Subject: x11r4 xbiff tricks
Message-ID: <9001120451.AA20950@garnet.berkeley.edu>
Date: 12 Jan 90 04:51:26 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 12

Set the shapeWindow resource to True (or use -shape on the command
line).  Use the bitmap program and make a bitmap and bitmap_mask file
with all 0's and use them for the "empty" bitmaps and anything you
want for the "full" bitmaps.  Then you get nothing whatsoever
displayed when you don't have mail but you get whatever you specified
for the "full" bitmap when you do have mail.  For example:

xbiff*shapeWindow:	True
xbiff*fullPixmap:	HOME/lib/bitmaps_x11/zippy.xbm
xbiff*fullPixmapMask:	HOME/lib/bitmaps_x11/zippy_mask.xbm
xbiff*emptyPixmap:	HOME/lib/bitmaps_x11/blank.xbm
xbiff*emptyPixmapMask:	HOME/lib/bitmaps_x11/blank_mask.xbm


From ucla-cs!usc!elroy.jpl.nasa.gov!ames!vsi1!zorch!ditka!qiclab!jamesd Fri Jan 12 09:01:04 PST 1990
Subject: New X Window Books
Status: O

Article 17567 of comp.windows.x:
Path: ucla-cs!usc!elroy.jpl.nasa.gov!ames!vsi1!zorch!ditka!qiclab!jamesd
>From: jamesd@qiclab.UUCP (James Deibele)
Newsgroups: comp.windows.x,comp.windows.news
Subject: New X Window Books
Message-ID: <3691@qiclab.UUCP>
Date: 11 Jan 90 16:02:45 GMT
Reply-To: jamesd@qiclab.UUCP (James Deibele)
Organization: Qic Laboratories, Portland, Oregon.
Lines: 45
Xref: ucla-cs comp.windows.x:17567 comp.windows.news:1943

The following new books might be of interest to X users:
(even though Release 4 is now available)

_X Window System Technical Reference_ by Steven Mikes.  This is distinguished 
by being almost totally devoid of text --- it's 786 pages of charts, figures, 
and code fragments.  It's a "quick reference" :-) to X programming, with 
functions shown with descriptions, category, and return type; structures; 
symbols; fonts; bitmaps, and more.  The last two chapters are "mini-
references" for Motif and OPEN LOOK, showing the resource name, widget, class, 
and type.  (Addison-Wesley, 0-201-52370-1, 1990, $34.95) 

_OPEN LOOK: Graphical User Interface Functional Specifications_ by Sun 
Microsystems.  The first volume of the OPEN LOOK technical reference series, 
this book presents the philosophy behind the OPEN LOOK interface, discussion of 
the design elements, description of the required elements (menus, user-settable 
options, etc.), instructions for using the user interface, and guidelines for 
writing applications using the interface. (Addison-Wesley, 0-201-52365-5, 
1990, $34.95)

_OPEN LOOK: Graphical User Interface Application Style Guidelines_ by Sun 
Microsystems.  The second volume of the OPEN LOOK technical reference series, 
this is the definitive guide for developers creating applications.  Containing 
a checklist for developers, concise information about using OPEN LOOK objects, 
guidelines for developing color applications, (Addison-
Wesley, 0-201-52364-7, 1990, $24.95) 

O'Reilly & Associates says that they hope to be shipping Volume 7 of the X 
series by February 1, to be devoted to Xt (the description I got over the 
phone was kind of garbled, but they're sending out a flyer on it).  They think 
that they may have the fabled volumes 4 and 5 (X toolkit intrinsics) in March.  
What's volume 6?  I don't know either.

Prentice-Hall is supposed to be shipping Doug Young's new book, _Introduction 
to the X Window System: Programming and Applications with Xt, OSF/Motif, next 
week.  (P-H, 0-13-497074-8, 1990, $32.80).   They've also announced the 
OSF/Motif series (_Style Guide_, _Programmer's Guide_, Programmer's Reference_, 
and _User's Guide_) all selling for $41.00 each.  Publication date not firmed 
up, although they told me that it should be firmed up "any day".


-- 
James Deibele  ...!tektronix!nosun!techbook!jamesd   BBS: (503) 760-1473 
TECHBooks: The Computer Book Specialists  ---  Voice: (503) 646-8257
12600 SW 1st  Beaverton, OR  97005  --- Book reviewers wanted for
computer science & electronics - contact us for more information.


From ucla-cs!usc!cs.utexas.edu!asuvax!ncar!unmvax!uakari.primate.wisc.edu!bin Fri Jan 12 12:05:37 PST 1990
Subject: R4 configuration questions
Status: O

Article 17601 of comp.windows.x:
Path: ucla-cs!usc!cs.utexas.edu!asuvax!ncar!unmvax!uakari.primate.wisc.edu!bin
>From: bin@primate.wisc.edu (Brain in Neutral)
Newsgroups: comp.windows.x
Subject: R4 configuration questions
Message-ID: <1455@uakari.primate.wisc.edu>
Date: 12 Jan 90 19:25:01 GMT
Organization: UW-Madison Primate Center
Lines: 12

1) Why do both Imake.tmpl and Project.tmpl do the following:

	#ifndef IncRoot
	#define IncRoot $(DESTDIR)/usr/include
	#endif

I would assume it's better to have this just one place; otherwise one
might change one of them and have it not take effect (due to, e.g.,
having been overridden by the other).

2) The ProjectX symbol is said, in README, to be a boolean.  It appears,
instead, to be defined as the release number.


From ucla-cs!usc!brutus.cs.uiuc.edu!zaphod.mps.ohio-state.edu!uwm.edu!lll-winken!ames!apple!snorkelwacker!bloom-beacon!ATHENA.MIT.EDU!swick Mon Jan 15 07:57:41 PST 1990
Subject: Re: R4 Xt documentation
Status: O

Article 17635 of comp.windows.x:
Path: ucla-cs!usc!brutus.cs.uiuc.edu!zaphod.mps.ohio-state.edu!uwm.edu!lll-winken!ames!apple!snorkelwacker!bloom-beacon!ATHENA.MIT.EDU!swick
>From: swick@ATHENA.MIT.EDU (Ralph R. Swick)
Newsgroups: comp.windows.x
Subject: Re: R4 Xt documentation
Message-ID: <9001130056.AA06178@lyre.MIT.EDU>
Date: 13 Jan 90 00:56:08 GMT
References: <1991@lamont.ldgo.columbia.edu>
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: DEC/MIT Project Athena
Lines: 68

> A make in mit/doc/Xt fails due to the absence of the files
> strings.mit and Xtk.intr.front.

and intr.idxmac.t

> Will I be missing anything if I just drop Xtk.intr.front from the
> dependency list?

nothing terribly important, but here are the minimal diffs w.r.t.
the R3 files to produce reasonable output:

*** r3/strings.mit
--- strings.mit
***************
*** 4,9 ****
  .ds xW X Toolkit Athena Widgets \- C Language Interface
  .ds xL Xlib \- C Language X Interface
  .ds xC Inter-Client Communication Conventions Manual
! .ds Rn 3
  .ds Vn 2.2
--- 4,10 ----
  .ds xW X Toolkit Athena Widgets \- C Language Interface
  .ds xL Xlib \- C Language X Interface
  .ds xC Inter-Client Communication Conventions Manual
! .ds Rn 4
  .ds Vn 2.2

*** r3/Xtk.intr.front
--- Xtk.intr.front
***************
*** 229,235 ****
  The explanations for all arguments that are returned to you start with the
  word \fIreturns\fP or, in the case of multiple arguments, the word \fIreturn\
^\fP.
  .bp 1
! .EH '\fBX Intrinsics\fP''\fBX11, Release 3, Oct. 1988\fP'
! .OH '\fBX Intrinsics\fP''\fBX11, Release 3, Oct. 1988\fP'
  .EF ''\fB % \fP''
  .OF ''\fB % \fP''
--- 232,238 ----
  The explanations for all arguments that are returned to you start with the
  word \fIreturns\fP or, in the case of multiple arguments, the word \fIreturn\
^\fP.
  .bp 1
! .EH '\fBX Toolkit Intrinsics\fP''\fBX11 Release 4, Dec. 1989\fP'
! .OH '\fBX Toolkit Intrinsics\fP''\fBX11 Release 4, Dec. 1989\fP'
  .EF ''\fB % \fP''
  .OF ''\fB % \fP''

*** r3/intr.idxmac.t
--- intr.idxmac.t
***************
*** 27,38 ****
  ..
  .\" set up various parameters for the right evironment.
  .\" Your taste may be different.
! .eh '\fBX Intrinsics\fP''\fBX11, Release 3, Oct. 1988\fP'
! .oh '\fBX Intrinsics\fP''\fBX11, Release 3, Oct. 1988\fP'
  .ef ''\fB % \fP''
  .of ''\fB % \fP''
--- 27,38 ----
  ..
  .\" set up various parameters for the right evironment.
  .\" Your taste may be different.
! .eh '\fBX Toolkit Intrinsics\fP''\fBX11 Release 4, Dec. 1989\fP'
! .oh '\fBX Toolkit Intrinsics\fP''\fBX11 Release 4, Dec. 1989\fP'
  .ef ''\fB % \fP''
  .of ''\fB % \fP''


From ucla-cs!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!orca.wv.tek.com!shamu!jct Mon Jan 15 07:58:24 PST 1990
Subject: Reposting of the Crayola rgb standard ...
Status: O

Article 17637 of comp.windows.x:
Path: ucla-cs!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!orca.wv.tek.com!shamu!jct
>From: jct@shamu.WV.TEK.COM (John C Thomas)
Newsgroups: comp.windows.x
Subject: Reposting of the Crayola rgb standard ...
Message-ID: <5643@shamu.WV.TEK.COM>
Date: 13 Jan 90 00:47:22 GMT
Organization: Tektronix Inc., Beaverton, Or.
Lines: 301

For those who missed it the first time around, here it is again:
   The original Crayola color standard for X-windows.

> I read some place that these colors were supposed to have come from the
> DEC-240.  Anyway, the MIT-supplied values for named colors didn't look very
> good on our SONY monitors, either.  Therefore, as an X-server developer for my
> employer, (Tektronix, Inc) it was my responsibility to do something about it. 
> 
> Advised by our human factors folks that "standard" named colors exist, but
> only for well-controlled color coordinate systems (like CIE, but not for RGB),
> I sat down one evening with the handiest standard of subjective color names,
> a box of 72 Crayola crayons.  (Believe it or not, over 50% of the colors from
> rgb.txt were represented.)
> 
> Using an X-client implementation of the TekColor model,I created the following
> list of named colors.  Appearance on your monitor may vary because of brand,
> age, and video drive circuitry, but I think you will find it a better match
> for the average monitor, than the original rgb.txt file from MIT.
>
> John C Thomas
> Tektronix, Inc.
> Wilsonville, OR
> jct@orca.TEK.COM
> (503) 685-2876

*************************** cut here ******************************************

0 0 0			black
255 255 255		white
255 0 0			red
0 255 0			green
0 0 255			blue
0 255 255		cyan
255 0 211		magenta
255 255 0		yellow
255 138 0		orange
159 211 0		green yellow
0 255 159		spring green
0 138 255		sky blue
148 0 211		violet
255 0 148		violet red
105 105 105		dim gray
174 174 174		gray
174 174 174		grey
211 211 211		light grey
211 211 211		light gray
105 105 105		dim grey
199 21 133		medium violet red
114 33 188		blue violet
218 107 212		orchid
172 77 166		medium orchid
106 37 102		dark orchid
103 7 72		maroon
76 46 87		plum
146 62 112		thistle
171 197 255		light blue
61 98 208		medium blue
100 149 237		cornflower blue
0 0 142			navy blue
0 0 142			navy
12 62 99		midnight blue
72 209 204		turquoise
62 172 181		medium turquoise
29 111 117		dark turquoise
52 152 202		light steel blue
55 121 153		steel blue
126 125 160		cadet blue
117 134 190		slate blue
95 109 154		medium slate blue
51 62 99		dark slate blue
60 64 74		dark slate grey
60 64 74		dark slate gray
0 83 0			dark green
79 79 47		dark olive green
85 192 52		forest green
107 142 35		medium forest green
46 155 28		lime green
60 141 35		medium spring green
152 255 152		pale green
43 167 112		sea green
27 134 86		medium sea green
41 171 151		aquamarine
21 135 118		medium aquamarine
75 211 0 		yellow green
254 197 68		gold
184 134 11		medium goldenrod
218 165 32		goldenrod
229 199 117		wheat
189 167 107		khaki
176 155 125		tan
178 143 86		sandy brown
142 107 35		sienna
103 67 0		brown
101 46 46		indian red
255 174 185		pink
248 137 117		coral
248 109 104		salmon
226 65 42		orange red
136 18 13		firebrick
0 0 0 			gray0
3 3 3 			gray1
5 5 5 			gray2
8 8 8 			gray3
10 10 10 		gray4
13 13 13 		gray5
15 15 15 		gray6
18 18 18 		gray7
20 20 20 		gray8
23 23 23 		gray9
26 26 26 		gray10
28 28 28 		gray11
31 31 31 		gray12
33 33 33 		gray13
36 36 36 		gray14
38 38 38 		gray15
41 41 41 		gray16
43 43 43 		gray17
46 46 46 		gray18
48 48 48 		gray19
51 51 51 		gray20
54 54 54 		gray21
56 56 56 		gray22
59 59 59 		gray23
61 61 61 		gray24
64 64 64 		gray25
66 66 66 		gray26
69 69 69 		gray27
71 71 71 		gray28
74 74 74 		gray29
77 77 77 		gray30
79 79 79 		gray31
82 82 82 		gray32
84 84 84 		gray33
87 87 87 		gray34
89 89 89 		gray35
92 92 92 		gray36
94 94 94 		gray37
97 97 97 		gray38
99 99 99 		gray39
102 102 102 		gray40
105 105 105 		gray41
107 107 107 		gray42
110 110 110 		gray43
112 112 112 		gray44
115 115 115 		gray45
117 117 117 		gray46
120 120 120 		gray47
122 122 122 		gray48
125 125 125 		gray49
127 127 127 		gray50
130 130 130 		gray51
133 133 133 		gray52
135 135 135 		gray53
138 138 138 		gray54
140 140 140 		gray55
143 143 143 		gray56
145 145 145 		gray57
148 148 148 		gray58
150 150 150 		gray59
153 153 153 		gray60
156 156 156 		gray61
158 158 158 		gray62
161 161 161 		gray63
163 163 163 		gray64
166 166 166 		gray65
168 168 168 		gray66
171 171 171 		gray67
173 173 173 		gray68
176 176 176 		gray69
179 179 179 		gray70
181 181 181 		gray71
184 184 184 		gray72
186 186 186 		gray73
189 189 189 		gray74
191 191 191 		gray75
194 194 194 		gray76
196 196 196 		gray77
199 199 199 		gray78
201 201 201 		gray79
204 204 204 		gray80
207 207 207 		gray81
209 209 209 		gray82
212 212 212 		gray83
214 214 214 		gray84
217 217 217 		gray85
219 219 219 		gray86
222 222 222 		gray87
224 224 224 		gray88
227 227 227 		gray89
229 229 229 		gray90
232 232 232 		gray91
235 235 235 		gray92
237 237 237 		gray93
240 240 240 		gray94
242 242 242 		gray95
245 245 245 		gray96
247 247 247 		gray97
250 250 250 		gray98
252 252 252 		gray99
255 255 255 		gray100
0 0 0 			grey0
3 3 3 			grey1
5 5 5 			grey2
8 8 8 			grey3
10 10 10 		grey4
13 13 13 		grey5
15 15 15 		grey6
18 18 18 		grey7
20 20 20 		grey8
23 23 23 		grey9
26 26 26 		grey10
28 28 28 		grey11
31 31 31 		grey12
33 33 33 		grey13
36 36 36 		grey14
38 38 38 		grey15
41 41 41 		grey16
43 43 43 		grey17
46 46 46 		grey18
48 48 48 		grey19
51 51 51 		grey20
54 54 54 		grey21
56 56 56 		grey22
59 59 59 		grey23
61 61 61 		grey24
64 64 64 		grey25
66 66 66 		grey26
69 69 69 		grey27
71 71 71 		grey28
74 74 74 		grey29
77 77 77 		grey30
79 79 79 		grey31
82 82 82 		grey32
84 84 84 		grey33
87 87 87 		grey34
89 89 89 		grey35
92 92 92 		grey36
94 94 94 		grey37
97 97 97 		grey38
99 99 99 		grey39
102 102 102 		grey40
105 105 105 		grey41
107 107 107 		grey42
110 110 110 		grey43
112 112 112 		grey44
115 115 115 		grey45
117 117 117 		grey46
120 120 120 		grey47
122 122 122 		grey48
125 125 125 		grey49
127 127 127 		grey50
130 130 130 		grey51
133 133 133 		grey52
135 135 135 		grey53
138 138 138 		grey54
140 140 140 		grey55
143 143 143 		grey56
145 145 145 		grey57
148 148 148 		grey58
150 150 150 		grey59
153 153 153 		grey60
156 156 156 		grey61
158 158 158 		grey62
161 161 161 		grey63
163 163 163 		grey64
166 166 166 		grey65
168 168 168 		grey66
171 171 171 		grey67
173 173 173 		grey68
176 176 176 		grey69
179 179 179 		grey70
181 181 181 		grey71
184 184 184 		grey72
186 186 186 		grey73
189 189 189 		grey74
191 191 191 		grey75
194 194 194 		grey76
196 196 196 		grey77
199 199 199 		grey78
201 201 201 		grey79
204 204 204 		grey80
207 207 207 		grey81
209 209 209 		grey82
212 212 212 		grey83
214 214 214 		grey84
217 217 217 		grey85
219 219 219 		grey86
222 222 222 		grey87
224 224 224 		grey88
227 227 227 		grey89
229 229 229 		grey90
232 232 232 		grey91
235 235 235 		grey92
237 237 237 		grey93
240 240 240 		grey94
242 242 242 		grey95
245 245 245 		grey96
247 247 247 		grey97
250 250 250 		grey98
252 252 252 		grey99
255 255 255 		grey100


From ucla-cs!usc!snorkelwacker!apple!sun-barr!newstop!sun!opus!gingell Mon Jan 15 07:59:02 PST 1990
Subject: Answers Re: SunOS Shared Libraries
Status: O

Article 17638 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!apple!sun-barr!newstop!sun!opus!gingell
>From: gingell%opus@Sun.COM (Rob Gingell)
Newsgroups: comp.windows.x
Subject: Answers Re: SunOS Shared Libraries
Keywords: SunOS 4.[x] shared libraries dynamic linking searching ldconfig
Message-ID: <130216@sun.Eng.Sun.COM>
Date: 13 Jan 90 02:41:39 GMT
Sender: news@sun.Eng.Sun.COM
Lines: 186

There have been a number of messages posted about various problems/issues in
using shared libraries under SunOS -- specifically problems relating in how
libraries are located and used at execution time.  These often manifest 
themselves as a message like:

	ld.so: libfoo.so.n not found

Here's some information about how it works that may help people use these
facilities a little better.  

setxid programs and dynamic linking.
	The dynamic linker will refuse to use shared objects from directories
	that it does not "trust" when running a set-user or set-group id 
	program.  In 4.0[.x], the implementation simply ignores the library
	search path environment variable when runing a setxid program.

	The reason for this is that it would be trivial to usurp the system
	by writing a C library that included a "getuid()" implementation that
	forked a shell, setting the path variable to pick up this C library,
	and then running "su".

	The link editor "trusts" /usr/lib, /usr/5lib, and /usr/local/lib.

	In 4.0[.x], there is no way to tell the linker that other directories
	are "trustworthy."  So, if you have a library that you want to have
	dynamically linked in a setxid program, it needs to be in one of these
	directories (rather, a name for the library needs to exist in one of
	these directories.)  The bottom line for you is to simply put a 
	symbolic link to the libraries needed by setxid programs in these
	directories.

	Just so you know, 4.1 changes this slightly.  The 4.1 dynamic linker
	does not just ignore the LD_LIBRARY_PATH variable, but instead will
	only use the elements it finds in it that it will trust.  This allows
	one, for instance, to change the search order among trusted libraries
	if for some reason you thought that'd be useful.

	There is also a change to what ld.so considers trusted, in the
	specific case of setxid programs.  While not a general solution
	to the matter, this would deal effectively with the specific
	problems discussed in this group.

		-L options specified during the ld'ing of a dynamically
		linked executable are retained in the executable.  This
		way you can build into a program that its shared libraries
		live in a non-default directory without requiring everyone
		to use the LD_LIBRARY_PATH environment variable.  (This
		is true even in 4.0[.x].)

		What's different in 4.1 is that if a program is ld'ed with
		-L options, and then run as a setxid program, then the
		dynamic linker will "trust" all the "-L" directories.

		So, if you build something like xterm using "-L" rather than
		LD_LIBRARY_PATH to specify X client shared libraries, and
		then ran it as a setxid program, under 4.1 the directory(s)
		specified in a "-L" option would be considered trusted for
		the exectution of "xterm".  (They would not be considered
		trusted for other programs that were not built with that
		directory specified with "-L", such as "su" -- the "trust"
		extends only as far as the program built with "-L".)

	Until 4.1, or if you don't want to depend on 4.1, you should put
	links in /usr/local/lib or /usr/lib to X libraries required by
	setxid executables.

"ldconfig."
	When a dynamically linked program is executed, the libraries it
	requires are located using an algorithm that involves searching a
	sequence of directories for the "best available" version of the
	library.  The ability to adjust the search rules on a per-process
	basis means that this evaluation must be evaluated for every process.
	Although the search is usually fast enough to not be noticable in
	the course of interactive use -- the cumulative time over all
	executions can be non-trivial.  So the dynamic linker uses a
	"cache" that has precomputed where the "best" of a given library
	is in a given directory.

	The cache is built up of elements that are constructed on a
	per-directory basis.  Each element contains information that tells what
	the best revision of each interface is contained in which file for all
	libraries contained in that directory.  For instance, if /usr/lib
	contained:

		libc.so.1.3
		libc.so.1.4
		libc.so.2.1

	and /usr/local/lib contained

		libfoo.so.5.3
		libfoo.so.5.15

	then a cache with elements for /usr/lib and /usr/local/lib would
	contain:

		/usr/lib:
			libc.1 -> libc.so.1.4
			libc.2 -> libc.so.2.1

		/usr/local/lib
			libfoo.5 -> libfoo.so.5.15

	If you change a directory associated with an element without causing
	the element to be re-evaluated, the dynamic linker will fail to find
	any updates you've made.  So, if you added

		/usr/lib/libc.so.2.2

	without recomputing the element for /usr/lib, no program would ever
	find the newly revised version of interface 2 of the C library.  [As it
	turns out, if you add an entirely new interface, such as a version
	"3.x" of the C library, such that a search through caches yields *no*
	candidate, the link editor will automatically invalidate the cache and
	recompute it for the current process -- however, new revisions don't
	cause this behavior simply because the cache does retrieve the old
	revision.]

	"ldconfig" is the program that recomputes the elements -- by default
	it does /usr/lib, /usr/local/lib, and /usr/5lib.  You can ask that
	other directories be included by having them as command line
	arguments to "ldconfig."

	If you don't do this for a directory, the only side effect is that the
	dynamic linker will have to read the directory to find the best
	versions of whatever libraries it holds.  If you don't do this for a
	directory that *is* in the cache already, but is one that you've
	updated with a new revision, then the new revision will simply not be
	visible.  In the case where you don't cache a directory, processes
	wishing to use that directory in finding shared libraries will simply
	run a little slower.  In particular, whether "ldconfig" builds a cache
	element for a directory or not has no impact on whether or not that
	directory is considered "trusted."

-assert pure-text
	In at least one of the messages I saw, there was a discussion that
	indicated that the use of this option was producing some "ld" 
	diagnostics -- this was mentioned in the context of whether or
	not the library could be found at execution time.  I may have mis-
	understood that specific reference but the only thing the "-assert
	pure-text" ld option does is have "ld" tell you whether or not it
	had to defer some text-segment relocation.  If it does, the penalty
	is that the dynamic linker will have to resolve that relocation at
	execution-time, leading to increased swap usage for the modified
	pages and less sharing than perhaps you expected.   The diagnostic
	it produces isn't particularly helpful, this is improved in 4.1
	to provide information that's more immediately useful to someone
	building the library.  However, it's completely separate from the
	process by which libraries are found at execution time.

Do shared libraries buy you anything?
	It depends upon what you value.  If a library is used by multiple
	processes (i.e., sharing is really going on) then experience with
	the libraries Sun supplies says that "yes, you save a lot of both
	disk space and memory occupancy, and indirectly save on channel
	bandwidth due to decreased I/O requirements."  If on the other
	hand, a shared library is used only serially (i.e. at any time only
	one process exists that uses the library), then it is conceivable
	(and probable) that you've actually increased the load on the
	primary memory resource because you've got the *whole* library
	rather than just what you need -- and this probably spans more
	address space and therefore more pages than it would have had you
	extracted just what you need from an archive.

	However, Sun ships a shared library that isn't shared (in parallel,
	that is.)  It's the libkvm library that is bound with programs that
	rummage through kernel memory like "ps", "netstat", etc.  It's 
	highly unlikely on a workstation that you'll actually have two
	processes doing this simultaneously.  However the reason libkvm is
	supplied as a .so and used that way in the system has to do with
	"dynamic linking" -- not the application of dynamic linking that
	creates the effect of library sharing.

	We want to dynamically link libkvm to isolate those applications
	that interrogate kernel memory from the access methods used to do
	that interrogation.  At the time the dynamic linking facilities
	were in development, we were also developing the memory management
	facilities and it was somewhat painful to have to re-cut all the
	"kernel virtual memory" programs as a result of some experiment or
	change we conducted with the memory management code.  What we value
	with libkvm is not the sharing, but the flexibility provided by
	dynamic linking.  You may also value this in some circumstances,
	where you might not value library sharing.  So, at least with the
	dynamically linked shared library implementations in SunOS and
	SVR4, the issue of whether "to .so or not to .so" is a little
	more subtle than simply library sharing.


From ucla-cs!usc!cs.utexas.edu!uunet!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws Mon Jan 15 08:48:44 PST 1990
Subject: Consortium Draft Standard Available For Public Review: Input Extension
Status: O

Article 17660 of comp.windows.x:
Path: ucla-cs!usc!cs.utexas.edu!uunet!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
>From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Consortium Draft Standard Available For Public Review: Input Extension
Message-ID: <9001131913.AA08875@expire.lcs.mit.edu>
Date: 13 Jan 90 19:13:50 GMT
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 67

An MIT X Consortium draft standard of the Input Extension is now available for
Public Review.  This draft standard establishes a mechanism for dealing with
additional input devices (beyond a single keyboard and pointer) within the
X server.

The objective of Public Review is to determine if the current draft is
acceptable as a Consortium standard.  Public Review can result in changes to
the draft standard.  Public Review of the Input Extension is scheduled to end
April 16, 1990.  The X community is encouraged to review the draft and submit
comments by electronic mail to
	input-ext@expo.lcs.mit.edu
You may send written comments to
	Bob Scheifler
	Laboratory for Computer Science
	545 Technology Square
	Cambridge, MA 02139
Comments sent to other addresses are not guaranteed to be considered.

Commentors should take the review process seriously, and should:
	1. Identify objectionable wording in the document.
	2. Suggest specific alternative wording.
and most importantly:
	3. Provide a rationale for the suggested change.

Commentors should also carefully distinguish between:
	1. Problems that they regard as intolerable and that must be corrected
	   before the document becomes a standard.
	2. Aspects that they don't like but could live with for a few years
	   until a future revision of the standard.
	3. Additional functionality that they can live without in an initial
	   standard but would like to see in a future revision.

A Consortium committee will review the comments and respond to commentors.


The Input Extension documents (protocol, encoding, and library) are available
as part of the X11R4 distribution, in the directory mit/doc/extensions/xinput/,
and separately via anonymous ftp to expo.lcs.mit.edu in the directory
/pub/DOCS/input/.  The documents are also available via the archive server
xstuff@expo.lcs.mit.edu, by sending a message with the Subject: line of
"send docs input/<itemname>" and an empty message body, where <itemname> is
one of:

Makefile
Format
S.aformat
TitlePage
TitlePage.p
protocol.mm
encoding.mm
library.mm.1
library.mm.2

Some mailers produce mail headers that are unusable for extracting return
addresses.  If you use such a mailer, you won't get any response.  If you
happen to know an explicit path, you can include a line like
	path foo%bar.bitnet@mitvma.mit.edu
or
	path bar!foo!frotz
in the body of your message, and the daemon will use it.

If you simply cannot obtain the Input Extension from the network, you may
request a paper copy by writing to:
	Michelle Leger
	Laboratory for Computer Science
	545 Technology Square
	Cambridge, MA 02139


From ucla-cs!usc!apple!well!jef Mon Jan 15 12:50:44 PST 1990
Subject: Updates 36 through 39 for Poskanzer Bitmap Collection available.
Status: O

Article 17693 of comp.windows.x:
Path: ucla-cs!usc!apple!well!jef
>From: jef@well.UUCP (Jef Poskanzer)
Newsgroups: comp.windows.x,comp.graphics,comp.windows.misc
Subject: Updates 36 through 39 for Poskanzer Bitmap Collection available.
Message-ID: <15521@well.UUCP>
Date: 15 Jan 90 19:33:44 GMT
Reply-To: Jef Poskanzer <jef@well.sf.ca.us>
Organization: Paratheo-Anametamystikhood Of Eris Esoteric, Ada Lovelace Cabal
Lines: 66
Xref: ucla-cs comp.windows.x:17693 comp.graphics:9906 comp.windows.misc:1426

Four more updates are ready -- I've been doing some scanning, plus
the usual steady trickle from around the net.

The updates are stored on expo.lcs.mit.edu (18.30.0.212) in the
directory contrib/poskbitmaptars.  The contents and exact sizes
are listed below.  Don't forget to set binary mode when you retrieve
them.  And please don't FTP during working hours (9 am to 6 pm EST).

As always, any bitmaps you want to send me are welcome.
---
Jef

  Jef Poskanzer  jef@well.sf.ca.us  {ucbvax, apple, hplabs}!well!jef

- - - - - - - - - -

    507904 pb.upd36.tar
README
PANIC		1028	900	me	"PANIC".
b52s		1123	738	me	B52 graveyard, from "Dead Tech".
bitch		728	869	me	"Life's a bitch and so am I!"
breathtakers	297	424	kendy	A speedway ad.
casablanca	690	514	me	Scene from the movie.
churchy		357	480	schwrtz	Scanned from The Puce Stamp Catalog.
coke2		371	300	me	A Coca-Cola can.
coke_small	110	107	me	The Coca-Cola logo.
coke_thai	339	274	me	A Coca-Cola can from Thailand.
cramps		458	581	allynh	A Cramps poster.
dmr		812	900	???*	Dennis Ritchie.
fish2		235	162	jonnyg	The monochrome fish from xaqua.
fish3		64	64	djones	A tiling fish background.
fish4		375	176	russ*	One of the two fish in twofish.
fish5		287	136	russ*	One of the two fish in twofish.
greavey		205	244	schwrtz	Scanned from The Puce Stamp Catalog.
grundoon	209	395	schwrtz	Scanned from The Puce Stamp Catalog.
hawkins		388	462	allynh	Screamin' Jay Hawkins.

    499712 pb.upd37.tar
howland		392	437	schwrtz	Scanned from The Puce Stamp Catalog.
junkers1	1143	753	me	Junked cars, from "Dead Tech".
junkers2	1152	900	me	Junked cars and sheep, from "Dead Tech".
jupiter1	1152	900	me	Voyager 1-19, P-21082, Jupiter, Io, and Europa.
jupiter2	1152	900	me	Voyager 1-??, P-??, Jupiter.
ladybug		164	341	schwrtz	Scanned from The Puce Stamp Catalog.
lottery		876	777	me	"Binky plays the lottery for you."

    507904 pb.upd38.tar
maginot		1152	698	me	The Maginot Line, from "Dead Tech".
manhattan2	386	900	me	Dr. Manhattan from "Watchmen".
manhattan3	1152	621	me	Dr. Manhattan from "Watchmen".
manhattan4	567	900	me	Dr. Manhattan from "Watchmen".
mouffetard	632	900	me	Rue Mouffetard, Paris 1954, Cartier-Bresson
needle		599	703	kendy	An anti-drug message.
nosl		469	746	kendy	No Speed Limit - a car-parts ad.
peter		678	799	me	Peter Gabriel.
pogo		264	373	schwrtz	Scanned from The Puce Stamp Catalog.
porky		242	353	schwrtz	Scanned from The Puce Stamp Catalog.

    409600 pb.upd39.tar
rockets		1152	900	me	Rocket Garden, from "Dead Tech".
rorschach	1152	590	me	Rorschach from "Watchmen".
snail1		599	405	me	A bunch of snails.
snail2		500	647	me	A sectioned nautilus.
tmi1		1144	756	me	Three Mile Island, from "Dead Tech".
tmi2		596	900	me	Three Mile Island, from "Dead Tech".
underground1	303	246	me	The London Underground's logo.


From ucla-cs!usc!snorkelwacker!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!EXPO.LCS.MIT.EDU!rws Wed Jan 24 09:41:24 PST 1990
Subject: Fix #1 for X11R4 is now available on expo
Status: O

Article 18023 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!EXPO.LCS.MIT.EDU!rws
>From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Fix #1 for X11R4 is now available on expo
Message-ID: <9001232353.AA16941@expire.lcs.mit.edu>
Date: 23 Jan 90 23:53:28 GMT
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 21

Fixes are available via anonymous ftp to expo.lcs.mit.edu (18.30.0.212), in
the directory /pub/R4/fixes/, in files with prefix "fix-".  The first fix
is "fix-1".  Fixes get put there in batches at intervals only.  Fixes usually
propagate to other distribution sites as well, so check at a nearer site first.

For those without ftp access, individual fixes can be obtained by mail by
sending a message to xstuff@expo.lcs.mit.edu.  In the usual case, the
message should have a subject line and no body, or a single-line body and
no subject, in either case the line looking like:
	send fixes 1
(to get the first fix).  To get a summary of fixes, make the line:
	index fixes
If you need help, make the line:
	help
Some mailers produce mail headers that are unusable for extracting return
addresses.  If you use such a mailer, you won't get any response.  If you
happen to know an explicit path, you can include a line like
	path foo%bar.bitnet@mitvma.mit.edu
or
	path zot!gzork!me@uunet.uu.net
in the body of your message, and the daemon will use it.


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws Wed Jan 24 09:43:21 PST 1990
Subject: Re: bug in Fix #1 for X11R4
Status: O

Article 18051 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
>From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: bug in Fix #1 for X11R4
Message-ID: <9001241343.AA17113@expire.lcs.mit.edu>
Date: 24 Jan 90 13:43:09 GMT
References: <4ZjGOzu00WB94_Ynhh@andrew.cmu.edu>
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 9


	The patch to mit/lib/Xt/NextEvent.c appears to have been
	generated off of the wrong version of the file. The version that was
	shipped as R4 (at least in the archive copy I got from CMU CS) is
	1.78, while the patch is going from 1.79 to 1.80.

A new version of fix-1 has been installed on expo, with a corrected diff
for NextEvent.c.  (The missing piece only affects Crays.)  Sorry for the
screwup.


From ucla-cs!usc!snorkelwacker!bloom-beacon!DB.TORONTO.EDU!jonah Mon Jan 29 08:59:32 PST 1990
Subject: Twm has a hard-wired path for the system defaults file
Status: O

Article 18262 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!DB.TORONTO.EDU!jonah
>From: jonah@DB.TORONTO.EDU (Jeffrey Lee)
Newsgroups: comp.windows.x
Subject: Twm has a hard-wired path for the system defaults file
Message-ID: <90Jan27.105603est.2755@ois.db.toronto.edu>
Date: 27 Jan 90 15:55:54 GMT
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 88


			  X Window System Bug Report
			    xbugs@expo.lcs.mit.edu


VERSION:
    R4

CLIENT MACHINE and OPERATING SYSTEM:
    Sun{3/x,4/x} running SunOS {4.x}

DISPLAY TYPE:
    Sun CG4, BW2, CG6

WINDOW MANAGER:
    twm

AREA:
    twm

SYNOPSIS:
    Twm has a hard-wired path for the system defaults file:
    "/usr/lib/X11/twm/system.twmrc" in mit/clients/twm/parse.c


DESCRIPTION:

    Although much of the system installation is configurable using
    Imakefiles and mit/config/site.def, twm has a hard-wired path for its
    system defaults file.  Since SunOS 4.0.* conventions dictate that /usr
    should be reserved for the manufacturer's software (and mounted
    read-only), we prefer to install X11 elsewhere than under /usr/lib/.

REPEAT BY:

    Look at mit/clients/twm/parse.c:

	...
	#include "parse.h"
	
	#define SYSTEM_INIT_FILE "/usr/lib/X11/twm/system.twmrc"
	#define BUF_LEN 300
	
	static FILE *twmrc;
	...


SAMPLE FIX:

    The following patch fixes parse.c so that it uses the hard-wired
    path only if SYSTEM_INIT_FILE is not defined on the command-line
    for the compile.  It also fixes mit/clients/twm/Imakefile so that
    (at our site) it defines SYSTEM_INIT_FILE in terms of $(LIBDIR)
    when creating the Makefile and passes this value to parse.c at
    compile time.  For general consumption, remove the #ifdef CSRIToronto
    or change it to #if 1.

*** /tmp/,RCSt1a29841	Fri Jan 26 20:10:29 1990
--- mit/clients/twm/parse.c	Fri Jan 26 19:40:25 1990
***************
*** 51,57 ****
--- 51,59 ----
  #include "gram.h"
  #include "parse.h"
  
+ #ifndef SYSTEM_INIT_FILE
  #define SYSTEM_INIT_FILE "/usr/lib/X11/twm/system.twmrc"
+ #endif
  #define BUF_LEN 300
  
  static FILE *twmrc;
*** /tmp/,RCSt1a29841	Fri Jan 26 20:10:30 1990
--- mit/clients/twm/Imakefile	Fri Jan 26 19:53:29 1990
***************
*** 14,20 ****
--- 14,25 ----
          DEPLIBS = $(DEPXMULIB) $(DEPEXTENSIONLIB) $(DEPXLIB)
  LOCAL_LIBRARIES = $(XMULIB) $(EXTENSIONLIB) $(XLIB)
         LINTLIBS = $(LINTXMU) $(LINTEXTENSIONLIB) $(LINTXLIB)
+ #ifdef CSRIToronto
+         DEFINES = ExtensionDefines $(SIGNAL_DEFINES) $(PUTENVDEF) \
+ 		'-DSYSTEM_INIT_FILE="'$(LIBDIR)'/twm/system.twmrc"'
+ #else
          DEFINES = ExtensionDefines $(SIGNAL_DEFINES) $(PUTENVDEF)
+ #endif
  
             SRCS = gram.c lex.c deftwmrc.c add_window.c gc.c list.c twm.c \
  		parse.c menus.c events.c resize.c util.c version.c iconmgr.c \


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws Mon Jan 29 09:01:00 PST 1990
Subject: Re: CLX key-events: converting keycodes to characters?
Status: O

Article 18270 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
>From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: CLX key-events: converting keycodes to characters?
Message-ID: <9001272104.AA02454@expire.lcs.mit.edu>
Date: 27 Jan 90 21:04:49 GMT
References: <3170@accuvax.nwu.edu>
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 9


    There are a number of possibly helpful functions defined in translate.lisp,
    but there is no explanation; for example, in
	(keycode->character display keycode state)
    ...what is a state?

Get R4, and print out the CLX documentation in mit/hardcopy/CLX/.  state is
a bitmask representing the state of the modifier bits.  Both the keycode and
state can be extracted from a keyboard event.


From ucla-cs!usc!brutus.cs.uiuc.edu!apple!sun-barr!newstop!sun!kimba!hvr Tue Jan 30 12:18:51 PST 1990
Subject: Re: Sun 4, OS 4.0.3, X11R4 problems fixes (at least some)
Status: O

Article 18342 of comp.windows.x:
Path: ucla-cs!usc!brutus.cs.uiuc.edu!apple!sun-barr!newstop!sun!kimba!hvr
>From: hvr@kimba.Sun.COM (Heather Rose)
Newsgroups: comp.windows.x
Subject: Re: Sun 4, OS 4.0.3, X11R4 problems fixes (at least some)
Message-ID: <130930@sun.Eng.Sun.COM>
Date: 30 Jan 90 01:56:45 GMT
References: <1998@rex.cs.tulane.edu>
Sender: news@sun.Eng.Sun.COM
Reply-To: hvr@sun.UUCP (Heather Rose)
Organization: Sun Microsystems, Mountain View
Lines: 40

In article <1998@rex.cs.tulane.edu> barad@dauphine.ee.tulane.edu (Herb Barad) writes:
>A lot of people have been running into X11R4 problems on Suns (at
>least I was) and I found the source of one of the problems.
>
>It seems that when X11 and Sun's X11/NeWS co-exist on the same
>machine, then building the MIT release might be a problem.
>
>The instructions to Sun's version indicate that an environment
>variable for the loader should be set.  For example,
>
>setenv LD_LIBRARY_PATH  $OPENWINHOME/lib:/usr/lib:/usr/local/lib:/usr/lib/X11
>
>This means that during the build linking stage, you will pick up
>X11/NeWS libraries first.  This is wrong and could be a problem
>depending upon the preferences stated in the setenv line.
>
>I hope this helps people some.

Do not use LD_LIBRARY_PATH at all.  Use the "ldconfig" command instead.
The major numbers of the OpenWindows libX11 differ from that of the X11R4
libX11, so if you use ldconfig, the correct library should be found at
run time.

Now at compile time, unsetenv the LD_LIBRARY_PATH variable, and rely instead
on the -L flag to point the loader to the correct library to link against.
This will insure that the binaries get the correct library at create time.

What do I mean by "use ldconfig"?  Basically, this means that after you
install the new shared libaries from X11R4, become root on your system and
do two things:  1) ldconfig <location of newly installed binaries>, and
2) edit the /etc/rc.local file to add the previous line to this file.
[ you also may want to add an ldconfig line for all libraries that are not
installed in /usr/lib, /usr5/lib, or /usr/local/lib ].

This is much simpler than telling all your users to set some environment
variables.  And you don't need to worry about situations where you want
to run some R4 binaries that need the new R4 libraries on your OpenWindows
server.

Heather


From ucla-cs!usc!brutus.cs.uiuc.edu!samsung!cs.utexas.edu!mailrus!purdue!bu.edu!bu-cs!ics!harden Tue Jan 30 12:21:24 PST 1990
Subject: Re: please don't do this to us
Status: O

Article 18362 of comp.windows.x:
Path: ucla-cs!usc!brutus.cs.uiuc.edu!samsung!cs.utexas.edu!mailrus!purdue!bu.edu!bu-cs!ics!harden
>From: harden@ICS.COM (Aub Harden)
Newsgroups: comp.windows.x
Subject: Re: please don't do this to us
Summary: R4 available on various media
Keywords: R4 Tapes
Message-ID: <1990Jan30.165838.17659@ICS.COM>
Date: 30 Jan 90 16:58:38 GMT
Expires: March 1, 1990
References: <9001251623.AA19243@expire.lcs.mit.edu>
Reply-To: harden@ics.com (Aub Harden)
Followup-To: comp.windows.x
Organization: Integrated Computer Solutions, Inc., Cambridge MA
Lines: 26


> perhaps any companies doing this could go ahead and post the
> information to this list.

Integrated Computer Solutions, Inc. provides R4 on various media-
1/2", 6250 bpi; 1/4", QIC-11, QIC-24; and TK50. The price is $400.
Documentation is included.  This is a full source distribution of
all core and user-contributed software.  Pre-builts are also available.

To order, call or fax us at the number below. Laurie Pelletier is
the person to talk to.

For more information on ICS X training, products and services send
mail to the address below, or call.


***********************************************************************
*                                                                     *
*  Integrated Computer Solutions, Inc.  |  Everything you wanted to   *
*  163 Harvard Street                   |    know about X but were    *
*  Cambridge, MA  02139                 |       afraid to ask...      *
*                                                                     *
*  voice: 617/547-0510    fax: 617/547-0758    e-mail: info@ics.com   *
*                                                                     *
*                   The X Window System Specialists                   *
*********************************************************************** 


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!jim Tue Jan 30 12:21:41 PST 1990
Subject: new expo.lcs.mit.edu:~ftp/contrib/R4fixes/ directory
Status: O

Article 18363 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!jim
>From: jim@EXPO.LCS.MIT.EDU (Jim Fulton)
Newsgroups: comp.windows.x
Subject: new expo.lcs.mit.edu:~ftp/contrib/R4fixes/ directory
Message-ID: <9001301657.AA15454@kanga.lcs.mit.edu>
Date: 30 Jan 90 16:57:35 GMT
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: X Consortium, MIT Laboratory for Computer Science
Lines: 32


We have created a new directory subtree named contrib/R4fixes/ that authors of
R4 user-contributed software may use for depositing *patches* relative to the
contents of the R4 tape.  This is analogous to the ~ftp/pub/R4/fixes/ directory
for core patches.

For packages that already have their own subdirectories in contrib (i.e.
XView, andrew, gwm, and winterp), I have already created subdirectories under
R4fixes (note that Niels has already updated winterp):

	% ls -lR contrib/R4fixes
	drwxrwxrwx  2 jim           512 Jan 30 11:45 XView
	drwxrwxrwx  2 jim           512 Jan 30 11:44 andrew
	drwxrwxrwx  2 jim           512 Jan 30 11:44 gwm
	drwxrwxrwx  2 jim           512 Jan 29 22:37 winterp
	
	XView:
	-rw-rw-rw-  1 jim            48 Jan 30 11:45 README
	
	andrew:
	-rw-rw-rw-  1 jim            49 Jan 30 11:45 README
	
	gwm:
	
	winterp:
	-rw-rw-rw-  1 ftp         84456 Jan 29 22:40 patch-0
	

Owners of R4 contributed software may contact me about creating additional
subdirectories or moving patches there. 

							Jim


From ucla-cs!usc!snorkelwacker!mit-eddie!thakur Wed Jan 31 08:00:32 PST 1990
Subject: Gcc vs Cc argument processing (Was: X11 can't find libXmu.so.4)
Status: O

Article 18377 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!mit-eddie!thakur
>From: thakur@eddie.mit.edu (Manavendra K. Thakur)
Newsgroups: comp.windows.x
Subject: Gcc vs Cc argument processing (Was: X11 can't find libXmu.so.4)
Message-ID: <1990Jan30.220403.10429@eddie.mit.edu>
Date: 30 Jan 90 22:04:03 GMT
Reply-To: thakur@eddie.MIT.EDU (Manavendra K. Thakur)
Organization: MIT EE/CS Computer Facilities, Cambridge, MA
Lines: 106


I'm getting the following error message when I do a "make World" for
the MIT core distribution on a Sun 4/390 (SPARC processor) under SunOS
4.0.3 and gcc 1.36:

> making all in ./fonts/mkfontdir...
> making all in ./fonts/bdf...
> making all in ./fonts/bdf/misc...
[...]

> ../../.././fonts/mkfontdir/mkfontdir .
> ld.so: libXmu.so.4: not found
> *** Error code 127
> make: Warning: Target `all' not remade because of errors
> Current working directory /src/X11R4/sun4/mit/fonts/bdf/misc


Ok, before all of you bawl me out for going over previously covered
material, I *did* wade through several hundred back postings of
comp.windows.x.  I found some references to this same problem, but
none of the offered solutions cleared up my confusion.  So please,
bear with me while I go over this again.

As I understand it, the basic problem is that ld.so cannot access the
required shared library (libXmu.so.4.0).  I've seen (basically) two
solutions to this problem posted to the net:

1) use ldconfig if you install the libraries in a nonstandard place
2) specify -L<dir> to encode the library directory info at compile time

Well, I don't think that 1) applies because first, I haven't installed
the libraries *anywhere* yet, much less in a nonstandard place -- this
problem happens during compile time!

Secondly, if I run ldd on the mit/fonts/mkfontdir/mkfontdir
executable, ldd reports that the mkfontdir executable is in fact
dynamically linked and that it *does* have the library directory
infomation encoded into it:

% cd /src/X11R4/sun4/mit/fonts/mkfontdir
% ldd mkfontdir
        -lXmu.4 => ../.././lib/Xmu/libXmu.so.4.0
        -lc.1 => /usr/lib/libc.so.1.3.1


So that eliminates 2) above.

However, it also provides a clue to what the problem is: the pathway
to the libXmu.so.4.0 directory is a *relative* pathname instead of an
absolute pathname (as is the libc.so.1.3.1 path information).  So this
means that the mkfontdir executable can only be called from a
directory two levels below the top directory.

And when mkfontdir gets run during the "make World" build, it is
invoked from the mit/fonts/bdf/misc directory -- which is *three*
levels below the top directory, and hence the relative pathway to
libXmu.so.4.0 is invalid and the program cannot run.

I verified this by looking in the make.world log:

> making .././fonts/mkfontdir
[...]
> gcc -DNOSTDHDRS -fstrength-reduce -fpcc-struct-return -fwritable-strings -o mkfontdir mkfontdir.o fontdir.o snf_util.o -O -pipe -Bstatic -L../.././lib/Xmu -lXmu -Bdynamic
> 

Note how the -L option specifies a relative pathname.

BUT, BUT, BUT!

Looking at the other arguments led me to realize what the *real*
problem underlying all of this is: gcc processes the -B flag very
differently from your generic garden variety C compiler.

For gcc, the -B option specifies a prefix that is prepended while
searching for executables such as ld, as, cpp, and the like.  Gcc does
not (to the best of my knowledge) pass the -B option to the linker.

For Sun's C compiler, the -B option is passed to the linker and is
used (among a few other things) to specify whether static or dynamic
linking is desired.

>From the way imake generates mit/fonts/mkfontdir/Makefile, it seems
clear that the intent is to link libXmu.a into mkfontdir *statically*
and not dynamically.  This would, of course, avoid all these problems
with relative pathnames.  But because gcc does not interpret the
-Bstatic call as intended, the linker uses the relative pathname to
libXmu.so.4.0 to link the library into mkfontdir *dynamically*
(dynamic linking is the default for Sun's ld).  Hence, we get the
error message whenever mkfontdir is invoked from a subdirectory that
is not two levels below the top directory.

So what to do about this?

A possible fix might be to define a new Imakefile variable (is that
the right terminology?) that species the right arguments to pass to
the compiler for switching between static and dynamic linking.

Does any of the above make sense?  Can anyone confirm or refute this
line of thought?  Is there a better solution?  Or have I done
something terribly stupid while installing gcc and/or X11R4?

                                Manavendra K. Thakur
                                System Manager, High Energy Division
                                Harvard-Smithsonian Center for Astrophyics
                                thakur@zerkalo.harvard.edu
                                thakur@cfa.harvard.edu


From ucla-cs!usc!snorkelwacker!bloom-beacon!CS.BROWN.EDU!jsb Wed Jan 31 08:02:57 PST 1990
Subject: r3->r4 Xlib change
Status: O

Article 18382 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!CS.BROWN.EDU!jsb
>From: jsb@CS.BROWN.EDU
Newsgroups: comp.windows.x
Subject: r3->r4 Xlib change
Message-ID: <9001302201.AA03914@no.cs.brown.edu>
Date: 30 Jan 90 22:01:02 GMT
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 12

"Xlib Changes From Release 3 to Release 4" fails to mention that
XOpenDisplay (really XConnDis) now sets the close-on-exec flag on
the socket through which it talks to the server.  It didn't under R3.

You might notice this if your client vfork/exec's a child and then exits
and you expect the child to keep the connection open.  As weird as it
sounds, I do it.

Pardon me if everyone knows this already.

John Bazik
jsb@cs.brown.edu


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!jim Wed Jan 31 13:41:42 PST 1990
Subject: Re: bitmap
Status: O

Article 18412 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!jim
>From: jim@EXPO.LCS.MIT.EDU (Jim Fulton)
Newsgroups: comp.windows.x
Subject: Re: bitmap
Message-ID: <9001311716.AA16911@kanga.lcs.mit.edu>
Date: 31 Jan 90 17:16:20 GMT
References: <1990Jan31.094138.4778@eng.umd.edu>
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: X Consortium, MIT Laboratory for Computer Science
Lines: 10


    Can anyone think of a good reason not to change bitmap
    to save the definition using unsigned char rather char?

Unfortunately, yes.  The bitmaps produced by it could no longer be read by
XReadBitmapFile().  Yes, one could amend the Xlib specification, but the
bitmaps still wouldn't be usable by programs that are statically linked (boo,
hiss) with old libraries.

A crock you say?  You bet.


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!jim Mon Feb  5 20:46:40 PST 1990
Subject: Re: Question about X11R4 XGetWMNormalHints()
Status: O

Article 18631 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!jim
>From: jim@EXPO.LCS.MIT.EDU (Jim Fulton)
Newsgroups: comp.windows.x
Subject: Re: Question about X11R4 XGetWMNormalHints()
Message-ID: <9002051628.AA28314@kanga.lcs.mit.edu>
Date: 5 Feb 90 16:28:14 GMT
References: <1159@tub.UUCP>
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: X Consortium, MIT Laboratory for Computer Science
Lines: 16


    What is the correct way for a client to determine whether or not the
    (new) base_width, base_height, and win_gravity components are defined
    in the XSizeHints structure returned by a call to XGetWMNormalHints()?

Look at the PBaseSize and PWinGravity bits in the flags.


    Should the client look into the supplied_return argument or into the
    flags component of the XSizeHints?  In what way are these two different?

The sizehints.flags mask indicates which fields are set in the structure.  The
supplied_return argument returns the mask of all possible fields which *could*
have been returned for this property.  New hints will return all of the
possible flag fields, pre-ICCCM hints will not have PBaseSize or PWinGravity
set.


From ucla-cs!elroy.jpl.nasa.gov!lll-winken!uwm.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!ucsd!ucsdhub!hp-sdd!hplabs!hpfcso!stroyan Mon Feb  5 20:49:09 PST 1990
Subject: Re: XCreateWindow with different depth
Status: O

Article 18656 of comp.windows.x:
Path: ucla-cs!elroy.jpl.nasa.gov!lll-winken!uwm.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!ucsd!ucsdhub!hp-sdd!hplabs!hpfcso!stroyan
>From: stroyan@hpfcso.HP.COM (Mike Stroyan)
Newsgroups: comp.windows.x
Subject: Re: XCreateWindow with different depth
Message-ID: <7320003@hpfcso.HP.COM>
Date: 5 Feb 90 22:43:28 GMT
References: <22095.25c5d523@kuhub.cc.ukans.edu>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 13

> I tried to XCreateWindow with the depth different from that of its parent, but
> failed. It worked O.K. as long as I changed the depth to that of its parent.
> What's the problem?

Make sure that the window does not inherit any depth dependent attributes
from its parent window.  That includes-

  background_pixmap
  border_pixmap
  colormap
  visual

Mike Stroyan, stroyan@hpfcla.hp.com


From ucla-cs!usc!zaphod.mps.ohio-state.edu!think!mintaka!bloom-beacon!VUSE.VANDERBILT.EDU!drl Tue Feb  6 10:07:41 PST 1990
Subject: Imake gotcha - escape colons (\:)
Status: O

Article 18669 of comp.windows.x:
Path: ucla-cs!usc!zaphod.mps.ohio-state.edu!think!mintaka!bloom-beacon!VUSE.VANDERBILT.EDU!drl
>From: drl@VUSE.VANDERBILT.EDU (David R. Linn)
Newsgroups: comp.windows.x
Subject: Imake gotcha - escape colons (\:)
Message-ID: <9002061600.AA10669@backup>
Date: 6 Feb 90 16:00:45 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 36

This may seem obvious to most but it took me an hour and a half
to track down. The imake manual page includes the following:

     On systems whose cpp reduces multiple tabs and spaces  to  a
     single  space, imake attempts to put back any necessary tabs
     (make is very picky about the difference  between  tabs  and
     spaces).   For this reason, colons (:) in command lines must
     be preceded by a backslash (\).

This means that colons in a MACRO that will be USED in a command
line must also be escaped.  In my particular case, I modified the
Imakefile in TOP/lib/Xt to provide a PARSE_DEFINES for compiling
parse.c.  It looks something like this:

  PARSE_DEFINES = -DXFILESEARCHPATHDEFAULT= <<NONL>>
\"$(LIBDIR)/%L/%T/%N%S\:$(LIBDIR)/%l/%T/%N%S\:$(LIBDIR)/%T/%N%S\"
		      ^^		    ^^
		      Note the escaped colons

The <<NONL>> indicates a newline introduced for the purpose of mail;
it does not exist in the Imakefile.  This macro is used in special
rules for compiling parse.c in the various combinations of debugging
and profiling.

Escaping the colons was not necessary on a Sun3 or Sun4 under SunOS
with its BSD-derived make.  However, under HP-UX on an HP9k300, the
makefile generated without the escapes was rejected by the ATT-derived
make.

	Hope this is of some use to someone,
	 David

David Linn, System Manager/Postmaster	   |INET: drl@vuse.vanderbilt.edu
Vanderbilt University School of Engineering|Phone: [+1] 615-343-6164
Post Office Box 3241, Station B            |Disclaimer:
Nashville, TN, USA  37235                  |  I speak only for myself.


From ucla-cs!usc!snorkelwacker!mit-eddie!uw-beaver!zephyr.ens.tek.com!orca.wv.tek.com!crevasse!glennw Tue Feb  6 12:40:17 PST 1990
Subject: R4 Hello World
Status: O

Article 18677 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!mit-eddie!uw-beaver!zephyr.ens.tek.com!orca.wv.tek.com!crevasse!glennw
>From: glennw@crevasse.WV.TEK.COM (Glenn Widener;;61-049;;orca;)
Newsgroups: comp.windows.x
Subject: R4 Hello World
Summary: An update of David Rosenthal's classic X program
Keywords: X11R4, Xlib, ICCCM, hello world, sample X program
Message-ID: <6077@orca.wv.tek.com>
Date: 6 Feb 90 18:57:48 GMT
Sender: nobody@orca.wv.tek.com
Reply-To: glennw@crevasse.WV.TEK.COM (Glenn Widener)
Organization: Tektronix, Inc., Wilsonville, OR
Lines: 435


There have been several requests for a "Hello World" program updated for
R4.  Here is the one I presented at my ICCCM tutorial at the MIT X
conference.  Yes, it does run!  It is a bit more than just a minimal Hello
World program; it demonstrates how to create client icon windows and
bitmaps, and how to handle Client Messages, using as an example a new
"client closedown" protocol that I have submitted to the Consortium for
review.

For more information, find the notes from my talk, or better yet, attend
the next edition of the ICCCM talk at Xhibition '90.
-----
/*
 * Copyright 1989 by the Massachusetts Institute of Technology, 
 * Cambridge, Massachusetts, and Tektronix, Inc. Beaverton, Oregon.
 *
 * Permission to use, copy, modify, distribute, and sell this software and
 * its documentation for any purpose is hereby granted without fee, provided
 * that the above copyright notice appear in all copies and that both that
 * copyright notice and this permission notice appear in supporting
 * documentation, and that the names of Tektronix or M.I.T. not be used in
 * advertising or publicity pertaining to distribution of the software
 * without specific, written prior permission.  Tektronix and M.I.T. make no
 * representations about the suitability of this software for any purpose.
 * It is provided "as is" without express or implied warranty.
 *
 * TEKTRONIX AND M.I.T. DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
 * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS,
 * IN NO EVENT SHALL TEKTRONIX OR M.I.T. BE LIABLE FOR ANY SPECIAL, INDIRECT
 * OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF
 * USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR
 * OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 * PERFORMANCE OF THIS SOFTWARE.
 *
 * Author:  Glenn Widener, Tektronix, Inc.
 *          P.O. Box 1000
 *          Wilsonville, OR, 97070
 *          glennw@orca.wv.tek.com
 *  Based on the r3 Hello World program by David Rosenthal.
 *
 *	NAME
 *		xhw_r4.c - an R4 Xlib Hello World program
 *
 *	DESCRIPTION
 *		This program is an update of the Hello World supplied by
 *		David Rosenthal on the R3 MIT X Consortium tape.  
 *		That program had no copyright; I have added the standard MIT
 *	        release copyright.
 *
 */

#include <stdio.h>
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/Xatom.h>

#define STRING	"Hello, world"
/* icon names should be as short as possible */
#define ICON_NAME	"Hello!"
#define BORDER	1
#define FONT	"fixed"
#define ICON_FILE		"smile"
#define ARG_ICON_FILE		"icon"
#define	ARG_FONT		"font"
#define	ARG_BORDER_COLOR	"bordercolor"
#define	ARG_FOREGROUND		"foreground"
#define	ARG_BACKGROUND		"background"
#define ARG_BORDER		"border"
#define	ARG_GEOMETRY		"geometry"
#define DEFAULT_GEOMETRY	""

char *ProgramName;
XWMHints    *xwmh;		/* WM Hints struct */
XSizeHints  *xsh;		/* Size hints for window manager */
XClassHint  *class_hint;	/* Class name hints for window manager */
Display	    *dpy;		/* X server connection */

void exit();

usage ()
{
    fprintf (stderr, 
	     "usage:  %s [-display host:dpy] [-geometry geom]\n", ProgramName);
    exit (1);
}

main(argc,argv)
    int argc;
    char **argv;
{
    Window      win;		/* Window ID */
    GC          gc;		/* GC to draw with */
    char       *fontName;	/* Name of font for string */
    XFontStruct *fontstruct;	/* Font descriptor */
    unsigned long fth, pad;	/* Font size parameters */
    unsigned long fg, bg, bd;	/* Pixel values */
    unsigned long bw;		/* Border width */
    char       *tempstr;	/* Temporary string */
    XColor      color;		/* Temporary color */
    Colormap    cmap;		/* Color map to use */
    XGCValues   gcv;		/* Struct for creating GC */
    XEvent      event;		/* Event received */
    char       *geomSpec = NULL;/* Window geometry string */
    XSetWindowAttributes xswa;	/* Temporary Set Window Attribute struct */
    int		junk;		/* ignore return values */
    unsigned int ujunk;		/* ignore return values */
    Window	wjunk;		/* ignore return values */
    unsigned int width, height;	/* of icon */
    unsigned int depth;		/* of root window/icon window */
    char	*icon_file;	/* file to get icon bitmap data from */
    char	*displayname = NULL;
    Atom	ClosedownAtom;	/* to ask for WM_CLOSEDOWN */
    Atom	WmProtocolsAtom;/* to read WM_CLOSEDOWN event */
    int         bitmask;	/* for ParseGeometry flags from XWMGeometry */
    int		i;
    Pixmap	icon_win_pixmap;/* for icon window */
    XTextProperty windowName, iconName;   /* ICCCM text */

    /* parse arguments for basic X args */

    ProgramName = argv[0];
    for (i = 1; i < argc; i++) {
	char *arg = argv[i];

	if (arg[0] == '-') {
	    switch (arg[1]) {
	      case 'd':			/* -display host:dpy */
		if (++i >= argc) usage ();
		displayname = argv[i];
		continue;
	      case 'g':			/* -geometry geom */
		if (++i >= argc) usage ();
		geomSpec = argv[i];
		continue;
	      default:
		usage ();
		/* doesn't return */
	    }
	} else 
	  usage ();
    }
    
    /*
     * Open the display using the $DISPLAY environment variable to locate
     * the X server.  See Section 2.1.
     */
    if ((dpy = XOpenDisplay(displayname)) == NULL) {
	fprintf(stderr, "%s: can't open %s\n", argv[0], 
	        XDisplayName(displayname));
	exit(1);
    }

    /*
     * Load the font and icon bitmap to use.  See Sections 10.2 & 6.5.1
     */
    if ((icon_file = XGetDefault(dpy, argv[0], ARG_ICON_FILE)) == NULL) {
	icon_file = ICON_FILE;
    }
    if ((fontName = XGetDefault(dpy, argv[0], ARG_FONT)) == NULL) {
	fontName = FONT;
    }
    if ((fontstruct = XLoadQueryFont(dpy, fontName)) == NULL) {
	fprintf(stderr, "%s: display %s doesn't know font %s\n",
		argv[0], DisplayString(dpy), fontName);
	exit(1);
    }
    fth = fontstruct->max_bounds.ascent + fontstruct->max_bounds.descent;

    /*
     * Select colors for the border,  the window background,  and the
     * foreground.  We use the default colormap to allocate the colors in.
     * Note that the border color will typically be overridden by the wm.
     * See Sections 2.2.1, 5.1.2, & 10.4.
     */
    cmap = DefaultColormap(dpy, DefaultScreen(dpy));
    if ((tempstr = XGetDefault(dpy, argv[0], ARG_BORDER_COLOR)) == NULL ||
	XParseColor(dpy, cmap, tempstr, &color) == 0 ||
	XAllocColor(dpy, cmap, &color) == 0) {
	bd = WhitePixel(dpy, DefaultScreen(dpy));
    }
    else {
	bd = color.pixel;
    }
    if ((tempstr = XGetDefault(dpy, argv[0], ARG_BACKGROUND)) == NULL ||
	XParseColor(dpy, cmap, tempstr, &color) == 0 ||
	XAllocColor(dpy, cmap, &color) == 0) {
	bg = BlackPixel(dpy, DefaultScreen(dpy));
    }
    else {
	bg = color.pixel;
    }
    if ((tempstr = XGetDefault(dpy, argv[0], ARG_FOREGROUND)) == NULL ||
	XParseColor(dpy, cmap, tempstr, &color) == 0 ||
	XAllocColor(dpy, cmap, &color) == 0) {
	fg = WhitePixel(dpy, DefaultScreen(dpy));
    }
    else {
	fg = color.pixel;
    }
    /*
     * Set the border width of the window,  and the gap between the text
     * and the edge of the window, "pad".
     */
    pad = BORDER;
    if ((tempstr = XGetDefault(dpy, argv[0], ARG_BORDER)) == NULL)
	bw = 1;
    else
	bw = atoi(tempstr);

    /*
     * Deal with providing the window with an initial position & size.
     * Fill out the XSizeHints struct to inform the window manager. See
     * Sections 9.1.7 & 10.3.
     */
    xsh = XAllocSizeHints();
    /* Ok, ok, so technically we should be checking for out of memory... */
    
    /*
     * For a program default size, fit the window to the text and locate it in
     * the center of the screen.  Make the minimum size such that the text is
     * always visible.
     */
    xsh->flags = (PPosition | PSize | PMinSize);
    xsh->height =
    xsh->min_height = fth + pad * 2;
    xsh->width = 
    xsh->min_width = XTextWidth(fontstruct, STRING, strlen(STRING)) + pad * 2;
    xsh->x = (DisplayWidth(dpy, DefaultScreen(dpy)) - xsh->width) / 2;
    xsh->y = (DisplayHeight(dpy, DefaultScreen(dpy)) - xsh->height) / 2;

    if (geomSpec == NULL)
	geomSpec = XGetDefault(dpy, argv[0], ARG_GEOMETRY);

    bitmask = XWMGeometry(dpy, DefaultScreen(dpy), geomSpec, 
			  DEFAULT_GEOMETRY, bw, xsh,
			  &(xsh->x), &(xsh->y),
			  &(xsh->width), &(xsh->height), &(xsh->win_gravity));
    /* XWMGeomtry does not set anything in the size hints structure */
    if (bitmask & (XValue | YValue)) {
        xsh->flags |= USPosition;
    }
    if (bitmask & (WidthValue | HeightValue)) {
        xsh->flags |= USSize;
    }

    /*
     * Create the Window with the information in the XSizeHints, the
     * border width,  and the border & background pixels. See Section 3.3.
     */
    win = XCreateSimpleWindow(dpy, DefaultRootWindow(dpy),
			      xsh->x, xsh->y, xsh->width, xsh->height,
			      bw, bd, bg);

    /*
     * Create the GC for writing the text and copying the icon pixmap.  See
     * Section 5.3.
     */
    gcv.font = fontstruct->fid;
    gcv.foreground = fg;
    gcv.background = bg;
    gc = XCreateGC(dpy, win, (GCFont | GCForeground | GCBackground), &gcv);

    /*
     * Set the standard properties for the window managers. See Section
     * 9.1.13.
     */

    /*
     * This structure forms the WM_HINTS property of the window, letting the
     * window manager know how to handle this window.  It may grow, so it is
     * dynamically allocated.  See Section 9.1.6 of the Xlib manual.
     */
    xwmh = XAllocWMHints();
    xwmh->flags = (InputHint|StateHint);
    xwmh->input = False;
    xwmh->initial_state = NormalState;
    /* unset fields are initialized to zero (they are ignored anyway) */

    if (XReadBitmapFile(dpy, win, icon_file, &width, &height,
		        &xwmh->icon_pixmap, &junk, &junk) == BitmapSuccess) {
	/*
	 * Create the icon window the size of the bitmap; ignore the
	 * WM_ICON_SIZE_HINTS and let the wm resize the window if it has to
	 * (the pixmap gets tiled in this case).  Do this cheap, to avoid
	 * handling exposure; use the window background to draw the desired
	 * pixmap.  Pixmap and window depth and visual are those of the root
	 * window.  The background pixmap must be of the depth of the window;
	 * fastest to let the server generate the bits from the depth one
	 * bitmap.  Border will be set by the WM, so usually this border
	 * pixel/width has no effect.  Window position is irrelevant.
	 */

	XGetGeometry(dpy, DefaultRootWindow(dpy), &wjunk, &junk, &junk,
			      &ujunk, &ujunk, &ujunk, &depth);
	icon_win_pixmap = XCreatePixmap(dpy, DefaultRootWindow(dpy),
				        width, height, depth);
	XCopyPlane(dpy, xwmh->icon_pixmap, icon_win_pixmap, gc, 0, 0,
		   width, height, 0, 0, 1);
	xswa.background_pixmap = icon_win_pixmap;
	xswa.border_pixel = bd;
	xwmh->icon_window = XCreateWindow(dpy, DefaultRootWindow(dpy),
			      0, 0, width, height, bw, CopyFromParent,
			      InputOutput, CopyFromParent,
			      (CWBackPixmap | CWBorderPixel),
			      &xswa);
	/* server keeps a copy of the pixmap */
	XFreePixmap(dpy, icon_win_pixmap);

	xwmh->flags |= (IconPixmapHint|IconWindowHint|IconPositionHint);
	/* for fun, center the icon on the screen (perhaps, approximately) */
	xwmh->icon_x = DisplayWidth(dpy, DefaultScreen(dpy)) >> 1;
	xwmh->icon_y = DisplayHeight(dpy, DefaultScreen(dpy)) >> 1;
    }
    else
	fprintf(stderr, "%s: Can't open bitmap file '%s' for icon\n",
		argv[0], icon_file);

    /*
     * Set the WM_CLASS property for the window managers. See Section
     * 9.1.8.
     */
    class_hint = XAllocClassHint();
    class_hint->res_name = argv[0];
    /* We set the program class name consistent with the XGetDefault code,
	   which is itself silly, and needs to be fixed... */
    class_hint->res_class = "Program";

    /*
     * XSetWMProperties() uses the new XTextProperty structure.  See Section
     * 9.1.2.
     */
    windowName.value = (unsigned char *) STRING;
    iconName.value = (unsigned char *) ICON_NAME;
    windowName.encoding = iconName.encoding = XA_STRING;
    windowName.format = iconName.format = 8;
    /* Note - nitems does not include a NULL terminator */
    windowName.nitems = strlen(STRING);
    iconName.nitems = strlen(ICON_NAME);

    XSetWMProperties(dpy, win, &windowName, &iconName, argv, argc, xsh, xwmh,
		     class_hint);

    /*
     * We don't really have to be informed of a connection close, but doing so
     * prevents dangling network resources and/or spurious error messages.
     * Note - WM_CLOSEDOWN is not yet part of the ICCCM!
     */
    ClosedownAtom = XInternAtom(dpy, "WM_CLOSEDOWN", False);
    WmProtocolsAtom = XInternAtom(dpy, "WM_PROTOCOLS", False);
    XSetWMProtocols(dpy, win, &ClosedownAtom, 1);

    /*
     * Ensure that the window's colormap field points to the default
     * colormap,  so that the window manager knows the correct colormap to
     * use for the window.  See Section 3.2.9. Also,  set the window's Bit
     * Gravity to reduce Expose events.
     */
    xswa.colormap = DefaultColormap(dpy, DefaultScreen(dpy));
    xswa.bit_gravity = CenterGravity;
    XChangeWindowAttributes(dpy, win, (CWColormap | CWBitGravity), &xswa);

    /*
     * Specify the event types we're interested in - only Exposures.  See
     * Sections 8.5 & 8.4.5.1
     */
    XSelectInput(dpy, win, ExposureMask);

    /*
     * Map the window to make it visible.  See Section 3.5.
     */
    XMapWindow(dpy, win);

    /*
     * Loop forever,  examining each event.
     */
    while (1) {
	/*
	 * Get the next event
	 */
	XNextEvent(dpy, &event);

	/*
	 * On the last of each group of Expose events,  repaint the entire
	 * window.  See Section 8.4.5.1.
	 */
	if (event.type == Expose && event.xexpose.count == 0) {
	    int         x, y;

	    /*
	     * Remove any other pending Expose events from the queue to
	     * avoid multiple repaints. See Section 8.7.
	     */
	    while (XCheckTypedEvent(dpy, Expose, &event));

	    /*
	     * Find out how big the window is now,  so that we can center
	     * the text in it.
	     */
	    if (XGetGeometry(dpy, win, &wjunk, &junk, &junk, 
			     &width, &height, &ujunk, &ujunk) == 0)
		break;
	    x = (width - XTextWidth(fontstruct, STRING, strlen(STRING))) / 2;
	    y = (height + fontstruct->max_bounds.ascent
		 - fontstruct->max_bounds.descent) / 2;

	    /*
	     * Fill the window with the background color,  and then paint
	     * the centered string.
	     */
	    XClearWindow(dpy, win);
	    XDrawString(dpy, win, gc, x, y, STRING, strlen(STRING));
	}
	else if ((event.type == ClientMessage) &&
		 (event.xclient.message_type == WmProtocolsAtom) &&
		 (event.xclient.data.l[0] == ClosedownAtom)) {
	    Cleanup();
	}
    }
    Cleanup();
}

Cleanup()
{
    /* just to be truly kosher */
    XFree(xwmh);
    XFree(class_hint);
    XFree(xsh);
    /* enough kosher is enough, close the display to free server resources */
    XCloseDisplay(dpy);
    exit(1);
}
Glenn Widener
Tektronix, Inc.
(UPS) 2660 SW Parkway
(US Mail) PO Box 1000


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!keith Mon Feb 12 09:22:57 PST 1990
Subject: Re: The easiest way to speed up X11R4
Status: O

Article 18823 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!keith
>From: keith@EXPO.LCS.MIT.EDU (Keith Packard)
Newsgroups: comp.windows.x
Subject: Re: The easiest way to speed up X11R4
Message-ID: <9002081626.AA21959@xenon.lcs.mit.edu>
Date: 8 Feb 90 16:26:23 GMT
References: <8968@portia.Stanford.EDU>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 46


> Suppose I wanted to spend, say, a day making X11R4 faster for my
> particular hardware. What would be the best way to spend my time?
> I am interested in 8 bit color speedups at the expense of portability.

As usual, this depends almost completely on what you will be using the
server for.  The R4 server is actually pretty good at a wide range of
common tasks.

> The README for the cfb directory says the cfb code is "very slow".

The README file was not updated for R4.  Look at the CHANGES file and
you'll see a more promising comment:

"This directory now provides a real implementation for 8-bit frame buffers,
 driving the frame buffer at memory bandwidth for many operations"

The most heavily tuned operations are BitBlt, text painting, line drawing
and rectangle filling.  For these operations, you'd be hard pressed to
get much performance increase even coding them in assembly.

> For those interested in receiving a copy, I'll be doing this for
> the MC68030.

The R4 server has code which is tuned for the 68020 family; it allows you
to specify a few machine characteristics which guide the compiler to the
correct bits of code.

> Even more specifically, it will be for the Macintosh II.

This is the bad news.  The Mac II frame buffer cards which sit on the NuBus
have memory latency of ~1us per access; and no special block-mode optimizations
which give them a bandwidth of 4Mb/sec (4 bytes/access).  Nothing the R4 server
does can help this out; you end up with a server which runs 2.5times slower
than a Sun 3/60.

Some of the newer Macintoshes have on-board frame buffers.  I expect that
eliminating the NuBus would give them more respectable frame buffer latency
numbers, but I haven't ever had a chance to bench mark them running our code.

If you want to start tuning the R4 code, get a copy of x11perf and start
measuring.  As usual, any changes you make would be welcome at MIT if directed
at 'xbugs@expo.lcs.mit.edu'.

Keith Packard
MIT X Consortium


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws Mon Feb 12 09:31:25 PST 1990
Subject: X11R4 public fix #2 is now available on expo
Status: O

Article 18853 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
>From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: X11R4 public fix #2 is now available on expo
Message-ID: <9002091938.AA01089@expire.lcs.mit.edu>
Date: 9 Feb 90 19:38:37 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 22

Fixes are available via anonymous ftp to expo.lcs.mit.edu (18.30.0.212), in
the directory /pub/R4/fixes/, in files with prefix "fix-".  The second fix,
now available, is "fix-2".  Fixes get put there in batches at intervals only.
Fixes usually propagate to other distribution sites as well, so it may pay
to check at a nearer site first.

For those without ftp access, individual fixes can be obtained by mail by
sending a message to xstuff@expo.lcs.mit.edu.  In the usual case, the
message should have a subject line and no body, or a single-line body and
no subject, in either case the line looking like:
	send fixes 2
(to get the second fix).  To get a summary of fixes, make the line:
	index fixes
If you need help, make the line:
	help
Some mailers produce mail headers that are unusable for extracting return
addresses.  If you use such a mailer, you won't get any response.  If you
happen to know an explicit path, you can include a line like
	path foo%bar.bitnet@mitvma.mit.edu
or
	path zot!gzork!me@uunet.uu.net
in the body of your message, and the daemon will use it.


From ucla-cs!usc!apple!voder!zok!mark Thu Feb 15 09:01:42 PST 1990
Subject: Announcing West Coast UUCP X11 Archive
Status: O

Article 19084 of comp.windows.x:
Path: ucla-cs!usc!apple!voder!zok!mark
>From: mark@zok.UUCP (Mark W. Snitily)
Newsgroups: comp.windows.x
Subject: Announcing West Coast UUCP X11 Archive
Message-ID: <447@zok.UUCP>
Date: 14 Feb 90 18:03:36 GMT
Organization: The distant planet Zok
Lines: 51


#########################################################################
#################          A n n o u n c i n g          #################
#################          W e s t   C o a s t          #################
#################   U U C P    X 1 1    A r c h i v e   #################
#########################################################################

Good News:  We now have a UUCP X11 archive site on the west coast again.

The X archive on Zok contains the full X11R4 distribution, the XTEST
distribution, an *entire* archive of comp.sources.x, along with many
other X11 goodies.

Zok has a TB+ modem which will connect to 19.2K, 2400, 1200 baud (in
that order).  The anonymous UUCP account is UXarch with password of
Xgoodies.  The modem's phone number is 408-996-8285.

A sample Systems (or L.sys) entry might be:

   zok Any ACU 19200 4089968285 in:--in: UXarch word: Xgoodies

To get a current listing of the files that are available, download
the file "/usrX/ls-lR.Z".

A full subject index of the comp.sources.x files is available in the
file "/usrX/comp.sources.x/INDEX".

When downloading files with uucp, wildcards (i.e. "*") won't work.  Be
sure to specify the full pathname starting with "/usrX/".  For example,

   uucp zok\!/usrX/ls-lR.Z \!~

(The above "\"'s are csh escapes, ignore them if you're using sh.)

Currently this modem line is Zok's only email and news connection to
the outside world.  Should you wish to fetch large distributions, such
as X11R4, it would be appreciated if you would pause every now and then
so that normal UUCP traffic may continue.  Thanks.

-- Mark

Mark W. Snitily                 Consulting Services:
894 Brookgrove Lane             Graphics, Operating Systems, Compilers
Cupertino, CA 95014             (408) 252-0456
mark@zok.uucp

     Zok, one of the distant planets occasionally visited by
          "Spaceman Spiff," Conqueror of the Cosmos,
                            Bold Interplanetary Explorer,
                            Interplanetary Explorer Extraordinaire.
          (Also known as Calvin, of "Calvin and Hobbes.")


From ucla-cs!tek Fri Feb 16 08:58:05 PST 1990
Subject: WM_ICON_SIZE
Status: O

Article 19152 of comp.windows.x:
Path: ucla-cs!tek
>From: tek@penzance.cs.ucla.edu
Newsgroups: comp.windows.x
Subject: WM_ICON_SIZE
Message-ID: <31926@shemp.CS.UCLA.EDU>
Date: 15 Feb 90 19:04:44 GMT
Sender: news@CS.UCLA.EDU
Reply-To: tek@CS.UCLA.EDU (Ted Kim (Random Dude))
Organization: UCLA
Lines: 15

A question for you IC3M gurus:

If a window manager decides to give hints about icon sizes, it sets the
WM_ICON_SIZE property on the root window. Does this mean there might be
many different WM_ICON_SIZE properties, one on each screen's root window?

Or is this like the RESOURCE_MANAGER property, which only makes its
appearance on screen zero's root window?

-ted

Ted Kim                           
UCLA Computer Science Department  Internet: tek@penzance.cs.ucla.edu
3804C Boelter Hall                UUCP:    ...!{uunet|ucbvax}!cs.ucla.edu!tek
Los Angeles, CA 90024		  Phone:   (213) 206-8696


From ucla-cs!usc!cs.utexas.edu!hellgate.utah.edu!helios.ee.lbl.gov!epb2.lbl.gov!envbvs Fri Feb 16 09:05:06 PST 1990
Subject: Re: bringing xfig upto scratch. idraw issues.
Status: O

Article 19171 of comp.windows.x:
Path: ucla-cs!usc!cs.utexas.edu!hellgate.utah.edu!helios.ee.lbl.gov!epb2.lbl.gov!envbvs
>From: envbvs@epb2.lbl.gov (Brian V. Smith)
Newsgroups: comp.windows.x,comp.text
Subject: Re: bringing xfig upto scratch. idraw issues.
Message-ID: <4866@helios.ee.lbl.gov>
Date: 15 Feb 90 23:19:03 GMT
References: <2846@goanna.oz.au>
Sender: usenet@helios.ee.lbl.gov
Reply-To: envbvs@epb2.lbl.gov (Brian V. Smith)
Organization: lbl
Lines: 60
Xref: ucla-cs comp.windows.x:19171 comp.text:6795
X-Local-Date: 15 Feb 90 15:19:03 PST

In article <2846@goanna.oz.au>, isaac@goanna.oz.au (Isaac Balbin) writes:
> I am contemplating giving a programming project to a group
> of 3rd year undergraduate students that would involve bringing
> xfig to a better state. I mean, at least bringing it to a state where
> it has all the features of fig-fs, and handles text (scaling, size etc)
> better than fig-fs. Perhaps they might also bring some features from 
> idraw to this new version of xfig. My motivation is clearly selfish,
> with an X-terminal to land on my desk in the nearish future (Visual
> Technology, are you listening, how is production of your 19" Turbo
> going). Is anyone undertaking such a project or is it in the pipeline?
> I guess they might use the Athena widget set. I don't know. I haven't even 
> looked at the code ...
> By the way, has anyone thought of an idraw to fig conversion program
> or even idraw to eepic or something? How hard would this be?
> Suggestions and comments welcome.		isaac@goanna.cs.rmit.OZ.AU
> 
> PS. All this because I use transfig and eepic for my TeX diagrams and find it
>     most convenient since you can actually preview the diagrams as well with
>     say xdvi or xtex!

Wellll,  I didn't want to say anything until I brought the documentation
up to date, but I have been hacking at xfig and have added the following 
features:

o Area fill for circles, boxes, etc. with 20 different gray shades
  for Postscript output

o 35 different fonts - the 35 fonts normally included with the Laserwriters
  can be used in figures at any point size.  If there is a corresponding
  font in X, then the text is shown in that font on the screen.

o text can be virtually any point size

o left, center and right justification of text

o rounded-corner boxes with any radius of the corners

o different line thicknesses

o lower button panel for quick access to "save", "chdir", etc. functions.

o button to change the line thickness of an existing object 

o button to change the line type of an existing object

o portrait or landscape print mode 

I have NOT supported the sunview code in xfig (for those who didn't know,
xfig can be compiled for X11 or sunview) and have stripped that code out
in some modules.

If there is any interest in this hacked xfig, I can post it to comp.sources.x
I would like to at least update the man entry, though, to show the new
features.

*** I will call it nxfig to distinguish it from the original xfig.
_____________________________________
Brian V. Smith    (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.


From ucla-cs!rutgers!cs.utexas.edu!uunet!island!dave Mon Feb 19 09:18:44 PST 1990
Subject: Desktop Publishing Programs with OSF/Motif
Status: O

Article 19262 of comp.windows.x:
Path: ucla-cs!rutgers!cs.utexas.edu!uunet!island!dave
>From: dave@island.uu.net (David Newman)
Newsgroups: comp.windows.x,comp.windows.news
Subject: Desktop Publishing Programs with OSF/Motif
Keywords: X11 OSF/Motif publishing DTP
Message-ID: <1390@island.uu.net>
Date: 14 Feb 90 17:51:58 GMT
Reply-To: dave@island.uu.net (David Newman)
Followup-To: comp.windows.x
Organization: Island Graphics, Marin County, California
Lines: 101
Xref: ucla-cs comp.windows.x:19262 comp.windows.news:2030


longs.LANCE.ColoState.Edu!robert writes:
>
>In article <6478@ogicse.ogc.edu> goward@ogicse.ogc.edu (Philip Goward) writes:
>>
>> 
>> Hi!
>>  
>>  I'm looking for MacPaint and MacWrite style software for
>>  X or NeWS (preferably in the public domain).  Anyone know
>>  any location I can obtain these from?
>>   
>>   Also if anyone out there has a version of troff that runs
>>   under X or NeWS and the sources for it are available....
>
>I don't know of a word processing appliction for X (if someone does please
>post the source as I am looking for the same thing)  The other applications
>are available at:
>
>	expo.lcs.mit.edu           18.30.0.212     
>
>Or just about any other comp.sources.x archive site.  Hope this helps.
>
>Robert Thompson
>Center for Computer Assisted Engineering
>Colorado State University
>

[caution: Press Release Ahead :-]

In response to the inquiry about paint and desktop publishing
software for X, Island Graphics Corporation, the company that
along with Sun Microsystems created SunWrite, SunPaint, and 
SunDraw, has announced a new suite of office publishing
applications that run with OSF/Motif.

Here are excerpts from a February 9, 1990 posting in comp.newprod: 

                    ISLAND GRAPHICS INTRODUCES
                   THE ISLAND OFFICE SERIES(tm)
                  UNDER OSF/MOTIF(tm) AT UNIFORUM


         IslandWrite(tm), IslandPaint(tm) & IslandDraw(tm)
            Shown on HP's Apollo Personal Workstations
              and on HP 9000 Series 300 Workstations

     WASHINGTON, D.C. January 23, 1990 -- Island Graphics
Corporation introduced its newest office publishing applica-
tions, IslandWrite, IslandPaint, and IslandDraw under the X
Window System-based OSF/Motif graphical user interface, at
UniForum today.  The products, the first in the Island
Office Series, were shown on HP's Apollo personal worksta-
tions and HP 9000 Series 300 workstations in Island's booth,
and in the Hewlett-Packard Company booth.

       The Island Office Series is intended to serve office
publishing needs ranging from writing memos and letters to
creating illustrated reports and newsletters.  IslandWrite
is a word processing and desktop publishing package that
accepts graphics from IslandDraw, an object-oriented illus-
tration package, and IslandPaint, a raster graphics editor.
Each program provides PostScript(R) output to laser
printers and imagesetters.

     The Island Office Series will be distributed by the
Apollo Direct Channel beginning April 1, 1990, for the
Apollo personal workstations, and July 1, 1990, for the HP
Series 300 workstations.  Apollo Direct is an after-market
sales channel that enables Apollo users to select from a
wide variety of products that add functionality to their
installed equipment.  IslandWrite is priced at $595, while
IslandPaint and IslandDraw can be purchased together for
$495.  The U.S. toll-free number for Apollo Direct is 1-
800-225-5290.  The Island Office Series runs on the entire
Apollo personal workstation family, ranging from the Series
2500 to the Series 4500.  It also runs on the HP 9000 Series
300.
         Island Graphics Corporation, headquartered in San
Rafael, California, is the leading developer of UNIX desktop
publishing and prepress software.  Island Graphics has
created a wide range of products for publishing and prepress
system vendors in the United States, Europe, and Japan,
including Sun Microsystems, Nixdorf, Dainippon Screen
Manufacturing Company, AT&T Information Systems, AGFA Compu-
graphic, ArborText and H. Berthold Fototype.

                            -30-

UNIX is a trademark of AT&T. OSF/Motif is a trademark of the
Open Software Foundation, Inc.  PostScript is a registered 
trademark of Adobe Systems, Inc.

Contact:        David Newman            Lynn Wehner
                Marketing Manager       Public Relations
                Island Graphics         Hewlett-Packard Company
                415/491-1000            508/256-6600  x 7717
                dave@island.uu.net


From ucla-cs!usc!apple!voder!zok!mark Mon Feb 19 16:44:05 PST 1990
Subject: West Coast UUCP X11 Archive Update
Status: O

Article 19281 of comp.windows.x:
Path: ucla-cs!usc!apple!voder!zok!mark
>From: mark@zok.UUCP (Mark W. Snitily)
Newsgroups: comp.windows.x
Subject: West Coast UUCP X11 Archive Update
Message-ID: <461@zok.UUCP>
Date: 19 Feb 90 17:23:33 GMT
Organization: The distant planet Zok
Lines: 95

#########################################################################
#################          W e s t   C o a s t          #################
#################   U U C P    X 1 1    A r c h i v e   #################
#################              U p d a t e              #################
#########################################################################

19-Feb-90

The /usrX/contrib tree has been augmented since announcing the X11 archive
last week.  zok!/usrX/contrib is now up to date (more or less) with the
/contrib directory tree on expo.lcs.mit.edu (18.30.0.212).  In particular,
X11R4 contrib fixes are available in /usrX/contrib/R4fixes.  Also, official
fix #2 from MIT is available in /usrX/pub/R4/fixes/fix-2.  Please obtain
a new ls-lR.Z listing file if you're interested.

A common problem has been specifying an incorrect pathname/filename when
downloading a file.

   -- The "/usrX/ls-lR.Z" file is simply the output of a "ls -lR" command,
      so ALL PATHNAMES/FILENAMES SHOULD BE OBTAINED FROM THIS FILE.

   -- The "/usrX/comp.sources.x/INDEX" is a subject index of the
      comp.sources.x files.  The actual files are compressed, so they
      almost always have a ".Z" suffix.  Also, each volume is in a
      separate subdirectory. (The ".Z" and the subdirectory are not
      listed in the INDEX file.)

   -- Here are some examples, ("\" are csh escapes):

      uucp zok\!/usrX/ls-lR.Z \!~
      uucp zok\!/usrX/pub/R4/fixes/fix-2 \!~
      uucp zok\!/usrX/pub/R4/tape-1/tape-1.01 \!~
      uucp zok\!/usrX/contrib/xldim103.tar.Z \!~
      uucp zok\!/usrX/contrib/XView/olgx-1.Z \!~
      uucp zok\!/usrX/contrib/R4fixes/winterp/patch-0 \!~
      uucp zok\!/usrX/comp.sources.x/INDEX \!~
      uucp zok\!/usrX/comp.sources.x/v00/v00INF1.Z \!~
      uucp zok\!/usrX/comp.sources.x/v05/v05i064.Z \!~

If you have any questions and/or problems feel free to email.  Note
that after you've added zok to your Systems or L.sys file, you can send
email *directly* to me using the uucp bang notation:  zok!mark  (Don't
forget a "\" escape on the "!" if using csh.)  If you email directly,
be sure to include a return path since replies will have to be routed
through established uucp connections.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
The remainder of this article is a copy of the original X11 archive
announcement from last week,  (i.e. skip the rest of this if you've
already seen it, nothing new).

14-Feb-90

The X archive on Zok contains the full X11R4 distribution, the XTEST
distribution, an *entire* archive of comp.sources.x, along with many
other X11 goodies.

Zok has a TB+ modem which will connect to 19.2K, 2400, 1200 baud (in
that order).  The anonymous UUCP account is UXarch with password of
Xgoodies.  The modem's phone number is 408-996-8285.

A sample Systems (or L.sys) entry might be:

   zok Any ACU 19200 4089968285 in:--in: UXarch word: Xgoodies

To get a current listing of the files that are available, download
the file "/usrX/ls-lR.Z".

A full subject index of the comp.sources.x files is available in the
file "/usrX/comp.sources.x/INDEX".

When downloading files with uucp, wildcards (i.e. "*") won't work.  Be
sure to specify the full pathname starting with "/usrX/".  For example,

   uucp zok\!/usrX/ls-lR.Z \!~

(The above "\"'s are csh escapes, ignore them if you're using sh.)

Currently this modem line is Zok's only email and news connection to
the outside world.  Should you wish to fetch large distributions, such
as X11R4, it would be appreciated if you would pause every now and then
so that normal UUCP traffic may continue.  Thanks.

-- Mark

Mark W. Snitily                 Consulting Services:
894 Brookgrove Lane             Graphics, Operating Systems, Compilers
Cupertino, CA 95014             (408) 252-0456
mark@zok.uucp

     Zok, one of the distant planets occasionally visited by
          "Spaceman Spiff," Conqueror of the Cosmos,
                            Bold Interplanetary Explorer,
                            Interplanetary Explorer Extraordinaire.
          (Also known as Calvin, of "Calvin and Hobbes.")


From ucla-cs!usc!cs.utexas.edu!jarvis.csri.toronto.edu!neat.cs.toronto.edu!church.csri.toronto.edu!moraes Tue Feb 20 08:55:04 PST 1990
Subject: fixes for R4 xplaces, xcpustate, xpic, xtroff, Xw
Status: O

Article 19321 of comp.windows.x:
Path: ucla-cs!usc!cs.utexas.edu!jarvis.csri.toronto.edu!neat.cs.toronto.edu!church.csri.toronto.edu!moraes
>From: moraes@csri.toronto.edu (Mark Moraes)
Newsgroups: comp.windows.x
Subject: fixes for R4 xplaces, xcpustate, xpic, xtroff, Xw
Message-ID: <90Feb20.021140est.1003@church.csri.toronto.edu>
Date: 20 Feb 90 07:13:19 GMT
Lines: 123

I've put the following patches for anonymous ftp on expo.lcs.mit.edu
(18.30.0.212) in contrib/

-rw-rw-rw-  1 ftp      30            645 Feb 20 01:47 Xw.README
-rw-rw-rw-  1 ftp      30           7170 Feb 20 01:47 Xw.fix01
-rw-rw-rw-  1 ftp      30        1545586 Feb 20 01:55 Xw.tar.Z
-rw-rw-rw-  1 ftp      30            392 Feb 20 01:55 xcpustate.README
-rw-rw-rw-  1 ftp      30           8513 Feb 20 01:55 xcpustate.fix01
-rw-rw-rw-  1 ftp      30          21127 Feb 20 01:55 xcpustate.tar.Z
-rw-rw-rw-  1 ftp      30            268 Feb 20 01:55 xpic.README
-rw-rw-rw-  1 ftp      30           8846 Feb 20 01:55 xpic.fix11
-rw-rw-rw-  1 ftp      30         305828 Feb 20 01:57 xpic.tar.Z
-rw-rw-rw-  1 ftp      30            253 Feb 20 01:57 xplaces.README
-rw-rw-rw-  1 ftp      30          11441 Feb 20 01:57 xplaces.fix03
-rw-rw-rw-  1 ftp      30          22322 Feb 20 01:57 xplaces.tar.Z
-rw-rw-rw-  1 ftp      30            140 Feb 20 01:57 xtroff.README
-rw-rw-rw-  1 ftp      30          23242 Feb 20 01:57 xtroff.fix09
-rw-rw-rw-  1 ftp      30         421889 Feb 20 02:00 xtroff.tar.Z

They're also on cs.toronto.edu (128.100.1.65) in pub/X.

The .fix* files are all the first patches to the versions of the
programs/widgets distributed with R4 (despite the higher patch numbers
for some of them), and make the programs/widgets compile and work
under R4.  The .tar.Z files are new versions of the full program
source, patched to the patchlevels of the fix* files for those who
don't want to use patch, or don't have the R4 contrib tapes.

The fixes are on their way to comp.sources.x.

Use 
	patch -p
from the top level directory to apply these patches.

New Makefiles are not distributed with these patches -- please remember
to rebuild the Makefiles with 'make Makefile' or xmkmf after applying
the patch.  xtroff and Xw also require 'make Makefiles' to regenerate
the Makefiles for the subdirectories.

The xtroff fix does not contain the regenerated files for devpsc and
devX11.  They are in xtroff.tar.Z or can be generated with a little
work.

Each patch has a CHANGES.Pat?? file in it describing what it changes.
I've included those in this message.  Some patches update the READMEs
-- if so, please read the README again, or the patch to see what's
changed.

	Mark.

::::::::::::::
contrib/clients/xcpustate/CHANGES.Pat01
::::::::::::::
- puts the hostname in the bar for s-bsd.

- system file for Cray XMP systems from Walter Poxon <wdp@zeus.cray.com>
  Thanks.  (I haven't a Cray to test this, alas:-)

- uses stippling instead of tiling to avoid hallucinogenic effects
  on colour displays

- uses the R4 include and Imakefile conventions
::::::::::::::
contrib/clients/xpic/CHANGES.Pat11
::::::::::::::
- added tune.h dependencies explicitly to Imakefile so people
  don't get burnt if they forget to run make depend.

- used a more accurate font scaling formula (use POINT_SIZE instead of
  PIXEL_SIZE)
::::::::::::::
contrib/clients/xplaces/CHANGES.Pat03
::::::::::::::
- Uses XGetWMSizeHints instead of XGetNormalHints so that it can
use PBaseSize in compliance with ICCCM.  Now gets R4 xterm size
right (used to be off by 1)  Thanks to Casey Leedom <casey@gauss.llnl.gov>
for this one.

- xplaces doesn't whine about toplevel windows without WM_COMMAND now.

- rcmd much improved -- runs much faster on machines without builtin
test in the shell, can take multiple commands for a single machine
from stdin (rsh is too slow for csh users to afford one per remote
command)
::::::::::::::
contrib/clients/xtroff/CHANGES.Pat09
::::::::::::::
- fixes a definition of XawScrollbarSetThumb that changed in R4 so xtroff
  compiles. Imakefile follows R4 conventions.

- can read from stdin again.

- fix of backward scroll page with "xtroff -full" problem. (from dac@cray.com)

- specification of "unsigned" in dev.h (from dac@cray.com)

- fakes 'z' command from Berkeley ditroff with BSpline instead of Bezier.
  (from Andreas Stolcke, stolcke@icsib12.Berkeley.EDU)

- Updated README.X11 to reflect R4 reality.
::::::::::::::
contrib/toolkits/Xw/CHANGES.Pat01
::::::::::::::
[The existence of patchlevel.h and this patch do not imply continued
 support for these.  I like and use these widgets, and would like to
 hear of changes -- from time to time, I may be convinced to release
 patches so we all have a single source version for these widgets.
 The official policy if these widgets don't work is to dig out your
 favourite text editor, debugger, and go to it... If you want support
 or 3D special-effects, try Motif or OpenLook or whatever the
 product-of-the-day is - moraes@cs.toronto.edu]

- a fix from mcintosh@maple.bellcore.com (Allen Mcintosh) to handle
  ReverseVideo properly.

- a fix from jcr@ulysses.att.com so the text widget does not go into
  an infinite loop when text.length is 0.

- a small fix to MButton.c for R4 include conventions, and an
  Imakefile for that subdirectory.

- added XtInheritSetValuesAlmost to Titlebar.c and MenuMgr.c to stop
  Xt whining when running xwebster


From ucla-cs!elroy.jpl.nasa.gov!lll-winken!uwm.edu!cs.utexas.edu!hellgate.utah.edu!helios.ee.lbl.gov!epb2.lbl.gov!envbvs Tue Feb 20 20:02:30 PST 1990
Subject: new xfig version 2.0
Status: O

Article 19346 of comp.windows.x:
Path: ucla-cs!elroy.jpl.nasa.gov!lll-winken!uwm.edu!cs.utexas.edu!hellgate.utah.edu!helios.ee.lbl.gov!epb2.lbl.gov!envbvs
>From: envbvs@epb2.lbl.gov (Brian V. Smith)
Newsgroups: comp.windows.x
Subject: new xfig version 2.0
Keywords: new features, no SunView support anymore
Message-ID: <4904@helios.ee.lbl.gov>
Date: 20 Feb 90 19:45:08 GMT
Sender: usenet@helios.ee.lbl.gov
Reply-To: envbvs@epb2.lbl.gov (Brian V. Smith)
Organization: lbl
Lines: 55
X-Local-Date: 20 Feb 90 11:45:08 PST

I have put the new version of xfig on expo.lcs.mit.edu (18.30.0.212)
in the contrib/ directory, in the file xfig-2.0.tar.Z.

Be sure to set binary mode when retrieving it.

I have also mailed the sources to x-sources, so it should appear on 
comp.sources.x sometime soon.

NOTE: Version 2.0 of xfig no longer supports SunView!  If you wish to
      retain compatibility with SunView, use version 1.4.3.

Added Features:
===============

o Separate version number for program vs file format (protocol now 1.4X)

o Area fill for circles, boxes, etc. with 20 different gray shades
  for Postscript output

o 35 different fonts - the 35 fonts normally included with the Laserwriters
  can be used in figures at any point size.  If there is a corresponding
  font in X, then the text is shown in that font on the screen.

o text can be virtually any point size

o left, center and right justification of text

o rounded-corner boxes with any radius of the corners
  "pen" component of the object is used for the radius (in pixels)

o different line thicknesses

o lower button panel for quick access to "save", "chdir", etc. functions

o button to change the line thickness of an existing object

o button to change the line type of an existing object

o portrait or landscape print mode

NOTE: I will support these features as best I can, but I cannot promise
      anything, as my normal workload is pretty full.
      Brian Smith
      (bvsmith@lbl.gov)


Deleted Features:
=================

o f2p (fig to pic) support not updated for above features

_____________________________________
Brian V. Smith    (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.


From ucla-cs!usc!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!ucsd!helios.ee.lbl.gov!epb2.lbl.gov!envbvs Tue Feb 20 20:08:47 PST 1990
Subject: first patch to f2ps.c (new xfig)
Status: O

Article 19362 of comp.windows.x:
Path: ucla-cs!usc!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!ucsd!helios.ee.lbl.gov!epb2.lbl.gov!envbvs
>From: envbvs@epb2.lbl.gov (Brian V. Smith)
Newsgroups: comp.windows.x
Subject: first patch to f2ps.c (new xfig)
Keywords: context diff
Message-ID: <4908@helios.ee.lbl.gov>
Date: 20 Feb 90 23:34:29 GMT
Sender: usenet@helios.ee.lbl.gov
Reply-To: envbvs@epb2.lbl.gov (Brian V. Smith)
Organization: lbl
Lines: 50
X-Local-Date: 20 Feb 90 15:34:29 PST

There had to be at least one mistake!
Here is a context diff for f2ps.c to rid it of it's dependency
on put_msg and CFREE/FREE.

*** f2ps.c.orig	Tue Feb 20 15:16:47 1990
--- f2ps.c	Tue Feb 20 15:15:25 1990
***************
*** 14,19
  #include "resources.h"
  #include "psfonts.h"
  
  #define		PAGE_WIDTH		612	/* points; 8.5" */
  #define		PAGE_HEIGHT		792	/* points; 11" */
  #define		POINT_PER_INCH		72

--- 14,22 -----
  #include "resources.h"
  #include "psfonts.h"
  
+ #undef cfree
+ #undef free
+ 
  #define		PAGE_WIDTH		612	/* points; 8.5" */
  #define		PAGE_HEIGHT		792	/* points; 11" */
  #define		POINT_PER_INCH		72
***************
*** 814,816
  
  	return(0);
  	}

--- 817,828 -----
  
  	return(0);
  	}
+ 
+ /*VARARGS1*/
+ put_msg(format, arg1, arg2, arg3, arg4, arg5)
+ 	char    *format;
+ 	int     arg1, arg2, arg3, arg4, arg5;
+ {
+ 	fprintf(stderr, format, arg1, arg2, arg3, arg4, arg5);
+ }
+ 


_____________________________________
Brian V. Smith    (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.


From ucla-cs!usc!snorkelwacker!bloom-beacon!osf.ORG!vania Mon Feb 26 08:34:37 PST 1990
Subject: Re: Motif texts
Status: O

Article 19668 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!osf.ORG!vania
>From: vania@osf.ORG (Vania Joloboff)
Newsgroups: comp.windows.x
Subject: Re: Motif texts
Message-ID: <9002261514.AA11749@osf.osf.org>
Date: 26 Feb 90 15:14:52 GMT
References: <4449@rouge.usl.edu>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 11


I have in my office 5 books edited by Prentice Hall.
The five books references are:

OSF/Motif Style Guide ISBN 0-13-640491-X
OSF/Motif User's Guide ISBN 0-13-640509-6
OSF/Motif Programmer's Reference ISBN 0-13-640517-7
OSF/Motif Programmer's Guide ISBN 0-13-640525-8
OSF/Motif Application Environment specifications (AES) ISBN 0-13-640483-9

The author is "Open Software Foundation".


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!jim Mon Feb 26 08:34:59 PST 1990
Subject: Re: Alternate fonts under twm
Status: O

Article 19670 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!jim
>From: jim@EXPO.LCS.MIT.EDU (Jim Fulton)
Newsgroups: comp.windows.x
Subject: Re: Alternate fonts under twm
Message-ID: <9002261521.AA07211@kanga.lcs.mit.edu>
Date: 26 Feb 90 15:21:01 GMT
References: <4336@quanta.eng.ohio-state.edu>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: X Consortium, MIT Laboratory for Computer Science
Lines: 13


> Is it possible to specify fonts other than "fixed", "variable" or
> "8x13" in twm?

Yes, see the descriptions in twm(1) of the following .twmrc keywords:

	IconFont
	IconManagerFont
	MenuFont
	ResizeFont
	TitleFont

or look in sample-twmrc/*.twmrc.


From ucla-cs!usc!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!tank!mimsy!mojo!stripes Tue Feb 27 09:48:44 PST 1990
Subject: Re: Running Xsun in color
Status: O

Article 19699 of comp.windows.x:
Path: ucla-cs!usc!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!tank!mimsy!mojo!stripes
>From: stripes@eng.umd.edu (Joshua Osborne)
Newsgroups: comp.windows.x
Subject: Re: Running Xsun in color
Summary: su & MAKEDEV
Message-ID: <1990Feb26.235401.17631@eng.umd.edu>
Date: 26 Feb 90 23:54:01 GMT
References: <9002211844.AA02401@amd-20.>
Sender: news@eng.umd.edu (The News System)
Organization: Maryversity of Uniland, College Park
Lines: 21

In article <9002211844.AA02401@amd-20.> dhuff@AMD-20.HAC.COM(Daryl Huff) writes:
>I have the cgfour device in my sun 3 but I can only get the monochrome
>server to appear.  How do I get the color screen to "appear"?  Is it a 
>command line option?  A screen number other than 0?

You probbly have the same problem we use to have  :-)

Suntools (apparently) opens /dev/fb and does everything with that.  X requires
the proper frame buffer device.  For example rohan's /dev has:
crw-rw-rw-  1 root      27,   1 Mar 10  1989 /dev/bwtwo1
crw-rw-rw-  1 root      39,   0 Mar 10  1989 /dev/cgfour0

The easyest way to make those devices is to su to root cd to /dev and 
MAKEDEV the devices.  (harder was involve su and mknode, obscure bugs and
mknode, or the disk and a magnetic source...).
-- 
           stripes@wam.umd.edu          "Security for Unix is like
      Josh_Osborne@Real_World,The          Mutitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
"Don't try to change C into some nice, safe, portable programming language
 with all sharp edges removed, pick another language."  - John Limpert


From ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!EXPO.LCS.MIT.EDU!rws Thu Mar  1 14:34:11 PST 1990
Subject: Re: need help using Xlib to zoom images
Status: O

Article 19812 of comp.windows.x:
Path: ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!EXPO.LCS.MIT.EDU!rws
>From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: need help using Xlib to zoom images
Message-ID: <9002282145.AA00738@expire.lcs.mit.edu>
Date: 28 Feb 90 21:45:06 GMT
References: <48965@lll-winken.LLNL.GOV>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 14


    Something is going wrong -> the
    image is appearing at a 90 degree angle from how it should appear,

You are doing

	  pix_value = XGetPixel(orig_image, row, col);

but it's really XGetPixel(ximage, x, y); you have the args reversed.

    plus it's backwards and sometimes extra garbage appears!

You are arbitrarily smashing bitmap_unit and bitmap_pad; that's not
a reasonable thing to do for the source image.


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws Mon Mar  5 17:29:02 PST 1990
Subject: X11R4 public fixes #3 and #4 now available on expo
Status: O

Article 20012 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
>From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: X11R4 public fixes #3 and #4 now available on expo
Message-ID: <9003051703.AA02639@expire.lcs.mit.edu>
Date: 5 Mar 90 17:03:48 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 43

Fixes are available via anonymous ftp to expo.lcs.mit.edu (18.30.0.212), in
the directory /pub/R4/fixes/, in files with prefix "fix-".  "fix-3" and "fix-4"
are now available, "fix-3" and "fix-4".  "fix-4" is really only of interest to
Apollo users.  Fixes get put there in batches at intervals only.  Fixes usually
propagate to other distribution sites as well, so it may pay to check at a
nearer site first.

For those without ftp access, individual fixes can be obtained by mail by
sending a message to xstuff@expo.lcs.mit.edu.  In the usual case, the
message should have a subject line and no body, or a single-line body and
no subject, in either case the line looking like:
	send fixes 2
(to get the second fix).  To get a summary of fixes, make the line:
	index fixes
If you need help, make the line:
	help
Some mailers produce mail headers that are unusable for extracting return
addresses.  If you use such a mailer, you won't get any response.  If you
happen to know an explicit path, you can include a line like
	path foo%bar.bitnet@mitvma.mit.edu
or
	path zot!gzork!me@uunet.uu.net
in the body of your message, and the daemon will use it.

fix-3 fixes the following problems:
	bugs when using XtVaTypedArg
	handling contraint resources in XtVaSetValues
	bug in Xt support for owning multiple selections
	bug in Xt selection support when sending within same client
	missing Xt RectObj exposures in XtSetValues
	XtSetValues loses on XtGeometryAlmost with RectObj children
	memory "leak" from extraneous backing-store getting created
	server randomly dumps core in CopyArea
	memory leak in cfb CopyArea when not using alloca
fix-4 fixes the following Apollo-specific problems:
	correct buggy configuration settings
	remove obsolete comments in README and Xapollo.man
	explain UDS non-support in Xapollo.man
	motion events may be emitted in wrong order
	support 4/5 button mice
	return correct screen size in millimeters
	bugs in GC validation
	bitmap window shapes sometimes don't work


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!kit Tue Mar  6 09:21:59 PST 1990
Subject: Re: carriage_return binding
Status: O

Article 20025 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!kit
>From: kit@EXPO.LCS.MIT.EDU (Chris D. Peterson)
Newsgroups: comp.windows.x
Subject: Re: carriage_return binding
Message-ID: <9003051823.AA22923@expo.lcs.mit.edu>
Date: 5 Mar 90 18:23:20 GMT
References: <9918@pyr.gatech.EDU>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 15


> Few days ago, someone mentioned carriage_return binding to an OK button
> in the dialog box. Could this person or anybody out there drop an example
> on how a carriage_return can be binded to a button.

One example of how to do this is in "examples/Xaw/popup.c" on the R4 core
distribution.

						Chris D. Peterson     
						MIT X Consortium 

Net:	 kit@expo.lcs.mit.edu
Phone:   (617) 253 - 9608	
Address: MIT - Room NE43-213
			


From ucla-cs!usc!samsung!think!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws Tue Mar  6 21:26:30 PST 1990
Subject: X11R4 public fix #5 now available on expo
Status: O

Article 20062 of comp.windows.x:
Path: ucla-cs!usc!samsung!think!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
>From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: X11R4 public fix #5 now available on expo
Message-ID: <9003061908.AA04053@expire.lcs.mit.edu>
Date: 6 Mar 90 19:08:56 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 38

Fixes are available via anonymous ftp to expo.lcs.mit.edu (18.30.0.212), in
the directory /pub/R4/fixes/, in files with prefix "fix-".  The fifth fix, now
available, is "fix-5".  This fix is really only of interest to IBM users.  Fixes
get put on expo in batches at intervals only.  Fixes usually propagate to other
distribution sites as well, so it may pay to check at a nearer site first.

For those without ftp access, individual fixes can be obtained by mail by
sending a message to xstuff@expo.lcs.mit.edu.  In the usual case, the
message should have a subject line and no body, or a single-line body and
no subject, in either case the line looking like:
	send fixes 2
(to get the second fix).  To get a summary of fixes, make the line:
	index fixes
If you need help, make the line:
	help
Some mailers produce mail headers that are unusable for extracting return
addresses.  If you use such a mailer, you won't get any response.  If you
happen to know an explicit path, you can include a line like
	path foo%bar.bitnet@mitvma.mit.edu
or
	path zot!gzork!me@uunet.uu.net
in the body of your message, and the daemon will use it.

Fix-5 fixes the following IBM-specific server problems:

	apa16BBlit.c - Lack of range checking causes server to wedge
	apa16Curs.c - Possible NULL pointer dereference problem
	apa16FlSp.c - Unused routine removed (mfb did proper work)
	apa16GC.c - Remove use of archaic stipple fill code. Also fix for
		wide lines not being drawn. Setting ops for certain glyph blit
		operations correctly.
	apa16IGBlt.c - Inproper clipping and signed/unsigned conflicts caused
		server wedging if viewing glyphs with sidebearings.
	apa16Text.c - Inverted text in a partially obscured window had improper
		bounding box. Also, only use this routine if doing GxCopy.
	mpelData.c - Corrected screen dimensions (pixel/inch calculation)
	mpelPolyPt.c - Incorrect translation code and no check for a
		valid length to megalpel adapter


From ucla-cs!usc!samsung!think!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!jim Tue Mar 13 08:28:56 PST 1990
Subject: X11R4 public fix #6 now available on expo [xterm escape sequence hole]
Status: RO

Article 20348 of comp.windows.x:
Path: ucla-cs!usc!samsung!think!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!jim
>From: jim@EXPO.LCS.MIT.EDU (Jim Fulton)
Newsgroups: comp.windows.x
Subject: X11R4 public fix #6 now available on expo [xterm escape sequence hole]
Message-ID: <9003122054.AA00259@kanga.lcs.mit.edu>
Date: 12 Mar 90 20:54:29 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: X Consortium, MIT Laboratory for Computer Science
Lines: 39


A 3 year old bug in the xterm logging escapes that can lead to security holes
(yet another good reason to use xmh or something like it :-) has been
identified.  A fix may be obtained via anonymous ftp from the machine
expo.lcs.mit.edu (18.30.0.212) in the file "/pub/R4/fixes/fix-6" or from
the xstuff server as follows (for more information, see below):

	% mail xstuff@expo.lcs.mit.edu
	Subject: send fixes 6
	path mymachine!me@uunet.uu.net
	^D

where mymachine!me@uunet.uunet is a path from expo.lcs.mit.edu back to you,
(see below).

				XSTUFF INFO

For those without ftp access, individual fixes can be obtained by mail by
sending a message to the archive server at xstuff@expo.lcs.mit.edu.  The
subject line should read

        send fixes 6

For a list of other fixes, send another message with a subject line of:

	index fixes

Information on other areas that are available from the xstuff server may
be obtained by sending another message with a subject line of:

	help

The xstuff server attempts to extract a return address from your message.  If
you are using a system that does not produce usable headers, you can specify
a particular return path in the body of your message, i.e.:

        path foo%bar.bitnet@mitvma.mit.edu
or
        path zot!gzork!me@uunet.uu.net


From ucla-cs!elroy.jpl.nasa.gov!decwrl!shelby!portia!drapeau@jessica.Stanford.EDU Thu Mar 15 11:14:49 PST 1990
Subject: New Version Of XMusic Now Available
Status: RO

Article 20406 of comp.windows.x:
Path: ucla-cs!elroy.jpl.nasa.gov!decwrl!shelby!portia!drapeau@jessica.Stanford.EDU
>From: drapeau@jessica.Stanford.EDU (George D. Drapeau)
Newsgroups: comp.windows.x
Subject: New Version Of XMusic Now Available
Keywords: music, Csound
Message-ID: <10141@portia.Stanford.EDU>
Date: 14 Mar 90 02:23:36 GMT
Sender: USENET News System <news@portia.stanford.edu>
Reply-To: drapeau@jessica.Stanford.EDU (George D. Drapeau)
Organization: Academic Information Resources, Stanford University
Lines: 28

A "maintenance" version of XMusic is now available for anonymous ftp
from either of these sites

	sioux.stanford.edu (36.83.0.100), /pub/XMusic.tar.Z
	expo.lcs.mit.edu (18.30.0.212), /contrib/XMusic.tar.Z

The new version is hardly different than the last version running
under R3.  Mostly the differences are to accommodate changes in the
Athena Widget Set.

XMusic is a graphical front end to the Csound music compiler (Csound
was written by Barry Vercoe at the MIT Media Lab).  XMusic allows you
to create instruments ("orchestra files", in Csound terms) by
arranging icons in a diagram you create.  XMusic will compile a Csound
orchestra file from your graphical diagram.

XMusic only handles half of Csound compositions; once you have created
the orchestra file, you still much write your own score file to tell
Csound what notes to play on which instruments.  This is likely the
simpler of the two tasks, however.

If you are interested in obtaining Csound, it is available via
anonymous ftp from ems.media.mit.edu (18.85.0.6).

______________________________________________________________________________
George D. Drapeau			Internet: drapeau@jessica.stanford.edu
Academic Information Resources
Stanford University


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!jim Thu Mar 29 11:57:42 PST 1990
Subject: X11R4 public fixes #8 and #9 for twm now available on expo [get both]
Status: RO

Article 20992 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!jim
>From: jim@EXPO.LCS.MIT.EDU (Jim Fulton)
Newsgroups: comp.windows.x
Subject: X11R4 public fixes #8 and #9 for twm now available on expo [get both]
Message-ID: <9003282313.AA24387@kanga.lcs.mit.edu>
Date: 28 Mar 90 23:13:29 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: X Consortium, MIT Laboratory for Computer Science
Lines: 41


Patches for a variety of problems in twm are now available via anonymous ftp
or the xstuff mail archive server on expo.lcs.mit.edu (18.30.0.212).  This is
a 2 volume set: make sure that you get both before trying to rebuild.

The files may be found in ~ftp/pub/R4/fixes/fix-[89] or may be retreived from
xstuff with a command similar to the following:

	%  mail xstuff@expo.lcs.mit.edu
	Subject:  send fixes 8
	path mymachine!me@uunet.uu.net
	^D

	%  mail xstuff@expo.lcs.mit.edu
	Subject:  send fixes 9
	path mymachine!me@uunet.uu.net
	^D


Make sure that you do make clean and make depend before rebuilding....  The
following files are affected:

        fix-8   Imakefile       fix installation problems
        fix-8   add_window.c    NoStackMode, setupframe
        fix-8   events.c        NoStackMode, colormaps, Mod2-5, icons,
ring, configurenotify
        fix-8   events.h        icons
        fix-8   gc.c            saber
        fix-8   gram.y          NoStackMode, Mod2-5
        fix-8   iconmgr.c       icons, saber
        fix-8   icons.c         icons
        fix-9   list.c          saber
        fix-9   menus.c         exec, saber, colors, colormaps, borders
        fix-9   parse.c         NoStackMode, Mod2-5
        fix-9   resize.c        configurenotify, setupframe
        fix-9   resize.h        setupframe
        fix-9   screen.h        NoStackMode
        fix-9   twm.c           NoStackMode, colormaps, events, saber
        fix-9   twm.h           NoStackMode, colormaps, icons
        fix-9   twm.man         NoStackMode
        fix-9   util.c          zoom


From ucla-cs!usc!cs.utexas.edu!uunet!decwrl!wsl.dec.com!klee Thu Mar 29 11:58:12 PST 1990
Subject: Re: Is it possible to create a transparent bit-plane?
Status: RO

Article 20994 of comp.windows.x:
Path: ucla-cs!usc!cs.utexas.edu!uunet!decwrl!wsl.dec.com!klee
>From: klee@wsl.dec.com (Ken Lee)
Newsgroups: comp.windows.x,comp.windows.news
Subject: Re: Is it possible to create a transparent bit-plane?
Keywords: OpenWindows, X, X11R3, transparent, annotation, bit-plane
Message-ID: <3184@bacchus.dec.com>
Date: 29 Mar 90 04:16:01 GMT
References: <1820@ambush.dk>
Sender: news@decwrl.dec.com
Reply-To: klee@decwrl.dec.com
Organization: DEC Western Software Laboratory
Lines: 23
Xref: ucla-cs comp.windows.x:20994 comp.windows.news:2138

In article <1820@ambush.dk>, andrew@ambush.dk (Leif Andrew Rump) writes:
> My dream is that
> I can put an tranparent bit-plane on top of an editor (which of course
> I have source code acces to) so the drawings I generate in the
> annotation editor is stored in this specific bit-plane _but_ shown on
> top of the other bit-plane that may actually be several levels deep (I
> only need one level: black or transparent, 1 and 0 or whatever).

A standard computer graphics technique for doing this is to reserver
one bit from a multi-bit colormap for your overlay annotations.  Allow
your graphics editor to use any of the colors specified by the other
bits.  For example, on an 8 plane machine, make all colors with the
first bit on be black.  Then, write your overlays with a GC foreground
of black and GC function of GXor.  You can retreive/erase/copy/etc. the
underlying graphics and the overlay annotations independently by simply
specifying the proper planes in your GCs.  Any computer graphics text
should have example colormaps for doing this, possibly also examples
with more than 2 independent images.

Ken Lee
DEC Western Software Laboratory, Palo Alto, Calif.
Internet: klee@wsl.dec.com
uucp: uunet!decwrl!klee


From ucla-cs!usc!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse Mon Apr  9 09:52:53 PDT 1990
Subject: Re:  Surface plots in X
Status: RO

Article 21411 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
>From: mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  Surface plots in X
Message-ID: <9004080144.AA28284@Larry.McRCIM.McGill.EDU>
Date: 8 Apr 90 01:44:28 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 16

> Does anyone know of a program that will do surface plots in X?  I
> have data that consists of z values on an evenly spaced XY grid and I
> want a surface plot with hidden line removal.  Axes would be nice as
> well.  I can ftp, so an address to a ftp server would suffice.

It's not quite what you want, but it may be a good starting point, and
it's cheap at half the price :-).  Fetch X/xsurface.c from 132.206.1.1.
You will likely need some local include files and library routines;
fetch X/mterm.src/mterm.aux for those.  Let me know if you need
anything besides what's there (that aux file is designed for a
different program).

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu


From ucla-cs!usc!samsung!uunet!atexnet!cvbnet!caribe.prime.com!aperez Thu Apr 12 19:35:14 PDT 1990
Subject: Long query about color XOR'ing
Status: RO

Article 21568 of comp.windows.x:
Path: ucla-cs!usc!samsung!uunet!atexnet!cvbnet!caribe.prime.com!aperez
>From: aperez@caribe.prime.com (Arturo Perez x6739)
Newsgroups: comp.windows.x
Subject: Long query about color XOR'ing
Message-ID: <192@cvbnetPrime.COM>
Date: 10 Apr 90 17:44:09 GMT
Sender: postnews@cvbnetPrime.COM
Reply-To: aperez@cvbnet.prime.com (Arturo Perez x6739)
Distribution: na
Organization: Prime Computervision, Bedford MA
Lines: 148

I'm working on some code from xtank (to get it to work in color) and I'm
running into something I don't understand.  Could some kind soul out there
explain what's happening?


I'm running the MIT X server, release 4 with patches 1-9 installed on a sun
3/60 whose default visual is PseudoColor.

The xtank game creates scads of GC's, one for every combination color,
operation, and font.  That turns out to be about 100 GC's.  There also seems
to be quite a lot of bitmaps, possibly as many as 350.  That's just for 
background.

There are 2 modes of operation, GXxor and GXcopy.  The GXxor operation is
used for most of the drawing operations involving the bitmaps, in order to
draw, erase, move, draw the bitmaps.  

Originally, the code looked like this:

  for(i = 0 ; i < MAX_COLORS ; i++) {
    for(j = 0 ; j < MAX_DRAW_FUNCS ; j++) {
      switch(j) {
      case DRAW_XOR:
        values.function = GXxor;
        values.background = vid->bg;
        values.foreground = vid->color[i] ^ vid->fg;

And to draw a bitmap, like so:

#define draw_picture(w,x,y,pic,func,_color) \
  { \
    int tmp_x = x - pic->offset_x; \
    int tmp_y = y - pic->offset_y; \
      if(x > -pic->offset_x && tmp_x < vid->win[w].width && \
         y > -pic->offset_y && tmp_y < vid->win[w].height) { \
        if(vid->planes == 1)\
          XCopyArea(vid->dpy,vid->pixid[pic->pixmap],vid->win[w].id, \
                    vid->graph_gc[func][_color],0,0,pic->width,pic->height, \
                    tmp_x,tmp_y); \
        else\
	  XCopyPlane(vid->dpy,vid->pixid[pic->pixmap],vid->win[w].id, \
                     vid->graph_gc[func][_color],0,0,pic->width,pic->height, \
                     tmp_x,tmp_y, 1);\
         }\
 }

And that didn't work.  All I got were white blocks instead of the bitmaps.  Now,
on a PseudoColor screen, this is obviously wrong because we're dealing with
colormap entries, not pixel values.  So, I changed it to this:

  for(i = 0 ; i < MAX_COLORS ; i++) {
    for(j = 0 ; j < MAX_DRAW_FUNCS ; j++) {
      switch(j) {
      case DRAW_XOR:
        values.function = GXxor;
        values.background = vid->bg;
        values.foreground = vid->color[i];

And that didn't work.  The bitmaps came out correctly, but lines and text
did not.  The lines and text didn't come out at all, as a matter of fact. Also,
in mono the bitmaps came out fine, but on a color screen the bitmaps came out
in reverse, i.e. black on white, instead of white on black.

This is background for my first bunch of questions.
	How come lines didn't come out when I`m using the GC for xor? All
	I'm doing is using it in an XDrawLine request.

	Why do the bitmaps come out as black on white on a color screen?

So, next I try:

  for(i = 0 ; i < MAX_COLORS ; i++) {
    for(j = 0 ; j < MAX_DRAW_FUNCS ; j++) {
      switch(j) {
      case DRAW_XOR:
        values.function = GXxor;
        values.background = vid->color[i];
        values.foreground = vid->bg;


And that works perfectly in mono but in color the bitmaps come in in black
with a colored box surrounding them.  Why the difference?  I would have 
thought that if the bitmap looked fine in mono, it should have looked fine in
color as well.

So, then I changed it to:

  for(i = 0 ; i < MAX_COLORS ; i++) {
    for(j = 0 ; j < MAX_DRAW_FUNCS ; j++) {
      switch(j) {
      case DRAW_XOR:
        values.function = GXxor;
        if (vid->color[i] == vid->fg) {
           values.background = vid->fg;
           values.foreground = vid->bg;
        } else {
           values.background = vid->fg;
           values.foreground = vid->color[i];
        }

And this sort of works for both color and black/white.  At least, the bitmaps
come out color on black and white on black.  But, out of the set of colors
Black, White, Red, Orange, Yellow, Green, Blue and Violet on my workstation
(3/60 /dev/cgfour0) the orange comes out as dark blue and the blue and violet
don't come out at all, that is, the bitmaps drawn in those 2 colors are
invisible.  Even worse, on other workstations (even other 3/60) none of the
colors look correct.  Why do the colors look right on my machine but no one
else's?  Why don`t the colors come out right if I XOR them onto black?

I reason, probably incorrectly, that the colors are behaving as if they
were being XOR'ed onto white.  So, I change the draw_picture macro to

#define draw_picture(w,x,y,pic,func,_color) \
  { \
    int tmp_x = x - pic->offset_x; \
    int tmp_y = y - pic->offset_y; \
      if(x > -pic->offset_x && tmp_x < vid->win[w].width && \
         y > -pic->offset_y && tmp_y < vid->win[w].height) { \
        if(vid->planes == 1)\
          XCopyArea(vid->dpy,vid->pixid[pic->pixmap],vid->win[w].id, \
                    vid->graph_gc[func][_color],0,0,pic->width,pic->height, \
                    tmp_x,tmp_y); \
        else\
          switch(func) {\
               case DRAW_XOR : \
                 if (_color != WHITE)\
                   XCopyPlane(vid->dpy,vid->pixid[pic->pixmap],vid->win[w].id,\
                     vid->graph_gc[func][WHITE],0,0,pic->width,pic->height, \
                     tmp_x,tmp_y, 1);\
               case DRAW_COPY : \
                  XCopyPlane(vid->dpy,vid->pixid[pic->pixmap],vid->win[w].id, \
                     vid->graph_gc[func][_color],0,0,pic->width,pic->height, \
                     tmp_x,tmp_y, 1);\
         }\
      } \
   }

And everything looks correct, in both color and mono.  And I've just converted
the program into a real pig because CopyPlane has gotta be one of the most
expensive Xlib calls.

Why doesn't the vanilla XOR work?  Is there a more efficient way to get the
d****d bitmaps up on the screen in the correct color?

Arturo Perez
ComputerVision, a division of Prime
aperez@cvbnet.prime.com
Too much information, like a bullet through my brain -- The Police


From ucla-cs!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!smurf!aspd!anatole Tue Apr 17 18:19:11 PDT 1990
Subject: *** X PUBLICATIONS ***
Status: RO

Article 21682 of comp.windows.x:
Path: ucla-cs!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!smurf!aspd!anatole
>From: anatole@aspd.uucp (anatole olczak)
Newsgroups: comp.windows.x
Subject: *** X PUBLICATIONS ***
Message-ID: <654@aspd.uucp>
Date: 14 Apr 90 13:03:13 GMT
Organization: ASP, Inc
Lines: 109


			X MANUAL SET (VOLUMES 1-3)
			--------------------------

			Volume 1: X User Commands

This volume provides detailed information about using the X Window System.  
It covers the standard clients and contributed software, as well as the 
specification and usage of X resources. All the man pages for the standard
and contributed software, along with the major documents are included.

			Volume 2: X Library Interface

This volume provides the manual pages and reference documentation for C
programming with the X11 Library.  A cross-reference is also included.

			Volume 3: X Intrinsics & Athena Widgets

This volume provides the manual pages and reference documentation for C
programming with the X11 Intrinsics library and Athena Widgets.  A 
cross-reference is also included.

Together, these provide manual pages and major documents from the X11
Window System standard distribution.  All 3 volumes total over 1100 pages.
Available in the US directly from ASP, Inc, or internationally from
Addison-Wesley.  The US price is $49.95 (plus shipping/handling and tax 
if CA resident).


			X REFERENCE SET (LIBRARY/TOOLKIT/USER)
			--------------------------------------
	
			X Library Reference Manual (2nd Ed) ($19.95)

This handbook provides a quick-reference for the use of the X Library.  It
contains sections on X Library Functions, Convenience Functions, Macros,
X10 Compatibility Functions, Constants, and X11 Extension Functions.  A
cross-reference, how-to sections, and sample programs are also included.

			X Toolkit Reference Reference Guide ($17.95)

This handbook provides a quick-reference for the use of the X Toolkit.  It
contains sections on the X Intrinsics Functions, Athena Widgets, Toolkit
Data Structures, Toolkit Sample Initializations, Steps to Creating a New
Widget, and Steps to Writing Toolkit Applications.  A handy cross-reference
is also included.

			X User Reference Guide ($14.95)

This handbook provides a quick-reference for the X Window System user. It
contains sections for each command for the X clients and a majority of the
contributed software (over 120 commands are covered vs 39 for O'Reilly).
Each command lists the name, invocation syntaxes, options, resources, files,
variables, and related commands.  Examples are also included.

Together, these provide a complete reference set for the X Window System.
When purchased together as the X Reference Set, the price is $39.95 (plus
shipping-handling and tax if CA resident)


			ORDERING/MORE INFORMATION
			-------------------------

Shipping-Handling - add $2 for the 1st item, .75 for each add'l.  For the
X Manual Set, add $3 for 1st item, $1 for each add'l.  Call for UPS Next/
2nd Day delivery.  All orders are shipped within 24 hours.  Call/write for
our free catalog.  For more information contact:

ASP, Inc.
PO Box 9249-003N
San Jose CA 95157
e-mail: sun!asp%cup.portal.com

To order call toll-free or fax to:
(800) 777-UNIX
(408) 629-7993
fax: (408) 226-8819

	
			OTHER TITLES
			------------

ASP offers a series of comprehensive reference booklets on a range of UNIX 
and C topics like System V UNIX, Berkeley BSD UNIX, System Administration 
for System V UNIX, UNIX System Programming, Bourne Shell Programming, C Shell
Programming, Korn Shell Programming, C Programming, C++ Programming, Text 
Editing with Vi and Ed, Using the Source Code Control System, and Using Netnews 
with USENET.  These guides are in a handy, portable format and can be 
customized to include a company name and logo. 

ASP UNIX/C reference publications are available at technical bookstores like 
Computer Literacy Bookshops, B Dalton Software/Etc, Stacies, and Stanford 
Bookstore or by mail order (add .75 for each book and Ca sales tax if 
applicable) directly from ASP.


			CUSTOMIZATION/LICENSING SERVICES
			--------------------------------

ASP publications can be customized for training, sales, promotion, or use
as proprietary documentation.  This includes a variety of services from
production of customized versions with a copany name and logo, to complete
source-level changes with proprietary information and formatting changes.
Volume discounts also apply.  Our staff of technical writers and editors
can help you produce original technical documentation, or customize our
publications for your systems.

ASP publications have been licensed by a number of companies, including
Analog Design Tools, Aspen Technologies, Informatix, IXI Ltd, and Unisys.


From ucla-cs!rutgers!usc!snorkelwacker!bloom-beacon!AI.MIT.EDU!cjl Thu Apr 19 09:04:21 PDT 1990
Subject: new version of CLX available
Status: RO

Article 21699 of comp.windows.x:
Path: ucla-cs!rutgers!usc!snorkelwacker!bloom-beacon!AI.MIT.EDU!cjl
>From: cjl@AI.MIT.EDU (Chris Lindblad)
Newsgroups: comp.windows.x
Subject: new version of CLX available
Message-ID: <19900415184835.9.CJL@OTIS.AI.MIT.EDU>
Date: 15 Apr 90 18:48:00 GMT
Sender: tytso@athena.mit.edu (Theodore Y. Ts'o)
Organization: The Internet
Lines: 15

I have put together a new version of CLX.  It's available for ftp from:

	expo.lcs.mit.edu:/contrib/CLX.R4.1.tar.Z

The objective is to fix reported bugs and to include the vendor-specific
bug-fixing and performance-improving patches that I recently received.  There
is no substantial vendor-independent difference in functionality between the
R4 CLX and the R4.1 CLX.  It's just easier for me to distribute patches this
way than the "fixes file" way X server patches are distributed.

Code compiled with the R4 CLX will work with the R4.1X CLX, but code compiled
with the R4.1X CLX will NOT work with the R4 CLX.  I made an effort to ensure
backward binary compatibility with R4 CLX so that old code doesn't have to be
recompiled to still work.  It does have to be recompiled to fix an event-queue
bug, since the fix involved a change to the event-loop macro.


From ucla-cs!usc!zaphod.mps.ohio-state.edu!uwm.edu!rutgers!njin!khnphwzhn.njin.net!rapatel Thu Apr 19 09:06:12 PDT 1990
Subject: twm resize bug w/fix.
Status: RO

Article 21728 of comp.windows.x:
Path: ucla-cs!usc!zaphod.mps.ohio-state.edu!uwm.edu!rutgers!njin!khnphwzhn.njin.net!rapatel
>From: rapatel@khnphwzhn.njin.net ( Rakesh Patel)
Newsgroups: comp.windows.x
Subject: twm resize bug w/fix.
Message-ID: <Apr.16.18.19.14.1990.20330@khnphwzhn.njin.net>
Date: 16 Apr 90 22:19:16 GMT
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 53
Cc: xbugs@expo.lcs.mit.edu


			  X Window System Bug Report
			    xbugs@expo.lcs.mit.edu


VERSION:
    R4

CLIENT MACHINE and OPERATING SYSTEM:
Sun Sparcstation 1 SunOS (any)

DISPLAY TYPE:
bwtwo0 (any)

WINDOW MANAGER:
twm

AREA:
twm

SYNOPSIS:
twm dumps core due to a divide by zero bug during resizing windows.

DESCRIPTION: Clients that claim to set hints for the window manager
but do not can cause twm to dump core. The particular one I found was
with the resize increment values. If a client claims to set the resize
increments but does not, set either or both of them (width_inc and
height_inc), then twm ends up dividing by zero. There may be other
cases in twm where the hints are assumed to be set properly and those
should be checked as well.

REPEAT BY:
Try writing a client that claims to set those hints without actually
doing so - or at least setting them to zero values. Then try to resize
that window.

SAMPLE FIX:

*** resize.c.OLD	Mon Apr 16 14:20:59 1990
--- resize.c	Sat Apr 14 01:25:28 1990
***************
*** 385,390 ****
--- 385,394 ----
  	}
      }
  
+     if ( tmp_win->hints.flags & PResizeInc && 
+ 	(!tmp_win->hints.width_inc || !tmp_win->hints.height_inc) )
+       tmp_win->hints.flags &= ~PResizeInc;
+ 
      if (tmp_win->hints.flags & PResizeInc)
      {
          dwidth /= tmp_win->hints.width_inc;


From ucla-cs!usc!samsung!think!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws Mon Apr 23 16:29:40 PDT 1990
Subject: Re: Patch 10 and 11 Failure
Status: RO

Article 21993 of comp.windows.x:
Path: ucla-cs!usc!samsung!think!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
>From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: Patch 10 and 11 Failure
Message-ID: <9004231236.AA06881@expire.lcs.mit.edu>
Date: 23 Apr 90 12:36:45 GMT
References: <9004222142.AA24764@expo.lcs.mit.edu>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 9

Patch 10/11 affects Xt.  The problem you cite is with the server.
I find it hard to believe the two are related, except that perhaps
make install did something bad.

    Failed to set default font path '/usr/lib/X11/fonts/misc,..'

One of the directories in the default font path has a bad fonts.dir
or fonts.alias file.  Make sure you've run mkfontdir on each
(installed) directory, and checked the fonts.alias file(s).


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!kit Mon Apr 23 22:25:59 PDT 1990
Subject: Re: scrolling Text Widget problems
Status: RO

Article 22015 of comp.windows.x:
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!kit
>From: kit@EXPO.LCS.MIT.EDU (Chris D. Peterson)
Newsgroups: comp.windows.x
Subject: Re: scrolling Text Widget problems
Message-ID: <9004231614.AA25660@expo.lcs.mit.edu>
Date: 23 Apr 90 16:14:46 GMT
References: <19934@shamash.cdc.com>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 33


> I'm working on a client that puts up an Athena Text Widget
> and gets its information from a disk file.  All works fine
> until I try scrolling.  The scrolled text is there, it
> just isn't visible.  If text is selected, the invisible text
> appears during the selection.

> background:  R3 Xt/Xaw   (Is this another "fixed in R4"?)

I can't be of much help on this one, other than to say that I had never heard
of this problem before, and therefore find it hard to believe that the fault
lies in the Text widget.  Although from the description that you have given it
sure sounds like a Text widget problem.  I do not have access to an R3 Athena
widget set, so I can't really help you directly.  If going to R4 is an option 
I would strongly suggest it, for many reasons:

1) Many bug fixes, possibly including this one, I had reworked that code
   a bit from R3 to R4.

2) Better interface, more features, and easier to program.

3) If the problem still persits then I can try to help you.

If that is not an option someone else will have to help you, since I don't have
R3 bits anymore, and have never seen this problem.


						Chris D. Peterson     
						MIT X Consortium 

Net:	 kit@expo.lcs.mit.edu
Phone:   (617) 253 - 9608	
Address: MIT - Room NE43-213


From ucla-cs!elroy.jpl.nasa.gov!lll-winken!bu.edu!ics!xug Mon Apr 30 08:17:50 PDT 1990
Article: 22206 of comp.windows.x
Path: ucla-cs!elroy.jpl.nasa.gov!lll-winken!bu.edu!ics!xug
From: xug@ICS.COM (X User's Group)
Newsgroups: comp.windows.x,ba.windows.x,comp.windows.misc
Subject: Frequently Asked Questions about X with Answers [long monthly posting]
Message-ID: <1990Apr27.204217.5788@ICS.COM>
Date: 27 Apr 90 20:42:17 GMT
Expires: Fri, 01 Jun 90 00:00:00 GMT
Organization: the World
Lines: 1272
Xref: ucla-cs comp.windows.x:22206 comp.windows.misc:1606
Status: RO

[Last changed: 25 Apr 90]

This article contains the answers to some Frequently Asked Questions often seen
in comp.windows.x. It is posted to help reduce volume in this newsgroup and to
provide hard-to-find information of general interest.

This article includes answers to these questions:

0) Where can I obtain X source?
1) Where can I obtain X11R4?
2) Where can I obtain Motif?
3) Where can I obtain software implementing Open Look?
4) Where can I obtain other X sources?
5) What is the xstuff mail-archive?
6) Where can I obtain patches to X11R4?
7) Where can I find books and articles on X that are good for beginners?
8) What courses on X are available?
9) Is there a skeleton X program available?
10) What are these common abbreviations?
11) What is XUG?
12) What is EXUG?
13) What is the X Consortium and how do I join?
14) What conferences on X are coming up?
15) What is the current state of the world in X terminals?
16) How can I get an X server on a PC?
17) How can I get an X server on a Macintosh running MacOS?
18) Where can I obtain an X-based editor or word-processor?
19) Where can I obtain an X-based paint/draw program?
20) Where can I obtain an X-based spreadsheet?
21) Where can I get a PostScript previewer for X?
22) Where can I get a troff previewer for X?
23) How do I convert Mac/TIFF/GIF/Sun/PICT/Face/img/FAX/etc images to X?
24) How do I use an alternate window manager with DEC's session manager?
25) How do I build X with gcc?
26) What are these funny problems compiling X11R3 on the Sun4?
27) What are these funny problems installing X11R4 on the Sun running SunOS 4?
28) Where can I get a fast X server for a workstation?
29) How can I change the titlebar of my xterm window?
30) Why doesn't anything appear when I run this simple program?
31) What is the difference between a Screen and a screen?
32) Why do I get a BadDrawable error drawing to XtWindow(widget)?
33) Can I get a window's background pixel/pixmap using XGetWindowAttributes?
34) Why does the pixmap I copy to the screen show up as garbage? 
35) Why doesn't my program get the keystrokes I select for?
36) How can my application iconify itself?
37) How do I check whether a window ID is valid?
38) Why can't I set the backgroundPixmap resource in my .Xdefaults file?
39) Why does the R3 xterm, et al, fail against the R4 server?
40) Where can I obtain alternate language bindings to Xlib?

If you have suggestions or corrections for any of these answers or any 
additional information, please send them directly to xug@expo.lcs.mit.edu;
the information will be included in the next revision (or possibly the one 
after that; thanks for the many suggestions which haven't been incorporated 
yet).  The answers in this iteration are acknowledged to be partial and to 
lean more towards products than to programming.

This posting is intended to be distributed at approximately the beginning of 
each month; the date of expiration has been fixed up so that this message
should stay around for a bit.

The information contained herein has been gathered from a variety of sources. In
many cases attribution has been lost; if you would like to claim responsibility
for a particular item, please let us know. 

Conventions used below: telephone numbers are Bell-system unless otherwise 
noted; prices on items are generally not included.

--------------------------------------------------
0) Where can I obtain X source?

	Intelligent Software Products, Inc., (516-766-2867) ships X11R3
[formats are unknown]. 

	Integrated Computer Solutions, Inc., (617-547-0510) ships X11R3 on 
half-inch and quarter-inch formats. 

	The Free Software Foundation (617-876-3296) sells X11R3 on half-inch 
tapes and on QIC-24 cartridges.  

	Automata Design Associates (215-646-4894) sells X11R3 source on 5.25" 
high-density floppies and QIC-24 quarter-inch cartridge tapes. 

	European sites can obtain a free distribution from Jamie Watson, who 
may be reached at chx400!pan!jw or cernvax!pan!jw. [1/90]

	IXI Limited (+44 223 462 131) is selling X11R3 source on quarter-inch 
cartridge formats and on 5.25" and 3.5" floppy, with other formats available on
request. [IXI, 2/90]

[Note that some distributions are media-only and do not include docs.]
[The MIT Software Center no longer distributes X11R3.]
	(See below for FTP sites.)

1) Where can I obtain X11R4?

	The MIT Software Center is shipping X11R4 on four 1600bpi half-inch 
tapes. Call the X Hotline at (617) 258-8330 for prerecorded ordering 
information and a good product description.

	Integrated Computer Solutions, Inc., ships X11R4 on half-inch, 
quarter-inch, and TK50 formats. Call 617-547-0510 for ordering information.

	The Free Software Foundation (617-876-3296) sells X11R4 on half-inch 
tapes and on QIC-24 cartridges.  

	Yaser Doleh (doleh@math-cs.kent.EDU; P.O. Box 1301, Kent, OH 44240) is
making X11R4 available on HP format tapes, 16 track, and Sun cartridges. [2/90]

	European sites can obtain a free X11R4 distribution from Jamie Watson,
who may be reached at chx400!pan!jw or cernvax!pan!jw. [1/90]

	IXI Limited (+44 223 462 131) is selling X11R4 source on quarter-inch 
cartridge formats and on 5.25" and 3.5" floppy, with other formats available on
request. [IXI, 2/90]

	Virtual Technologies (703-430-9247) provides the entire X11R4 
compressed source release on a single QIC-24 quarter-inch cartridge and also on
1.2meg or 1.44 meg floppies upon request. [Conor Cahill (cpcahil@virtech.uu.net)
2/90]

[Note that some distributions are media-only and do not include docs.]

	Canadian sites can send email to xhacks@csri.toronto.edu to arrange for
the exchange of tapes; the offer is subject to "time availability".
[information from Mark Moraes (moraes@csri.toronto.edu), 2/90]

	UK sites can obtain R4 through the UKUUG Software Distribution Service,
from the Department of Computing, Imperial College, London, in several tape 
formats.  You may also obtain the source via Janet (and therefore PSS) using 
Niftp (Host: uk.ac.ic.doc.src Name: guest Password: your_email_address). 
Queries should be directed to Lee McLoughlin, 01-589-5111#5037, or to 
ukuug-soft@uk.ac.ic.doc.

	X11R4 is ftp-able from expo.lcs.mit.edu; these sites are preferable, 
though, and are more direct:

                        Machine                  Internet      FTP
    Location            Name                     Address       Directory
    --------            -------                  --------      -------------
(1) West USA            gatekeeper.dec.com       16.1.0.2      pub/X11/R4
    Central USA         mordred.cs.purdue.edu    128.10.2.2    pub/X11/R4
(2) Central USA         giza.cis.ohio-state.edu  128.146.8.61  pub/X.V11R4
    Southeast USA       uunet.uu.net             192.48.96.2   X/R4
(3) Northeast USA       crl.dec.com              192.58.206.2  pub/X11/R4
(4) UK Janet            src.doc.ic.ac.uk         129.31.81.36  X.V11R4
    UK niftp            uk.ac.ic.doc.src                       <XV11R4>
(5) Australia           munnari.oz.au            128.250.1.21  X.V11/R4

The giza.cis.ohio-state.edu site, in particular, is known to have much of the
contrib stuff that can be found on expo. In addition, the same stuff is also 
available via anonymous UUCP from osu-cis, at TB+ and V.32 speeds.  
Write to uucp@cis.ohio-state.edu (same as osu-cis!uucp) for instructions. 
[thanks to Bob Sutterfield, bob@MorningStar.Com, 2/90]

The release is available to DEC Easynet sites as CRL::"/pub/X11/R4".

[additional information to be filled in as received]

--------------------------------------------------
2) Where can I obtain Motif?
	
	Various hardware vendors produce developer's toolkits of binaries, 
header files, and documentation; check your hardware vendor, particularly if
that vendor is an OSF member. Systems known to be shipping now: HP (sans UIL), 
Apollo (sans UIL), SCO, ISC, Mips (RISCwindows=X11R3 + full Motif).  
In addition, independent binary vendors produce Motif toolkits. ICS makes 
several binary kits, notably for Sun, Apple; Quest (408-988-8880) sells kits for
Suns, as well.

	An OSF/Motif source license must be obtained from OSF before source can
be obtained from the Open Software Foundation or any value-added vendor. Call 
the Motif Desk at OSF at 617-621-8835 for ordering information.

--------------------------------------------------
3) Where can I obtain software implementing Open Look?

	Sun's XView has a SunView-style API. A new version is on the X11R4 
tape; a newer version is also available (as of 2/90) on expo.lcs.mit.edu 
for anonymous ftp.

	AT&T's Open Look GUI 2.0 Xt-based toolkit is now generally available 
[2/90]; contact 1-800-828-UNIX#544 for information.

	Sun is shipping OpenWindows 1.0 for Sparc, Sun-3, and Sun386i machines;
contact your local sales representative for more details.

	Solbourne's extensible C++-based Object Interface Library will be 
distributed by AT&T [date of availability appx. 6/90].

--------------------------------------------------
4) Where can I obtain other X sources?

	User-contributed software is distributed through the newsgroup
comp.sources.x, moderated by Dan Heller (argv@sun.com); also check that group 
for posting information.


	[Information expected about the Free Widget Library is about to make 
the following on PDWL out-of-date. In the mean-time ... ]
	Miles O'Neal of Sales Technologies, Inc., started a Public Domain 
Widget Library in 11/88. The PDWL is a repository of widgets donated for the 
use of other X programmers and also of toolkit documentation, widget-writing
documentation, better documentation for extant widgets and toolkits, and 
widget-writing tools.
	In addition, the PDWL also stores information on commercially available
toolkits and other sites from which public-domain widget-related and X-related 
stuff may be obtained. It is a place for non-commercial stuff not readily 
available elsewhere.
	You can access the PDWL by sending electronic mail to the account
gatech!stiatl!xwidgets. Send a Subject line of 'help' to obtain more 
information on retrieving widgets and on submitting sources.


	The machine expo.lcs.mit.edu has a great deal of user-contributed
software in the contrib/ directory; a good deal of it is present in current or 
earlier versions on the X11R3 and X11R4 contrib tapes. There is a new directory
contrib/R4fixes/ for fixes to R4 contrib software. [Jim Fulton, 2/90]


	A new west-coast UUCP X11 Archive is administered by Mark Snitily 
(mark@zok.uucp) and contains the full X11R4 distribution, the XTEST
distribution, an entire archive of comp.sources.x and other goodies.
	The machine zok has a TB+ modem which will connect to 19.2K, 2400, 
1200 baud (in that order).  The anonymous UUCP account is UXarch with password 
Xgoodies.  The modem's phone number is 408-996-8285.
	A sample Systems (or L.sys) entry might be:
   		zok Any ACU 19200 4089968285 in:--in: UXarch word: Xgoodies
	To get a current listing of the files that are available, download
the file "/usrX/ls-lR.Z".
	A full subject index of the comp.sources.x files is available in the
file "/usrX/comp.sources.x/INDEX".
	The machine has just the one modem, so please do not fetch large 
amounts of data at one sitting.
[courtesy Mark Snitily, 2/90]


	FTP sites and software available (list as of X11R3; also see above):
brazos.rice.edu            128.42.42.2    pub/X11R3/core.src
charon.mit.edu             18.80.0.13     perl+patches, xdvi
cs.purdue.edu              128.10.2.1     rcs,xspeed
j.cc.purdue.edu            128.210.0.3    comp.sources.{unix,x,amiga}, elm, uupc
nl.cs.cmu.edu              128.2.222.56   Fuzzy Pixmap 0.84 in /usr/mlm/ftp
shambhala.berkeley.edu     128.32.132.54  xrn
terminator.cc.umich.edu    35.1.33.8      xscheme, msdos, atari
cayuga.cs.rochester.edu    192.5.53.209   Xfig,LaTeX styles,Jove
cfdl.larc.nasa.gov         128.155.24.55  gnu, rfc, sun, X, ucb, odu, vm
cheddar.cs.wisc.edu        128.105.2.113  Common Lisp stuff, X11 courier fonts
cs.orst.edu                128.193.32.1   Xlisp
dinorah.wustl.edu          128.252.118.101 X11R3/core.src 
expo.lcs.mit.edu           18.30.0.212    a home of X, portable bitmaps
gatekeeper.dec.com         128.45.9.52    X11,etc...
giza.cis.ohio-state.edu    128.146.8.61   X11R3, PEX
hotel.cis.ksu.edu          129.130.10.12  XBBS, msdos, U3G toolkit
icarus.riacs.edu           128.102.64.1   SLIP, chkpt, macdump, Xpostit
interviews.stanford.edu    36.22.0.175    InterViews X toolkit
jpl-mil.jpl.nasa.gov       128.149.1.101  Tex, Mac, Gnu, Xv11R{2,3}
m9-520-1.mit.edu           18.80.0.45     Xim (X image viewer)
mordred.cs.purdue.edu      128.10.2.2     X11R3
polyslo.calpoly.edu        129.65.17.1    src/spaceout.tar.Z for X11
scam.berkeley.edu          128.32.138.1   X sources, etc.
sun.soe.clarkson.edu       128.153.12.3   X11 fonts, TeX
think.com                  10.4.0.6       X11.2 Interviews 3d
vaxa.isi.edu               128.9.0.33     X, db
wheaties.ai.mit.edu        128.52.32.13   "tX11" 
xanth.cs.odu.edu           128.82.8.1     comp.srcs.{x,unix,misc,games,amiga},X
[This is from a file posted in early July 1989 and is attributable to Edward
Vielmetti (emv@math.lsa.umich.edu) and Jon Granrose (odin@pilot.njin.net).
This list does need updating.]


In addition, UUNET Source Archives (703-876-5050) tracks comp.sources.x and 
provides 600MB+ of compressed programs on two 6250 bpi or five 1/4" tapes. 
	
--------------------------------------------------
5) What is the xstuff mail-archive?

	The xstuff server is a mail-response program. That means that you mail 
it a request, and it mails back the response.
	Any of the four possible commands must be the first word on a line. The 
xstuff server reads your entire message before it does anything, so you can 
have several different commands in a single message (unless you ask for help). 
The xstuff server treats the "Subject:" header line just like any other line 
of the message.
	The archives are organized into a series of directories and 
subdirectories.  Each directory has an index, and each subdirectory has an 
index. The top-level index gives you an overview of what is in the 
subdirectories, and the index for each subdirectory tells you what is in it.

	1) The command "help" or "send help" causes the server to send you a 
more detailed version of this help file.
	2) if your message contains a line whose first word is "index", then 
the server will send you the top-level index of the contents of the archive. If
there are other words on that line that match the name of subdirectories, then 
the indexes for those subdirectories are sent instead of the top-level index. 
For example, you can say "send index fixes" (or "index fixes"). A message that 
requests an index cannot request data.
	3) if your message contains a line whose first word is "send", then the
xstuff server will send you the item(s) named on the rest of the line. To name 
an item, you give its directory and its name. For example
                send fixes 1 3 4
	You may issue multiple send requests. The xstuff server contains many 
safeguards to ensure that it is not monopolized by people asking for large 
amounts of data. The mailer is set up so that it will send no more than a fixed 
amount of data each day. If the work queue contains more requests than the 
day's quota, then the unsent files will not be processed until the next day. 
Whenever the mailer is run to send its day's quota, it sends the requests out 
shortest-first.
	4) Some mailers produce mail headers that are unusable for extracting 
return addresses.  If you use such a mailer, you won't get any response.  If 
you happen to know an explicit path, you can include a line like
        path foo%bar.bitnet@mitvma.mit.edu
or
        path bar!foo!frotz
in the body of your message, and the daemon will use it.

	The xstuff server itself can be reached at xstuff@expo.lcs.mit.edu. If 
your mailer deals in "!" notation, try sending to 
{someplace}!eddie!expo.lcs.mit.edu!xstuff.

[based on information from the MIT X Consortium, 8/89.]

--------------------------------------------------
6) Where can I obtain patches to X11R4?

	The xstuff server now has eleven patches for X11R4 [4/90]. Send to 
xstuff@expo.lcs.mit.edu the Subject line
		send fixes #
where # are numbers in the range of 1 to 11 (e.g. `send fixes 1 3 5 7 8 10`).

	Patches are typically also distributed through the newsgroup 
comp.sources.x, with some lagtime.

	Some source re-sellers may be including patches in their source 
distributions of X11R4.

--------------------------------------------------
7) Where can I find books and articles on X that are good for beginners?

	Ken Lee of the DEC Western Software Laboratory (klee@wsl.dec.com) 
regularly posts to comp.windows.x and ba.windows.x a list of reference books 
and articles on X and X programming.  Here is an unordered set of useful 
reference books and tutorials, most of which appear on that list [comments are 
gathered from a variety of places and are unattributable]:

Jones, Oliver, "Introduction to the X Window System," Prentice Hall, 1989. A 
fine introduction to programming with Xlib; fairly good background to the X 
protocol; nice discussion of Xlib, the X library. ISBN 0-13-499997-5. (There 
is a new version. ISBN?)
 
Young, Doug. "The X Window System: Applications and Programming with Xt (Motif 
Version)," Prentice Hall, 1989 (ISBN 0-13-497074-8). The excellent tutorial 
"X Window Systems Programming and Applications with Xt," (ISBN 0-13-972167-3) 
updated for Motif. [The examples from the Motif version are available on expo 
in ~ftp/contrib/young.motif.tar.Z]
 
Scheifler, Robert, James Gettys, and Ron Newman, "X Window System: C Library 
and Protocol Reference," Digital Press, 1988. The bible on X.  This is the most
complete published description of the X programming interface and X protocol. 
It should not be one's first book on X, though. ISBN 1-55558-012-2.  DP order 
number EY-6737E-DP.  
 	
Nye, Adrian, "Xlib Programming Manual, Volume 1" and "Xlib Reference Manual, 
Volume 2," O'Reilly and Associates, 1988. A superset of the MIT X documentation;
the first volume is a tutorial with broad coverage of Xlib, and the second
contains reference pages for Xlib functions and many useful reference 
appendices.  ISBN 0-937175-26-9 (volume 1) and ISBN 0-937175-27-7 (volume 2).
[A version updated for X11R4 will be available in April.]

Nye, Adrian, and Tim O'Reilly, "X Toolkit Programming Manual, Volume 4,"
O'Reilly and Associates, 1989. The folks at O'Reilly give their comprehensive
treatment to programming with the MIT X11R3 Intrinsics; some information on 
X11R4 is included.

O'Reilly, Tim, ed.,  "X Toolkit Reference Manual, Volume 5," O'Reilly and 
Associates, 1989.  A professional reference manual for the MIT X11R3 Xt; some 
information on X11R4 is included.

Rosenthal, David S.H., "Inter-Client Communication Conventions Manual Version 
1.0 (MIT Consortium Standard)." The first real ICCCM, available on the R4 tape;
a version is also available from the xstuff mail-archive-server.

(Prentice-Hall ordering is 201-767-5937. O'Reilly ordering is 800-338-NUTS.)

In addition, check the X11R4 core distribution in doc/tutorials for some useful
papers and tutorials, particularly the file doc/tutorials/answers.txt.  "Late 
Night's Top Ten X11 Questions" by Dave Lemke (lemke@ncd.com) and Stuart Marks 
(smarks@sun.com) answers other common questions and some of these here in more 
detail.

--------------------------------------------------
8) What courses on X are available?

	Lurnix offers 4-day "type-along courses" on Xt; the course is being
ported from Xaw to Xm. Information is available at 800-433-9337 (in CA: -9338).
	
	Integrated Computer Solutions, Inc., offers several multi-day, hands-on
courses on X, Xt, and the Xaw, HP, and Motif widget sets, in particular. 
Information is available at 617-547-0510 and info@ics.com.

	Intelligent Visual Computing teaches several Xt-based lab courses 
on-site. IVC is at 919-481-1353 or at info@ivc.uu.net.

	IXI Limited (+44 223 462 131) offers regular X training courses for 
both programmers and non-technical managers.

	Advanced Computing Environments periodically offers at least a two-day
Introduction course. Contact Susie Karlson at 415-941-3399 for information.

	Communica Software Consultants offers three-day hands-on courses in X 
designed for the X Window system developer and programmer. Contact Nicholas
Davias, telephone (08) 232 2626, e-mail nick@manic.communica.oz. [4/90]

	Various vendors are also beginning to offer X training, usually 
specific to Xt and a proprietary widget set; HP and DEC are also offering Xlib 
courses. Sun offers an XView course.

	Various universities are offering short X courses or overviews: UCLA,
Dartmouth, University of Lowell, University of Canberra (within Australia: 
062-522422) ...

	Among the best places to find courses are at the various Unix 
conferences -- Uniforum, Usenix, Unix Expo, Xhibition, the MIT X Technical
Conference, &c.

[additional information to be filled in as received]

--------------------------------------------------
9) Is there a skeleton X program available?
	
	There is no general framework such as the TransSkel program for the 
Macintosh which handles lots of the odds and ends and overhead of development 
under a window system and which can be used as a platform for additional 
development. In X, the problem is typically solved by using an interactive 
application builder tool or by using cut&paste on existing X applications. Good
applications which you might look to manipulate when you want to "test just 
this one little thing" include contrib/clients/xskel, a simple R4 program that 
puts up a window and allows sketching in it and offers a starting point for
quick hacks, the Xaw examples in the examples/ directory in the R3 and R4 
distributions, and the Xlib "Hello World" example in the R3 doc/HelloWorld and 
R4 doc/tutorials/HelloWorld; an updated version of this program which uses R4 
Xlib calls and current ICCCM conventions was posted in 2/90 to comp.windows.x  
by Glenn Widener of Tektronix. 	[3/90]

--------------------------------------------------
10) What are these common abbreviations?

	Xt: The X Toolkit Intrinsics is a library layered on Xlib which 
provides the functionality from which the widget sets are built. An "Xt-based" 
program is an application which uses one of those widget sets and which uses 
Intrinsics mechanisms to manipulate the widgets.
	Xmu: The Xmu library is a collection of Miscellaneous Utility functions
useful in building various applications and widgets.
	Xaw: The Athena Widget Set is the MIT-implemented sample widget set
distributed with X11 source since X11R2.
	Xm: The OSF/Motif widget set from the Open Software Foundation; binary
kits are available from many hardware vendors
	XUI: DEC's X-programmer's toolkit, including a widget set and a high-
level widget description language, is being phased out.
	Xhp (Xw): The Hewlett-Packard Widget Set was originally based on R2++, 
but several sets of patches exist which bring it up to R3, as it is distributed
on the X11R4 tapes.
	dxwm: The DECwindows window manager is part of DEC's current X release.
	mwm: The Motif Window Manager is distributed with OSF/Motif source and
is available from vendors in binary form.
	CLX: The Common Lisp X Interface is a Common Lisp equivalent to Xlib.
	XDMCP: The X Display Manager Protocol provides a uniform mechanism for 
a display such as an X terminal to request login service from a remote host.
	XLFD: The X Logical Font Description Conventions describes a standard
logical font description and conventions to be used by clients so that they
can query and access those resources.
	ICCCM: The Inter-Client Communication Conventions Manual explains the
set of standard conventions which X clients should follow to allow them to
cooperate in the areas of selections, cut buffers, window management, session
management, and resources. The latest version is on the X11R4 tape.
	RTFM: Common expert-speak meaning "please locate and consult the 
relevant documentation -- Read the Manual"
	UTSL: A common expression meaning "take advantage of the fact that you 
aren't limited by a binary license -- Use The Source, Luke".

--------------------------------------------------
11) What is XUG?

	The X User's Group was formed in January of 1988.  Its purpose is to 
encourage X development by providing information on the X Window System to all 
who are interested.

	- Local Area Groups: [this list is in the process of being updated]:
		Bay Area 		Jim Turner, 415/960-0123
		Boston 			Mitch Trachtenberg, 617/621-8700
		Cleveland 		Mike Kolberg, 216/243-1198
		New York City 		#TBC#
		Princeton, NJ 		Joe Camaratta, 609/734-6500
		Research Triangle Park 	Steven Thiedke, 919/481-1353
		Washington, DC 		Thomas Fagre, 703/866-7425
		England 		Ray Anderson, +44 223 462131
		France 			Daniel Dardailler, +33 93 65 77 71
		Singapore		Chee Keong Law, 772-3116

	- XNextEvent: the several-times-yearly newsletter includes articles of 
general interest.

	To join, form a local group, contribute to XNextEvent, or help out in 
any other way, contact Alex Fisher at XUG, c/o Integrated Computer Solutions, 
163 Harvard Street, Cambridge, MA  02139, 617/547-0634, or email to 
xug@expo.lcs.mit.edu (please make sure to include a return address, particularly
if you connect to the world via a UUCP connection). Note that this address is
not a mail server. [Note also that XUG does not currently send this list via
email to a mailing list, though individual requests will be answered.]

--------------------------------------------------
12) What is EXUG?

The European X User Group was formed in 1989 to represent X users in Europe.  
It holds technical conferences at regular intervals, the next one being a one- 
day conference in Cambridge, England on the 4th of May 1990.  A further three- 
day conference is planned for the end of September.

The EXUG also publishes a regular newsletter which is distributed free of 
charge to members.  The EXUG also runs a email mailing list for members which 
is frequently used to address issues of European interest in X.

The EXUG can be contacted by email at: exug@unipalm.uucp or by snail mail at:   
The EXUG, Mitchell House, 185 High Street, Cottenham, Cambridge CB4 4RX, 
England; phone +44 954 211860.

[from Bevis King (brwk@doc.ic.ac.uk), 4/90]

--------------------------------------------------
13) What is the X Consortium and how do I join?

	The MIT X Consortium was formed in January of 1988 to further the
development of the X Window System and has as its major goal the promotion of 
cooperation within the computer industry in the creation of standard software 
interfaces at all layers in the X Window System environment.
	MIT's role is to provide the vendor-neutral architectural and 
administrative leadership required to make this work. Membership in the 
Consortium open to any organization.  There are two categories of membership, 
Member (for large organizations) and Affiliate (for smaller organizations).
	Most of the Consortium's activities take place via electronic mail, 
with meetings when required.  As designs and specifications take shape,
interest groups are formed from experts in the participating organizations.  
Typically a small multi-organization architecture team leads the design, with 
others acting as close observers and reviewers.  Once a complete specification
is produced, it may be submitted for formal technical review by the Consortium
as a proposed standard.  The standards process typically includes public 
review (outside the Consortium) and a demonstration of proof of concept.
	Your involvment in the public review process or as a Member or 
Affiliate of the Consortium is welcomed.
	Write to: Bob Scheifler, MIT X Consortium, Laboratory for Computer 
Science, 545 Technology Square, Cambridge, MA 02139.

[For complete information see the XCONSORTIUM man page from the X11R4
distribution, from which this information is adapted.] [2/90]

--------------------------------------------------
14) What conferences on X are coming up?

	The Xhibition90 X trade show and conference is being held in San Jose 
May 21-25. Xhibition is focused on the X Window System and offers tutorials, 
panels, presentations, and vendor exhibits. Call Xhibition at 617-547-0510 for 
information.

	The MIT Technical Conference is typically held in January in Boston,
mostly for historical reasons.

	Other trade shows -- UnixExpo, Uniforum, Siggraph -- show an increasing
presence of X.

--------------------------------------------------
15) What is the current state of the world in X terminals?

	Here is a selection of vendors with "impressions of consensus opinions".

	Acer (408-922-0333) has the Xebra 1000, based on an 8086 cpu, with a
640x480 monochrome screen. "Low performance." "May not be sold anymore."

	AT&T's (800-247-1212; ask for local dealer) 730X has a 1Kx1K b/w
display with a 1:1 aspect ratio. The terminal supports multiple Telnet sessions
and AT&T windowing in addition to X. [Starlan only.] "Very, very nice."

	C. Itoh (714-660-1421; also 800-347-2484) produces the CIT-X Network 
Display Station based on a 12.5MHZ 68301 main processor with a 34010 graphics 
processor. "Rumor: making a terminal that Sun will OEM, if C. Itoh doesn't pull
out of the business first."

	DEC (800-343-4040) is slated to ship in 3/90 the VT1000, a home-brew
15" 1024x864 monochrome terminal using the TI 34010. "Digital has it now?"

	Gipsi S.A. (+33 (1) 30.60.75.00 or Jeff Abramatic at jfa@gipsi.fr) in 
10/89 announced "le tX", a line of 68030-based X terminals running X11R3. 
High-end models, at least, feature downloadable X servers.
	 Model Memory Resolution   Display Refresh (Hz)  Price (FF)
	   M    2 MB  1280x960x1  19" B&W       66        32 400
	   Me   2 MB  1280x960x2  19" Greyscale 66        38 000
	   C4   2 MB  1280x768x4  16" Colour    60        59 900
	   C8   4 MB  1280x1024x8 19" Colour    60        79 400
		Expansion is up to 8MB and 8 planes.
The exclusive US distributor is Peripheral Design, Inc (404-263-0067).
"Looks fairly nice; shouldn't be overlooked."

	GraphOn (800-472-7466) OptimaX 200 runs a server on the host which 
translates from X protocol to a proprietary protocol which can run over a 
serial line. The screen is 14". The terminal is based on a 12MHz 68000.  (See 
the December 1989 issue of XNextEvent for an informal review.) "Best available
solution for RS232C lines."

	HP (800-752-0900; ask for nearest sales office) offers the 700/X series
of terminals using on the TI 34010. Bit-mapped graphics monitors with 
resolutions of 640x480, 800x600, and 1024x768 are supported.  All units come 
standard with 1 Mbyte of RAM expandable up to 4 Mbytes and display 16 colors 
from a palette of 4096 or up to 16 levels of gray-scale.

	Human Design Systems (800-437-1551) offers several combinations of 14",
16", and 19" color, grey-scale, and mono screens, at least 1Kx1K. All support 
thin and thick Ethernet. High-end models are expandable to 8.5MB. "Slow."

	IBM's Xstation 120 starts with 512KB of memory and features support
for simultaneous Token-Ring and Ethernet connections. [2/90] AGE (619-565-7373)
has software that allows it to work with Suns, RTs, and DECstations as well as 
the IBM Powerstation machines.

	Jupiter Systems (415-523-9000, 508-836-4400) produces the Model 310
which features a 19-inch 1280x1024 color monitor. "A price leader, but also a 
performance leader."

	Network Computing Devices (415-694-0650) offers several terminals. The 
NCD16 has a 1Kx1K 16" square display, a 12.5MHz 68000, a non-optical mouse, a 
DEC-influenced keyboard, and an X11R3 server.  The base configuration comes 
with 1.5M memory. There is an option for down-loading the server into RAM.
(This is the terminal offered by MIPS and DG; it is also the Tektronix XN5.) 
There is also a 19" version with 1280x1024 resolution. The new 17c is an 8-bit 
color 1024x768 display. "Nice engineers' terminals."

	NCR (513-445-2033) offers the Towerview with 1024x840 resolution and a 
PROM-based server. The Towerview supports serial connections. Fonts are
down-loaded. The XL15 and XL19 have 15", 1024x800 and 19", 1280x1024 displays,
respecitively. "Seems to be designed for the PC office."

	Princeton Graphic Systems (800-221-1490) has introduced the Ultra X line
with monochrome up to 1024x768 and color up to 1024x1280. Expandable to 8MB.

	Qume (408-942-4000) has announced an X terminal called the QXT 10 X.

	Spectragraphics (619-450-0611) offers an X terminal with emulation for
the IBM 3270 and related terminals.

	Tektronix (203-877-1494; or Rick Kamp rickka@orca.WV.tek.com) offers 
the Model 4211 Graphics Netstation using the TI 34010 graphics processor. The 
15" screen is 1024x768 color. The XN11 is a PseudoColor device with up to 8 
planes. The 16" and 19" monitors have the 1024x768 resolution. There is also an
XN10, which features a 19", 1024x768 color monitor.

	Visual Technologies (800-VISUALC; MA 508-836-4400) offers the 640X 
based on a 12MHz 68000. The display is 1024x800 14" monochrome. The 719 
increases speed to 16Mhz and offers a 19" display. The 719x Turbo offers grey-
scale images. "Good low-cost-per-seat performance station."

Digital Review's 2/26/90 issue evaluates a subset of these terminals. 
Corrections are in the 3/5 issue, p.4. A rebuttal from Jupiter appears 3/19. 

Digital News' 4/16/90 evaluates a subset of these terminals.

--------------------------------------------------
16) How can I get an X server on a PC?

	Locus Computing (800-955-6287; CA: 213-670-6500; UK: +44 296 89911) has 
a server called PC-Xsight which also appears in Acer's X terminal.

	HP (800-752-0900) has the "HP Accelerated X Window Display Server"
(HP AXDS/PC; HP part D2300B) which will run on any AT-class DOS machine with 
640KB, MSDOS 3.1 or higher, and the HP Intelligent Graphics Controller 10 card,
to which the X11R3-based server is downloaded (avoiding performance-limitations
from PC RAM-size and processor speed). [from John Kempff (kempff@hppad.hp.com),
3/90]

	Graphic Software Systems (GSS) (503-641-2200) makes PC-Xview, an 
MSDOS-based X server which interfaces with PC/TCP Plus networking software from
FTP Software and Excelan's LAN WorkPlace for DOS.  The server works with 
(a) 286, 386, 486 (b) EGA, VGA, DGIS displays. (c) DOS 3.2 and above
(d) Microsoft, Logitech, Mouse Systems Mice (e) 640k memory up to 16 MB memory
[the PC-Xview/16 is available for PCs with extended memory].

	VisionWare's XVision is a Microsoft Windows-based X server which allows
an IBM-compatible PC or PS/2 to display X clients running on a networked 
computer at the same time as local DOS programs. VisionWare is at 612-377-3627 
or vision@vware.mn.org (UK: +44 532 788858 and vware@vision.uucp).
	
	Integrated Inference Machines (714-978-6201 or -6776) is shipping 
X11/AT, an X server that runs under MS-windows. The server converts an IBM-AT 
into an X terminal which can simultaneously run MS-DOS and Microsoft Windows 
applications.

	IBM is rumored to offer a product; part #5709-029.

	Hummingbird Communications (Canada 416-470-1203) produces the 
HCL-eXceed and HCL-eXceed Plus for EGA, VGA, and VGA+ controllers. 

	Information Network Solutions also offers a product called HCL-eXceed
for the *86. The fax is 02-4122079 inside Australia, 612-4122079 from overseas.

	PC DECwindows a.k.a. the PC DECwindows Display Facility is an MS-DOS 
application that turns your PC into an X11R3 terminal. It supports DECnet.
Available from DEC. [Dennis Giokas (giokas@mosaic.enet.dec.com), 3/90]

	AGE (619-565-7373) offers the XoftWare TIGA.

	Bell Technologies (Fremont, CA: 415-659-9097)

	Intelligent Decisions, Inc. (Sunnyvale, CA: 408-734-3730)

--------------------------------------------------
17) How can I get an X server on a Macintosh running MacOS?

	eXodus from White Pine Software (603-886-9050) runs on any Mac with
at least 1MB of memory and runs the X server within a standard Macintosh 
window.  eXodus II uses the math co-processor and other features of high-end
Macs. [info current as of 6/89]

	Apple's MacX runs on MacPlus or newer machines with >= 2MB of memory
and system software 6.0.4 or later. It is an "X11R3.5" server that includes 
support for an optional built-in ICCCM-compliant window manager, X11R4 fonts 
and colors, a built-in BDF font compiler, and built-in standard colormaps, and 
it supports the X11R4 notion "all visuals that make sense" for color displays. 
Available 1Q90. [courtesy Alan Mimms (alan@apple.com], 3/90]

--------------------------------------------------
18) Where can I obtain an X-based editor or word-processor?

	You can ftp the latest version of emacs, including X11 support, from
prep.ai.mit.edu [18.71.0.38].  The file you probably want is
~ftp/pub/gnu/emacs-18.55.tar.Z, or similarly-named files. 
	
	Epoch is a modified version of Gnu Emacs with additional facilities
useful in an X environment. Epoch is available by anonymous ftp from 
cs.uiuc.edu (128.174.252.1), in the directory pub/epoch-files.  There are two 
subdirectories:  epoch contains the epoch source, and gwm contains the source 
to the programmable window manager GWM, with which epoch works well.

	The Andrew system on the X11R4 tape has been described as one of the
best word-processing packages available. It supports word processing with 
multi-media embedded objects: rasters, tables/spread sheets, drawings, style 
editor, application builder, embedded programming language, &c. 
[Fred Hansen (wjh+@ANDREW.CMU.EDU)]

In addition:

	FrameMaker and FrameWriter are available as X-based binary products for
several machines. Frame is at 800-843-7263 (CA: 408-433-3311).

	InDepthEdit is available from Non Standard Logics (+33 (1) 43 36 77 50).

	DECwrite is available from DEC for some DEC hardware and SunWrite is
available from Sun.

	IslandWrite will soon be available from Island Graphics (415-491-1000) 
for some HP & Apollo platforms.

	Interleaf is currently available from Interleaf (800-241-7700, 
MA: 617-577-9800) on all Sun and DEC platforms; others are under development.

	The Alis office-productivity tool from Applix (1-800-8APPLIX, MA: 
508-870-0300) includes a multi-font WYSIWG document composer; for several
systems.

--------------------------------------------------
19) Where can I obtain an X-based paint/draw program?

	xpic is an object-oriented drawing program. It supports multiple font 
styles and sizes and variable line widths; there are no rotations or zooms.
xpic is quite suitable as an interactive front-end to pic, though the 
xpic-format produced can be converted into PostScript. (The latest version is 
on the R4 contrib tape in clients/xpic.)

	xfig is an object-oriented drawing program supporting compound objects.
The text-handling is limited. The xfig-format can be converted in PostScript or
other formats. The latest is on the R4 contrib tape in clients/xfig; it is one 
of the several 'xfig' programs which several groups independently developed 
parallel versions of from the R3 xfig.

	idraw 2.5 supports numerous fonts and various line styles and arbitrary
rotations. It supports zoom and scroll and color draws and fills. On the R4 
tape; see also interviews-request@interviews.stanford.edu.

[courtesy Jim Helman (jim@kaos.Stanford.EDU) 7/89; some comments added by XUG]

In addition:

	dxpaint is a bitmap-oriented drawing program most like MacPaint; it's 
good for use by artists but bad for drawing figures or drafting. dxpaint is 
part of the Ultrix 3.x release.

	FrameMaker has some draw capabilities. [4/90]

--------------------------------------------------
20) Where can I obtain an X-based spreadsheet?

Vendor                        Product    Phone
------                        -------    -----
Access Technology             20/20      (508) 655-9191
Informix                      WingZ      (800) 331-1763
Quality Software Products     Q-Calc/eXclaim    800-628-3999 (CA:213-410-0303) 
Unipress                      Q-Calc     (201) 985-8000
Uniplex                       Uniplex    (214) 717-0068, (800) 356-8063
[above from Walter E. Gillett (gillett@AI.MIT.EDU)]
Digital				DECdecision   1-800-DIGITAL

BBN Software Products         BBN/Slate  617-873-3984 (Scott Richardson)
	(the product includes WordProcessing, Spreadsheet, Graphics, Image 
	Processing, Foreign Language WordProcessing, Electronic Mail, and 
	Elecronic Conferencing)

The Alis office-productivity tool from Applix (1-800-8APPLIX, MA: 508-870-0300)
includes a spreadsheet.

--------------------------------------------------
21) Where can I get a PostScript previewer for X?

	xps is available from almost everywhere that the X11 contributed source
can be found. The version currently on expo is based on Crispin Goswell's 
PostScript interpreter with fixes and speedups by John Myers and Barry Shein 
and an X11 driver by Terry Weissman.  There are known problems with fonts. The 
package is good for lowering the edit-print-edit cycle in experimenting with 
particular PostScript effects.

	Ghostscript is distributed by the Free Software Foundation 
(617-876-3296) and includes a PostScript interpreter and a library of graphics
primitives. The README for the current version, 1.3, points out that it doesn't
take advantage of many of the facilities offered by X but that this is intended
to change in the future. The software can probably be found on prep.ai.mit.edu.
A 1.4beta may be found on uunet. [2/90]

In addition:

	ScriptWorks is Harlequin's software package for previewing and printing
PostScript(R) descriptions of text and graphics images; previewers for X are 
available. For information call +44-223-872522 or send email to 
scriptworks-request@uk.co.harlqn.

	Digital's dxpsview runs on UWS 2.1 and 2.2.

	Sun's pageview runs with the X11/NeWS server. 

--------------------------------------------------
22) Where can I get a troff previewer for X?

	X11R4 has two previewers for device-independent troff: the supported 
client xditview, and the contributed-but-well-maintained xtroff. An earlier 
version of xtroff also appeared on the R3 contributed source.

In addition:

	Elan Computer Group (CA: 415-964-2200) produces eroff, a modified 
troff implementation, and Elan/Express, an X11 eroff previewer (misleadingly)
labeled "WYSIWYG".

	SoftQuad (416-963-8337; USA only 800-387-2777, mail@sq.uu.net or
mail@sq.com) offers SoftQuad Publishing Software, including a substantially-
rewritten troff formatter, a better intermediate language with backwards 
compatibility, and an X11[R3,R4] previewer. (This is the package adopted by 
AT&T's own MIS department, and used in and re-sold by many parts of AT&T). 
[information from Ian Darwin, SoftQuad (ian@sq.com) 3/90]

	Image Network (1-800-TOXROFF; CA: 415-967-0542) has the 'xroff' 
package, which includes a fine modified troff implementation and a set of 
X11-based page previewers. (This is the package OEM'ed by several hardware 
vendors.)

[mostly courtesy moraes@cs.toronto.edu (Mark Moraes)] [2/90]

--------------------------------------------------
23) How do I convert Mac/TIFF/GIF/Sun/PICT/Face/img/FAX/etc images to X?

	The likeliest program is an incarnation of Jef Poskanzer's useful++ 
Portable Bitmap Toolkit, which includes a number of programs for converting 
among various image formats. It includes support for many types of bitmaps, 
gray-scale images, and full-color images. The latest version, PBMPLUS, was 
posted to the net about 11/22/89; it is also on the R4 tape under 
contrib/clients/pbmplus.
	The package has been independently updated to support XPM images for
pixmaps.
	Useful for viewing some image-formats is Jim Frost's xloadimage, a
version of which is in the R4 directory contrib/clients/xloadimage. 

	[Both PBMPLUS and xloadimage are under active development; watch for
updated versions.]

--------------------------------------------------
24) How do I use an alternate window manager with DEC's session manager?

	DEC's session manager will start dxwm up by default. To override this, 
add to your .Xdefaults file something like this line, naming the full pathname:

	sm.windowManagerName:   /usr/bin/X11/your_favorite_wm

--------------------------------------------------
25) How do I build X with gcc?

	MIT is now using regularly the Free Software Foundation's
GNU-CC to build the X distribution and uses gcc-built servers to test 
performance increases.

	[These options are gathered from several descriptions of building
X with gcc 1.34, 1.35, and 1.36]:

	Use the options
		-O -fstrength-reduce -fpcc-struct-return

		-traditional may also be necessary if your version of
gcc is sufficiently old.

	Do not use -finline-functions, particularly on the R4 server.

	--->	Make sure to run 'fixincludes' from the gcc distribution 
	--->	before doing anything, or you will get fatal errors such as:
	--->	xterm: Error 15, errno 25: Inappropriate ioctl for device.

HOWEVER, there is a bug in gcc 1.34 and 1.36 (but not in 1.35 or 1.37) which 
miscompiles things of the form (expr == 0 ? exp1 : exp2).  The fix needed in 
X11R4 (and probably X11R3) is to change the definition of XtNewString in 
Intrinsic.h to:
  #define XtNewString(str) \
  ((str) != NULL ? (strcpy(XtMalloc((unsigned)strlen(str) + 1), str)) : NULL)
A work-around is also in fix-2 to X11R4.

--------------------------------------------------
26) What are these funny problems compiling X11R3 on the Sun4?

	cc -c -O -I. -I../../include -I../../.././X11 -I../mfb   cfbbitblt.c
	cc: Fatal error in iropt: Illegal instruction (core dumped)

	Known problems with the Sun4 optimizer render the -O flag unusable
on this file. 

	In addition, there is a problem in all of the procedures that return a
parameter that was never referenced.  Instead of returning the string, the 
compiler with optimization seems to be returning the last value computed.  You 
can compile lib/Xt/TMparse.c without optimization; alternatively, you can 
replace the "return str" in various routines to use that parameter [courtesy of
Jim Fulton, MIT X Consortium]:

#ifdef sparc
/*
 * The silly optimizer in SunOS 4.0.3 and below generates bogus code that
 * causes the value of the most recently used variable to be returned instead
 * of the value passed in.
 */
static String silly_optimizer_kludge;
#define BROKEN_OPTIMIZER_HACK(val) silly_optimizer_kludge = (val)
#else
#define BROKEN_OPTIMIZER_HACK(val) val
#endif

and have routines end with
    return BROKEN_OPTIMIZER_HACK(str);

Note also that the SPARCstation1 has a bug in its use of -misalign; a fix 
to cc should be obtained from Sun.

--------------------------------------------------
27) What are these funny problems installing X11R4 on the Sun running SunOS 4?
All of the executables that I try to run have the following results:
	ld.so: libXmu.so.4: not found
or even:
	ld.so: call to undefined procedure __GetHostname from 0xf776a96c

	If you are building with shared libraries on a Sun, remember that you 
need to run "ldconfig" as root after installing the shared libraries (if you've
installed X on a file-server, run it on the server's clients, too).  While 
building and installing the distribution, you need to be careful to avoid 
linking against any existing X shared libraries you might have (e.g. those 
distributed with OpenWindows).  You should make sure you do not have 
LD_LIBRARY_PATH set in your environment during the build or the installation.  
If you are going to keep xterm and xload as setuid programs, please note that 
the shared libraries must be installed in /usr/lib or /usr/5lib for these 
programs to work (or else those programs must be linked statically). 
[courtesy MIT X Consortium]

--------------------------------------------------
28) Where can I get a fast X server for a workstation?

	The R4 server should be among the fastest available for most machines.

	The "Purdue" speedups significantly speed up the X11R3 server.  Look on
expo.lcs.mit.edu:contrib/Purdue.2.[01]-tar.Z. (You'll also need gcc.)

	International Quest Corporation (408-988-8289) has an optimized R3 
server for Sun3/4/386i under SunOS 4.0 and also an optimized R4 server. 

	Torch Technology Ltd makes several R3-based tuned servers, most 
notably for Sun 3 and Sun 4.  Call (UK) +44 223 841000 for information. (Note:
Torch is about to go out of business; so far the fate of its products is 
unclear.)

	Several companies are making hardware acclerator boards:

	Dupont Pixel Systems, for Sun.

	Megatek's X-cellerator board for the Sun 3 and Sun 4 is based on the TI
34020; the company claims performance improvements of 5x to 10x.

--------------------------------------------------
29) How can I change the titlebar of my xterm window?

	The solution involves sending an escape sequence to xterm which will
cause it to update the property which the window manager relies upon for the
string which appears in the window titlebar.
	A solution is as easy as typing this in an xterm running a shell:
		echo "ESC]2;TEXT^G"
where ESC is the escape key, TEXT is the string you wish to have displayed,
and ^G is a Control-G (the BEL character).

	Here is a more complicated csh alias which changes the titlebar to
the current working directory when you change directories:
		alias newcd 'cd \!* ; echo ESC]2\;$cwd^G'

	The digit '2' in these strings indicates to xterm that it should 
change only the title of the window; to change both the title and the name 
used in the icon, use the digit '0' instead, and use '1' to change only the 
icon name.

[For more information, see the article by Skip Montanaro of GE CR&D on Xterm
control sequences in the December 1989 XNextEvent.]

--------------------------------------------------
30) Why doesn't anything appear when I run this simple program?

> ...
> the_window = XCreateSimpleWindow(the_display,
>      root_window,size_hints.x,size_hints.y,
>      size_hints.width,size_hints.height,BORDER_WIDTH,
>      BlackPixel(the_display,the_screen),
>      WhitePixel(the_display,the_screen));
> ...
> XSelectInput(the_display,the_window,ExposureMask|ButtonPressMask|
> 	ButtonReleaseMask);
> XMapWindow(the_display,the_window);
> ...
> XDrawLine(the_display,the_window,the_GC,5,5,100,100);
> ...

	You are right to map the window before drawing into it. However, the 
window is not ready to be drawn into until it actually appears on the screen --
until your application receives an Expose event. Drawing done before that will 
generally not appear. You'll see code like this in many programs; this code 
would appear after window was created and mapped:
  while (!done)
    {
      XNextEvent(the_display,&the_event);
      switch (the_event.type) {
	case Expose:	 /* On expose events, redraw */
		XDrawLine(the_display,the_window,the_GC,5,5,100,100);
		break;
	...
	}
    }

	Note that there is a second problem: some X servers don't set up the 
default graphics context to have reasonable foreground/background colors, and 
your program should not assume that the server does, so this program could 
previously include this code to prevent the case of having the foreground and 
background colors the same:
  ...
  the_GC_values.foreground=BlackPixel(the_display,the_screen);	/* e.g. */
  the_GC_values.background=WhitePixel(the_display,the_screen);	/* e.g. */
  the_GC = XCreateGC(the_display,the_window,
                GCForeground|GCBackground,&the_GC_values);
  ...
 
Note: the code uses BlackPixel and WhitePixel to avoid assuming that 1 is 
black and 0 is white or vice-versa.  The relationship between pixels 0 and 1 
and the colors black and white is implementation-dependent.  They may be 
reversed, or they may not even correspond to black and white at all.

--------------------------------------------------
31) What is the difference between a Screen and a screen?

	The 'Screen' is an Xlib structure which includes the information about
one of the monitors or virtual monitors which a single X display supports. A 
server can support several independent screens. They are numbered unix:0.0,
unix:0.1, unix:0.2, etc; the 'screen' or 'screen_number' is the second digit --
the 0, 1, 2 which can be thought of as an index into the array of available 
Screens on this particular Display connection.
	The macros which you can use to obtain information about the particular
Screen on which your application is running typically have two forms -- one
which takes a Screen and one with takes both the Display and the screen_number.
	In Xt-based programs, you typically use XtScreen(widget) to determine 
the Screen on which your application is running, if it uses a single screen.
	(Part of the confusion may arise from the fact that some of the macros
which return characteristics of the Screen have "Display" in the names -- 
XDisplayWidth, XDisplayHeight, etc.)
	
--------------------------------------------------
32) Why do I get a BadDrawable error drawing to XtWindow(widget)?
I'm doing this in order to get a window into which I can do Xlib graphics
within my Xt-based program:

> canvas = XtCreateManagedWidget ( ...,widgetClass,...) /* drawing area */
> ...
> window = XtWindow(canvas);	/* get the window associated with the widget */
> ...
> XDrawLine (...,window,...);	/* produces error */

	The window associated with the widget is created as a part of the 
realization of the widget.  Using a window id of NULL ("no window") could 
create the error that you describe.  It is necessary to call XtRealizeWidget() 
before attempting to use the window associated with a widget.

--------------------------------------------------
33) Can I get a window's background pixel/pixmap using XGetWindowAttributes?

	No.  Once set, the background pixel or pixmap of a window cannot be 
re-read by clients.  The reason for this is that a client can create a pixmap,
set it to be the background pixmap of a window, and then free the pixmap. The 
window keeps this background, but the pixmap itself is destroyed.  If you're 
sure a window has a background pixel (not a pixmap), you can use XClearArea() 
to clear a region to the background color and then use XGetImage() to read 
back that pixel.  However, this action alters the contents of the window, and 
it suffers from race conditions with exposures. [courtesy Dave Lemke of NCD 
and Stuart Marks of Sun]

	Note that the same applies to the border pixel/pixmap. This is a 
(mis)feature of the protocol which allows the server is free to manipulate the
pixel/pixmap however it wants.  By not requiring the server to keep the 
original pixel or pixmap, some (potentially a lot of) space can be saved. 
[courtesy Jim Fulton, MIT X Consortium]

--------------------------------------------------
34) Why does the pixmap I copy to the screen show up as garbage? 

	The initial contents of pixmaps are undefined.  This means that most
servers will allocate the memory and leave around whatever happens to be there 
-- which is usually garbage.  You probably want to clear the pixmap first using
XFillRectangle() with a function of GXcopy and a foreground pixel of whatever 
color you want as your background (or 0L if you are using the pixmap as a 
mask). [courtesy Dave Lemke of NCD and Stuart Marks of Sun]

--------------------------------------------------
35) Why doesn't my program get the keystrokes I select for?

	The window manager controls how the input focus is transferred from one
window to another.  In order to get keystrokes, your program must ask the
window manager for the input focus.  To do this, you must set up what are
called "hints" for the window manager.  If your applications is Xlib-based, you
can use something like the following:

        XWMHints wmhints;
        ...
        wmhints.flags = InputHint;
        wmhints.input = True;
        XSetWMHints(dpy, window, &hints)


If your application is based on the Xt Intrinsics, you can set the XtNinput 
resource to be True (as you probably want to in any case); if you don't have
source, you can start up the application with the resource '*input:True'.

Certain window managers, notably dxwm, are very picky about having this done.

[mostly courtesy Dave Lemke of NCD and Stuart Marks of Sun]

--------------------------------------------------
36) How can my application iconify itself?

	The ICCCM provides a mechanism for this; your application sends a
client message which includes a data value indicating that it wishes to be
iconified.  Here is a sample callback that will iconify the application shell, 
wait 3 seconds, and pop it back up. Note that ApplicationShellWidget below
is global; it would make more sense in real use to walk up the tree via 
XtParent() to find the shell containing the active widget.

   void IconifyShell(w, d1, d2)
        Widget w;
        caddr_t d1, d2;
   {
     XClientMessageEvent event;
     Window win;
     Display *dpy;

     event.type = ClientMessage;
     event.send_event = True;
     dpy = event.display = XtDisplay(w);
     win = event.window = XtWindow(ApplicationShellWidget);
     event.message_type = XInternAtom(dpy, "WM_CHANGE_STATE", False);
     event.format = 32;
     event.data.l[0] = IconicState;
     XSendEvent(dpy, DefaultRootWindow(dpy), False,
                SubstructureRedirectMask | SubstructureNotifyMask, &event);
     XFlush(dpy);
     sleep(3);
     XMapWindow(dpy,win);
   }

[courtesy David Brooks (dbrooks@osf.osf.org), 4/90]

--------------------------------------------------
37) How do I check whether a window ID is valid?
My program has the ID of a window on a remote display. I want to check whether
the window exists before doing anything with it.

	Because X is asychronous, there isn't a guarantee that the window would
still exist between the time that you got the ID and the time you sent an
event to the window or otherwise manipulated it. What you should do is send
the event without checking, but install an error handler to catch any BadWindow
errors, which would indicate that the window no longer exists. This scheme
will work except on the [rare] occasion that the original window has been
destroyed and its ID reallocated to another window.

[courtesy Ken Lee (klee@wsl.dec.com), 4/90]

--------------------------------------------------
38) Why can't I set the backgroundPixmap resource in my .Xdefaults file?
I want to be able to do this:
	xclock*backgroundPixmap:      /usr/include/X11/bitmaps/rootweave

	You can't do this. The backgroundPixmap resource is a pixmap of the 
same depth as the screen, not a bitmap (which is a pixmap of depth 1). Because 
of this, writing a generic String to Pixmap converter is impossible, since 
there is no accepted convention for a file format for pixmaps. Therefore, 
neither the X Toolkit or the Athena widget set define a String to Pixmap 
converter; because there is no converter you cannot specify this value as a 
resource.

	The Athena widget set does define a String to Bitmap converter for use 
in many of its widgets, however.

[courtesy Chris D. Peterson (kit@expo.lcs.mit.edu), 4/90]

	[Note: the leading general-purpose format for pixmaps is the XPM format
used by Groupe Bull in several of its programs, including the GWM window 
manager. XPM is being now handled by Richard Hess (rhess@cimshop.uu.net). The
XPM distribution, available on expo as contrib/xpm.tar.Z, includes read/write
routines which can easily be adapted to converters by new widgets which want
to allow specification of pixmap resources in the above manner.]

--------------------------------------------------
39) Why does the R3 xterm, et al, fail against the R4 server?

	The value given to a window's do_not_propagate mask is the likely 
culprit.  R3 allowed bogus values to be set, and early version of both Andrew 
and Interviews did, as well. Similar problems also occur in the R3 Motif
PanedWindow widget.

	If it is impossible to fix client source, use 'xset bc' to put the 
X11R4 server into bug-compatibility mode.

--------------------------------------------------
40) Where can I obtain alternate language bindings to Xlib?

	Versions of the CLX Lisp bindings are part of the X11R3 and X11R4 core 
source distributions. The latest version of CLX (R4.1) is available from expo 
for ftp as contrib/CLX.R4.1.tar.Z [Chris Lindblad (cjl@AI.MIT.EDU), 4/90];
this version fixes bugs reported against the R4 distribution.

	Ada bindings were written by Mark Nelson and Stephen Hyland at SAIC 
for the DOD. The bindings can be found on hapo.sei.cmu.edu or on 
wsmr-simtel20.army.mil and are also in the Ada Software Repository (ASR). 
R3 bindings should be available by the end of 1/90. [1/90]

	Prolog bindings (called "XWIP") written by Ted Kim at UCLA while
supported in part by DARPA are available by anonymous FTP from
expo.lcs.mit.edu:contrib/xwip.tar.Z or ftp.cs.ucla.edu:pub/xwip.tar.Z.
These prolog language bindings depend on having a Quintus-type foreign function
interface in your prolog. The developer has gotten it to work with Quintus and 
SICStus prolog. Inquiries should go to xwip@cs.ucla.edu. [3/90]

	GHG is developing X bindings and a complete Ada re-implementation
of X; check Lionel Hanley at 713-488-8806. [4/90]
-- 

The X User's Group		xug@expo.lcs.mit.edu	+1 617 547 0634
"No, I'm a member of the X User's Group, not the Ex-User's Group."


From ucla-cs!william@oahu.cs.ucla.edu Mon Apr 30 08:55:49 PDT 1990
Article: 22253 of comp.windows.x
Path: ucla-cs!william@oahu.cs.ucla.edu
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: Tgif-1.0 (Xlib based 2-D drawing tool) is available on expo.
Keywords: draw, tool, postscript, latex, hierarchical, x11, xlib
Message-ID: <34796@shemp.CS.UCLA.EDU>
Date: 30 Apr 90 15:54:07 GMT
Sender: news@CS.UCLA.EDU
Followup-To: william@cs.ucla.edu
Organization: UCLA Computer Science Department
Lines: 472
Status: RO

Tgif is an Xlib based 2-D drawing tool under X11.  It also supports
hierarchical construction (top/down, bottom/up) of drawings.

I have just put tgif-1.0.tar.Z in the contrib directory on expo.lcs.mit.edu.
Below is the man pages of tgif.  Please send any comments/bug reports
to william@cs.ucla.edu.

--Bill Cheng
========================= nroff output of tgif.man =============================

From ucla-cs!william@oahu.cs.ucla.edu Mon Apr 30 10:55:23 PDT 1990
Article: 22260 of comp.windows.x
Path: ucla-cs!william@oahu.cs.ucla.edu
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: Re: Tgif-1.0 (Xlib based 2-D drawing tool) is available on expo.
Keywords: draw, tool, postscript, latex, hierarchical, x11, xlib
Message-ID: <34799@shemp.CS.UCLA.EDU>
Date: 30 Apr 90 17:54:18 GMT
Sender: news@CS.UCLA.EDU
Followup-To: william@cs.ucla.edu
Organization: UCLA Computer Science Department
Lines: 10
Status: RO

I put the wrong 'spline.c' into tgif-1.0.tar.Z this morning around 9am.
The correct version of tgif-1.0.tar.Z is in the contrib directory on
expo.lcs.mit.edu now.  Sorry about the mistake.

--Bill Cheng
--

-- Bill Cheng // UCLA Computer Science Department // (213) 206-7135
   3277 Boelter Hall // Los Angeles, California 90024 // USA
   william@CS.UCLA.EDU      ...!{uunet|ucbvax}!cs.ucla.edu!william


From ucla-cs!william@oahu.cs.ucla.edu Wed May  2 08:09:04 PDT 1990
Article: 22309 of comp.windows.x
Path: ucla-cs!william@oahu.cs.ucla.edu
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: tgif-1.0 and malloc_debug() problem on DECstation
Message-ID: <34874@shemp.CS.UCLA.EDU>
Date: 2 May 90 06:57:18 GMT
Sender: news@CS.UCLA.EDU
Followup-To: william@cs.ucla.edu
Organization: UCLA Computer Science Department
Lines: 17
Status: RO

Jeff Webber pointed out that there is no malloc_debug() on DECstation 3100's.
I've just put 'tgif.malloc.patch.tar' in the contrib directory on
expo.lcs.mit.edu to patch out calls to malloc_debug().  To patch the 3
files that references malloc_debug(), untar tgif.malloc.patch.tar and type

	patch < Imakefile.patch
	patch < tgif.c.patch
	patch < pdraw11.c.patch

I hope this doesn't cause too much trouble for people using DECstations
(We don't have any DECstations here, yet).  In the future, I'll remove
calls to malloc_debug() since they only serves bug catching purposes.
--

-- Bill Cheng // UCLA Computer Science Department // (213) 206-7135
   3277 Boelter Hall // Los Angeles, California 90024 // USA
   william@CS.UCLA.EDU      ...!{uunet|ucbvax}!cs.ucla.edu!william


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws Wed May  2 11:21:28 PDT 1990
Article: 22324 of comp.windows.x
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: Questions about ORing Clip Rectangles into a GC and setting DashList
Message-ID: <9005021343.AA11503@expire.lcs.mit.edu>
Date: 2 May 90 13:43:39 GMT
References: <328@lennon.austek.oz>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 23
Status: O


    Is there any way to set the GCDashList without using the
    XSetDashes convenience function ?

Not for a list of length greater than one (i.e., it isn't really a
convenience function).

    XSetDashes takes a dash list (char
    dash_list[]) and the length of the list, but the XGCValues structure
    only defines a single dash character (char dashes).

If you want to keep a copy of the GC state, including full dash and clip
state, you'll have to keep more information than just the XGCValues structure.

    Is there a way to OR a set of XRectangles (i.e the
    arguments to XSetClipRectangles) into a Pixmap (the value already
    stored in the object's GC)?  I want the clipped region to be the
    intersection of the existing Clip Mask and the Exposed region.

OR is like union, AND is like intersection.  Either way, you can't do it
directly if the clip state is really a Pixmap.  I'm afraid you'd have
to create a new bitmap, and then or/and the two regions together using
graphics operations into the bitmap.


From ucla-cs!usc!apple!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws Thu May  3 08:02:38 PDT 1990
Article: 22355 of comp.windows.x
Path: ucla-cs!usc!apple!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: Legal status of X fonts
Message-ID: <9005022243.AA11928@expire.lcs.mit.edu>
Date: 2 May 90 22:43:04 GMT
References: <9005022228.AA05371@rose>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 19
Status: O


    Can fonts delivered in the X11 distribution be used in a non X
    application without paying a licence fee?

Some of the fonts are "public domain", you can do anything you want
with them.  Most of the fonts carry explicit copyright and permission
notices; read the notices to see what you can do.  For example, many
carry something of this form:

    Permission to use, copy, modify, and distribute this software and
    its documentation for any purpose and without fee is hereby granted,
			  ^^^
Note this word:------------|
    provided that <read the rest of this fine print!>

The word "any" really means any.

Many fonts also carry statements about use of trademark; you need to pay
attention to those statements as well.


From ucla-cs!usc!snorkelwacker!bloom-beacon!osf.ORG!vania Thu May  3 11:41:39 PDT 1990
Article: 22371 of comp.windows.x
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!osf.ORG!vania
From: vania@osf.ORG (Vania Joloboff)
Newsgroups: comp.windows.x
Subject: Re: X Books
Message-ID: <9005031518.AA03728@osf.osf.org>
Date: 3 May 90 15:18:13 GMT
References: <1990May2.231343.25973@cs.columbia.edu>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 20
Status: O


The five OSF/Motif books edited by Prentice Hall are:

OSF/Motif Style Guide ISBN 0-13-640491-X
OSF/Motif User's Guide ISBN 0-13-640509-6
OSF/Motif Programmer's Reference ISBN 0-13-640517-7
OSF/Motif Programmer's Guide ISBN 0-13-640525-8
OSF/Motif Application Environment specifications (AES) ISBN 0-13-640483-9

The author is "Open Software Foundation".


Also by Prentice Hall

The X Window System, Programming with Xt
	The OSF/Motif edition

author is Douglas A Young

ISBN 0-13-497074-8 


From ucla-cs!usc!snorkelwacker!bloom-beacon!UMIACS.UMD.EDU!steve Sat May  5 21:18:49 PDT 1990
Article: 22429 of comp.windows.x
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!UMIACS.UMD.EDU!steve
From: steve@UMIACS.UMD.EDU
Newsgroups: comp.windows.x
Subject: At long last -- OSF licensing summary
Message-ID: <9005041749.AA18253@fnord.umiacs.UMD.EDU>
Date: 4 May 90 17:49:23 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 70
Status: O


   Here, at long last, is the summary of responses I got to my question (a
month ago) about OSF licensing.  I asked people to tell me whether they were
a government, commercial, or educational institution; whether or not they
licensed sources successfully; what problems they had; and who they talked
to.  I received only ten responses (plus the local experiences, that makes
eleven), so the sample isn't quite as large as I'd liked.  One response
detailed two experiences with licensing.  Two other responses were from
people who were after binary distributions, and I didn't include those
responses in the numbers below.  Another response was from someone at OSF
who suggested that I join the OSF licensing SIG.  Time and financial
constraints prevent me from doing so, however.

   The fractions below indicate that someone's supposedly got a license 'in
the mail' from OSF to the licensee, or that someone had a problem that might
not have been all that bad (from their description).

Commercial sites:
	attempts: 6
	success: 4.5; 2.5 with problems

Educational/govt sites:
	attempts: 4 (including UMCP)
	success: 2 (ditto); 1 with problems (UMCP)

   From the responses I got, and from our own experience, the biggest
problem with licensing was with getting the OSF people to *call back*.
Almost everyone who had problems had problems because they couldn't get the
OSF legal people and/or help desk to respond to paper mail, voice mail, or
even their phones.  Some names were named as the people who were causing
problems (by being particularly guilty in this regard, or in other ways); I
will be more than happy to provide these names to OSF upon request by them.
One person said he called and asked for information.  He left his name and
number on the answering machine, and was never called back.

   It appears that the OSF charter prohibits OSF from offering different
license agreements to different organizations.  Thus, if one organization
needs a license modification, that modification must be made available to
other licensees, also.  This is likely to make the licensing problem
somewhat hairier for someone requesting a modification for the first time.
One person I talked to at OSF said that OSF is willing to make
modifications; previously, I'd thought that maybe OSF simply couldn't make a
change to its licenses without dissolving and re-incorporating itself so
that it could change its charter.  If you hear that OSF can't make license
changes, someone is either misinformed or is lying to you...

   One notable response pointed out that one organization has *seven*
departments who have all tried to get Motif sources at some point.  All have
failed because of legal issues.

   Our experience here was interesting.  After sending out my request for
information, I was called three or four times by two different people at
OSF.  They finally got the paperwork straightened out, and the Motif source
tape arrived this week.  (I've been holding off on my summary because I knew
something was afoot, and I wanted to give OSF the benefit of the doubt.)  I
don't want to give out their names to everyone, since I suspect that if they
get pestered a lot, they'll be somewhat less inclined to jump in and help.
If you're really stuck on a Motif (or, presumably, OSF/1) source licensing
issue, drop me a line, and I'll see what I can work out.

   I do have an archive of the responses I received.  I don't want to send
them out without checking with the authors, but if there is interest, I can
go check back with them.  Let me know.  If you don't feel that this summary
is adequate, let me know that, too, and maybe I can come up with some more
information.

	-Steve

Spoken: Steve Miller    Domain: steve@umiacs.umd.edu    UUCP: uunet!mimsy!steve
Phone: +1-301-454-1808  USPS: UMIACS, Univ. of Maryland, College Park, MD 20742


From ucla-cs!elroy.jpl.nasa.gov!sdd.hp.com!hplabs!hpfcso!stroyan Mon May  7 19:52:06 PDT 1990
Article: 22483 of comp.windows.x
Path: ucla-cs!elroy.jpl.nasa.gov!sdd.hp.com!hplabs!hpfcso!stroyan
From: stroyan@hpfcso.HP.COM (Mike Stroyan)
Newsgroups: comp.windows.x
Subject: Re: Polygon filling and scalable fonts
Message-ID: <7320007@hpfcso.HP.COM>
Date: 7 May 90 21:53:39 GMT
References: <1184@digiw.UUCP>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 28
Status: O

> If i like to draw O character, it is descripted with two separate
> paths or outlines, one outside and one inside. These two are non connected
> to each other. In postscript i can use two separate paths and then
> fill operator. If i like to use XFillPolygon it does not allow giving
> two separate outlines to it. Of course i can do it by drawing inside
> path with background color fill, but i like that items drawn back
> are still visible from hole like in postscript. 

You can draw a polygon with a hole in it by sending a self-intersecting
polygon.  Given the following points-

   A--------------B
   |              |
   |  E----F I--J |
   |  |    | |  | |
   |  |    | |  | |
   |  H----G L--K |
   |              |
   D--------------C

Either close each path and return to the overall initial point between
paths, or close each path and back track through the initial points of
each path.  You can send the sequence of coordinates ABCDAEFGHEAIJKLIA
or ABCDAEFGHEIJKLIEA.  The X11 definition for polygons is very specific
in requiring any path ABA to affect no pixels along on the line between
A and B.  This works in the both interior and the exterior of polygons.

Mike Stroyan, stroyan@hpfcla.hp.com


From ucla-cs!elroy.jpl.nasa.gov!usc!cs.utexas.edu!uunet!mcsun!ukc!harrier.ukc.ac.uk!rlh2 Wed May  9 13:05:36 PDT 1990
Article: 22564 of comp.windows.x
Path: ucla-cs!elroy.jpl.nasa.gov!usc!cs.utexas.edu!uunet!mcsun!ukc!harrier.ukc.ac.uk!rlh2
From: rlh2@ukc.ac.uk (R.L.Hesketh)
Newsgroups: comp.windows.x
Subject: Re: EventMask for XSendEvent
Message-ID: <4614@harrier.ukc.ac.uk>
Date: 9 May 90 17:02:05 GMT
References: <26900116@m.cs.uiuc.edu>
Reply-To: rlh2@ukc.ac.uk (Richard Hesketh)
Organization: Computing Lab, University of Kent at Canterbury, UK.
Lines: 32
Status: O

In article <26900116@m.cs.uiuc.edu> carroll@m.cs.uiuc.edu writes:
>I'm having problems with Client Messages and XSendEvent. The code works on a
>SysV 11R3 system, but not on Sun-3's or Sparcs with SunOS4.0.3 & 11R4.

Ahh, that little nut.  I think this one is getting popular enough to
become a "common asked question about X11".

>In desperation, I tried the following:
>	XSendEvent(xr->dpy,xr->id,False,
>		SubstructureNotifyMask | SubstructureRedirectMask,
>		,&ev); 

Try ..

	XSendEvent(xr->dpy, xr->id, False, 0L, &ev);

(ie. a null event mask)

Xlib manual (section 8.10):

"If the event_mask is the empty set, the event is sent to the client
 that created the destination window.  If that client no longer exists,
 no event is sent."

>What I want to know is why I can't send it with _all_ the event
>mask bits set?

The ClientMessage event is non-maskable and does not have an event mask.

>               Was something changed here from R3 to R4? Thanks!

Yup, the MIT Server is stricter about obeying the protocol.


From ucla-cs!usc!zaphod.mps.ohio-state.edu!rpi!uwm.edu!ogicse!mintaka!bloom-beacon!EXPO.LCS.MIT.EDU!rws Thu May 10 09:32:15 PDT 1990
Article: 22600 of comp.windows.x
Path: ucla-cs!usc!zaphod.mps.ohio-state.edu!rpi!uwm.edu!ogicse!mintaka!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: EventMask for XSendEvent
Message-ID: <9005101313.AA02746@expire.lcs.mit.edu>
Date: 10 May 90 13:13:45 GMT
References: <26900117@m.cs.uiuc.edu>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 27
Status: O


    Under R3 I can reconcile these by using an EventMask of ~0.

It is only an approximate reconciliation.  Specifying 0 is very different
from specifying a(ny) set of bits.  The resulting behaviour may actually
be the same for most kinds of windows you come into contact with, but
they aren't semantically equivalent.  Specifying 0 means send to (only)
the owner, regardless of how many clients are selecting for events on the
window, and regardless of whether the owner is even selecting for events
on the window.  Specifying a set of bits means send to every client selecting
for any of the given events types.  So if you happened to have a distributed
application, where one client created the window but some other client is
actually responsible for I/O on it, you will get very different behaviour
between specifying 0 and specifying some bits.

    What is the preferred solution to this? I want to avoid either having the
    Elisp programmer specify the EventMask, or having two calls for the two
    cases.

Without knowing what semantics you really desire, it's hard to say.  It
sounds like you want a simplistic solution that will work most of the time.
In that case, instead of using -1, use the complete set of legal bits instead
(don't ask what they are, read the documentation).  Or perhaps you want a
solution that will work for existing uses specified by the ICCCM.  In that
case, have your routine look to see whether the destination window is a
root window, and choose 0 vs. (SubstructureNotifyMask|SubstructureRedirectMask)
on that basis.


From ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!kit Thu May 10 21:37:29 PDT 1990
Article: 22623 of comp.windows.x
Path: ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!kit
From: kit@EXPO.LCS.MIT.EDU (Chris D. Peterson)
Newsgroups: comp.windows.x
Subject: Re: EventMask for XSendEvent
Message-ID: <9005101915.AA25215@expo.lcs.mit.edu>
Date: 10 May 90 19:15:26 GMT
References: <6073@amelia.nas.nasa.gov>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 26
Status: O


> I am unable to get a bitmap to be displayed on a command widget.
> Is there something I'm missing ?? 

You have to pass a valid bitmap (or pixmap) when setting thIS resouce via
XtSetValues() or at widget creation time.  The SetValues() interface expects the
resource to already be the proper type.  In this case you will need to either
create the bitmap yourself, or call XtDirectConvert().  

If you had specified this resource in an app-default file, or the user had
specified this resource in his/her resource file then the converted would have
been invoked to automatically convert this string (the filename) to a bitmap. 
This is one of the reasons why you should use the XtSetValues() interface
sparingly, giving preference to the resource files.


Yo, Xug folks, this should really be on the frequently asked questions list, if
it is not there already.


						Chris D. Peterson     
						MIT X Consortium 

Net:	 kit@expo.lcs.mit.edu
Phone:   (617) 253 - 9608	
Address: MIT - Room NE43-213


From ucla-cs!usc!samsung!uunet!trwacs!epstein Sat May 12 18:56:28 PDT 1990
Article: 22644 of comp.windows.x
Path: ucla-cs!usc!samsung!uunet!trwacs!epstein
From: epstein@trwacs.UUCP (Jeremy Epstein)
Newsgroups: comp.windows.x
Subject: Summary of commercial X software responses (long)
Keywords: Office automation, user interface management systems
Message-ID: <207@trwacs.UUCP>
Date: 11 May 90 18:59:40 GMT
Organization: TRW Systems Division, Fairfax VA
Lines: 299
Status: O


Several weeks ago I asked:

>We're looking for information on commercially available X products to run
>on Sun SPARCstations.  Categories of interest include:

>       *       Word processing
>       *       Spreadsheets
>       *       Calendar/calculators
>       *       Business graphics
>       *       Statistical analysis
>       *       Electronic mail
>       *       Natural language processors (to SQL)

>We're not particular what X toolkit or look-and-feel the application uses
>(e.g., Motif, OpenLook, XView, ...)

In a later message, I also asked for information about User Interface
Management Systems.

This message is a summary of the responses I've received.  If you
know of things I've missed, please let me know.  If there are comments
which don't make sense, please correct them (some of the vendor
statements just didn't make sense, but I put them in anyway).

Thanks to everyone who send information, suggestions, etc.:
	uunet!pinocchio.encore.com!knighten
	uunet!statsci!bob
	uunet!sun.UUCP!hvr
	uunet!alphalpha.com!nazgul
	uunet!Sun.COM!argv
	uunet!jatz.aarnet.edu.au!pte900
	uunet!ccicpg!quad1!few
	uunet!mcsun!prosys.se!stefan
	uunet!East.Sun.COM!npg
	uunet!andrew.cmu.edu!mss+
	uunet!rutgers!mars.jpl.nasa.gov!hashem
	uunet!ics.com!xug
Some of these people forwarded messages from other people, whom I would
like to (indirectly) thank as well.  Thanks also to the people who used
(gasp) the *telephone* or *USMail* to send us information.  Finally, if
I have misrepresented any of the products in editing the messages, please
accept my apologies and send me corrections!

Several people also referred me to various Sun catalogs and sales
people.  There's a SparcWare catalog for independent software vendors
(call 1-800-USA-4SUN).  I was also referred to the "Sun Developer's Guide".

All information is provided "as is"...and I'm not endorsing any of
these products!!!


		**************************
		OFFICE AUTOMATION SOFTWARE
		**************************

S-Plus
	Type: statistics program
	Contact:
		STATSCI
	Contact:
		Bob Treder
		STATSCI
		uunet!statsci!bob

Crosswind Technologies
	Product name: Synchronize
	Type: calendar/scheduling
	Contact:
		Ron Hughes
		Crosswind Technologies
		408-335-4988
	Toolkits, etc.:
		Motif

Alphalpha software
	Type: electronic mail (not yet released)
	Contact:
		Kee Hinckley
		Alphalpha Software
		148 Scituate St.
		Arlington, MA 02174
		617/646-7703
	Toolkits, etc.:
		Motif

O'Reilly and Associations
	Type: electronic mail
	Contact:
		Dan Heller
		uunet!Sun.COM!argv
		O'Reilly & Associates
	        632 Petaluma Ave
		Sebastopol, CA 95472
		800-338-NUTS
		in CA: 800-533-NUTS
		FAX 707-829-0104
	Toolkits:
		Any
	Note:
		Dan Heller is marketing this on his own, not through
		O'Reilly.  The initial target is Xview based OpenLook.
		It's not yet available for release.  Dan's number
		is 415-499-UNIX.

UniPlex
	Type: integrated office automation
	Contact:
		Uniplex
		214-717-0068
		800-356-8063

Quadratron Systems
	Type: integrated office automation (word processing, calculator,
		calendar/scheduling, presentation graphics, email, form
		compliant, electronic phonebook, etc.)
	Contact:
		Frank Whaley
		Senior Development Engineer
		Quadratron Systems Incorporated
		few@quad1.quad.com
		uunet!ccicpg!quad1!few
	Toolkits:
		Uses multiple xterm's
		Future: Motif

Exclaim:
	Type: X Window Spreadsheet with Lotus 1-2-3 compatibility
	Contact:
		Quality Software Products, Inc.
		5711 West Slavson Ave
		Suite 204
		Culver City CA  90230
		213-410-0303
		uunet!qsp!sales
	Toolkits:
		Motif

BBN/Slate
	Type: Office automation and multimedia document software
	Contact:
		BBN Software Products Corp
		10 Fawcett Street
		Cambridge MA  02138
		617-873-5000
	Toolkits:
		Sunview; Motif version available summer '90

Framemaker
	Type: Electronic publishing
	Contact:
		Frame Technology Corpo
		1010 Rincon Circle
		San Jose CA  95131
		408-433-3311
	Toolkits:
		Sunview, Xview; Motif version available Aug '90

XED Integrated office software
	Type: Office automation
	Contact:
		XED
		Box 3938
		Chatworth CA  91313
		818-884-2000
	Toolkits:
		Runs under X on a SPARC (may be multi-xterm)

ALIS
	Type: office automation
	Contact:
		Applix, inc
		112 Turnpike Road
		Westboro MA  01581
		508-870-0300
	Toolkits:
		DECwindows, Sunview; currently working on an XView version

See also the list in the monthly "Most Frequently Asked Questions" list
(from xug@ICS.COM).  I've tried to avoid repeating that information here...

		*********************************
		USER INTERFACE MANAGEMENT SYSTEMS
		*********************************

Serpent UIMS
	Alpha release 0.8
	Available via anonymous ftp:
		fg.sei.cmu.edu (128.237.2.163) in pub/serpent
		expo.lcs.mit.edu (18.30.0.212) in contrib
	Toolkits, etc.:
		Motif widget set
		Athena widget set
	Contact: Erik.Hardy@SEI.CMU.EDU

TeleUSE
	Release 1.1
	Cost: $9900 for development license; no runtime fees
	Contact:
		The TeleUSE Group
		Sally Griffinberg
		TELESOFT
		5959 Cornerstone Court West
		San Diego, Ca 921921-9891
		tel: 619-457-2700
		fax: 619-452-1334
	Toolkits, etc.:
		Motif widget set
		Athena widget set
		Can be configured to use others

Andrew
	Contact:
		info-andrew-request@andrew.cmu.edu

UIMX
	Contact:
		Visual Edge Software Limited
		3870 Cote Vertu
		St. Laurent, Quebec
		Canada
		H4R 1V4
		Michael Foody
		Tel:  (514) 332-6430 or (415) 948-0753

	Toolkits:
		Motif

Guide
	Contact:
		Sun
	Toolkits:
		XView

IUVI
	Contact:
		HP

Tiger
	Contact:
		???

ExoCODE/AutoCODE
	Contact:
		Expert Object Corporation
		7250 Cicero Avenue
		Suite 201
		Lincolnwood,  Illinois 60646
		Tel:  (312) 676-5555
	Toolkits:
		Motif, Overview
	Cost: $1300 for a single workstation

XBuild
	Contact:
		Nixdorf


VUIT
	Contact:
		DEC
	Toolkits:
		Motif

TAE+
	Contact:
		NASA

Builder Xcessory
	Contact:
		ICS
		uunet!ics.com!info
	Not yet available
	Toolkits:
		Motif

WINTERP
	Contact:
		???


		***************
		DESKTOP MANAGER
		***************

Looking Glass
	Contact:
		Visix Software
		11440 Commerce Park Drive
		Reston VA  22091
		703-758-8230
	Toolkits:
		Motif, Sunview
	Cost: $595-1295 per workstation
-- 
Jeremy Epstein
epstein@trwacs.uu.net
TRW Systems Division
703-876-8776


From ucla-cs!uci-ics!jarthur!bridge2!mips!zaphod.mps.ohio-state.edu!rpi!uupsi!rice!uw-beaver!cornell!beck Sat May 12 18:59:30 PDT 1990
Article: 22659 of comp.windows.x
Path: ucla-cs!uci-ics!jarthur!bridge2!mips!zaphod.mps.ohio-state.edu!rpi!uupsi!rice!uw-beaver!cornell!beck
From: beck@hermod.cs.cornell.edu (Micah Beck)
Newsgroups: comp.windows.x,comp.text,comp.text.tex
Subject: (X)Fig Survey Results
Message-ID: <40896@cornell.UUCP>
Date: 11 May 90 23:41:13 GMT
Sender: nobody@cornell.UUCP
Reply-To: beck@cs.cornell.edu (Micah Beck)
Distribution: comp
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 54
Xref: ucla-cs comp.windows.x:22659 comp.text:7208 comp.text.tex:1234
Status: O

Here are the results of a survey posted last week on the use of (X)Fig.
Some of the responses included questions directed at Brian Smith or myself.
We will try to answer them, but if you do not receive a reply soon, please 
mail your question to one of us directly.

Total sites responding	135	100%

Windowing System
	X Windows	105	 78%
	SunView		 62	 46%

WP Software
	LaTeX		110	 81%
	Troff		 35	 26%

Postscript sites	115	 85%
TransFig sites	 	76	 56%

Since the number of Fig users at each site was expressed as range, the result
is very inexact: the aggregate range is 926 - 1740 users.

Here are some notes on the status of Fig-related software which address
concerns and questions expressed by respondants:

TransFig Version 2.0 is now available; it supports XFig 2.0 features when
translating to PostScript, as well as retaining compatibility with Fig 1.4-TFX.
The functionality of the fig2dev program which is part of TransFig V2.0 is
a superset of programs named f2{p,ps} and also of those named
fig2{pic,ps,tex,latex,epic}.  Brian and I encourage users to switch to fig2dev
as the single back end translator for (X)Fig; f2p and f2ps will eventually be
dropped from the XFig distribution.

Fig 1.4.FS is the most recent version of Fig for SunView.  The functionality
of Fig 1.4.FS is a superset of Fig 1.4 R2, an old version which is still
available at some archive sites.  Fig 1.4.FS also includes recent bug fixes.

TransFig and Fig 1.4.FS are both available by anonymous FTP from 
svax.cs.cornell.edu, and by mail from the archive server at
sun.soe.clarkson.edu.  To find out how to use the archive server, send a
mail message containing the single line "help" to
archive-server@sun.soe.clarkson.edu.  TransFig V2.0 will be posted to 
comp.sources.unix sometime soon, and Fig-FS may be posted to comp.sources.sun.
If you still have distribution problems, write to me (beck@cs.cornell.edu) and
I will send the files personally.

We thank you for the many kind comments about our software, and even for
the unkind ones.  It would be unfair not to note that the body of Fig-related
software has a long history involving the efforts of too many people to list
here.  Most of the improvements which members of the user community would like
to see will be realized only through the contributions of users.  Send us
your patches, your fixes, your creeping features yearning to breath free...

Micah Beck, Cornell University			beck@cs.cornell.edu
Brian V. Smith, Lawrence Berkeley Laboratory	envbvs@epb2.lbl.gov


From ucla-cs!uci-ics!jarthur!bridge2!mips!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!bloom-beacon!HARVARD.HARVARD.EDU!oj%saber Sat May 12 19:00:18 PDT 1990
Article: 22660 of comp.windows.x
Path: ucla-cs!uci-ics!jarthur!bridge2!mips!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!bloom-beacon!HARVARD.HARVARD.EDU!oj%saber
From: oj%saber@HARVARD.HARVARD.EDU
Newsgroups: comp.windows.x
Subject: Source level debuggers running under X?
Message-ID: <9005111858.AA18264@armory>
Date: 11 May 90 18:58:17 GMT
References: <1473@dino.cs.iastate.edu>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 31
Status: O


     1. Names of available debuggers:   Saber-C
     2. Availability of source:         Not available
     3. Availability of binaries for VAX/Unix, Sun, DecStations.
                                        All these binaries are available.
     4. Where such may be obtained:     Call 1-617-876-7636 for information.

Saber-C is a comprehensive C programming environment with an integrated
set of tools for programming, debugging, testing, and maintaining code.
It includes:
* Static and run-time error detection, performed automatically during
  code loading and execution.
* Instant turnaround using an incremental linker and loader.
* Graphical browsers for data structures, cross-references, and projects.
* An extensible source-level debugger allowing you to customize
  debugging activity using the full C language, including macros.
  You can set breakpoints, step, and trace through the execution process,
  and set watchpoints on any data address, including allocated data.
* An interactive workspace which allows prototyping and testing by
  providing immediate execution of code fragments.
* Integrated editing through emacs, vi, or other popular editors.
* Operation under either the X Window System or suntools.

Parts of the X Window System, notably Charles Haynes's
work on Xt, were developed with the help of Saber-C.

Regards,
Ollie Jones
Saber Software, Inc.
185 Alewife Brook Parkway
Cambridge, MA 02138


From ucla-cs!william@oahu.cs.ucla.edu Thu May 17 21:25:49 PDT 1990
Article: 22837 of comp.windows.x
Path: ucla-cs!william@oahu.cs.ucla.edu
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: Tgif-1.2 (Xlib based 2-D drawing tool) is available on expo.
Keywords: drawing, tool, xlib, wysiwyg
Message-ID: <35495@shemp.CS.UCLA.EDU>
Date: 18 May 90 04:09:16 GMT
Sender: news@CS.UCLA.EDU
Followup-To: william@cs.ucla.edu
Organization: UCLA Computer Science Department
Lines: 8
Status: RO

I've just put tgif-1.2 in the contrib directory on expo.lcs.mit.edu,
there were some minor bug fixes (mostly `lint' type bugs).  Thanks to
Greg Rogers and Christos Zoulas for their bug reports.
--

-- Bill Cheng // UCLA Computer Science Department // (213) 206-7135
   3277 Boelter Hall // Los Angeles, California 90024 // USA
   william@CS.UCLA.EDU      ...!{uunet|ucbvax}!cs.ucla.edu!william


From ucla-cs!william@oahu.cs.ucla.edu Fri May 25 17:13:14 PDT 1990
Article: 23064 of comp.windows.x
Path: ucla-cs!william@oahu.cs.ucla.edu
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: Tgif-1.3 (Xlib based 2-D drawing tool) is available on expo ...
Keywords: drawing, tool, xlib, wysiwyg
Message-ID: <35706@shemp.CS.UCLA.EDU>
Date: 26 May 90 00:12:41 GMT
Sender: news@CS.UCLA.EDU
Followup-To: william@cs.ucla.edu
Organization: UCLA Computer Science Department
Lines: 17
Status: RO

I've just put tgif-1.3 in the `contrib' directory of `expo.lcs.ucla.edu'
and the `pub' directory of `rye.cs.ucla.edu'.  Here's a short list of
added features/bug fixes.  Special thanks to Chris Overton and
Christos Zoulas for their helpful hints.

1) Add support for encapsulated PostScript (psfig/epsf).
2) Fix a bug related to maximum string length.
3) Support user specified foreground and background colors.
4) Add "^,", "^.", "#,", "#.", and "#K" shorthand commands (scroll left,
   right, up, down, and change drawing mode to select).
5) Modify Imakefile to use a string to specify the location of the
   PostScript macro file.
--

-- Bill Cheng // UCLA Computer Science Department // (213) 206-7135
   3277 Boelter Hall // Los Angeles, California 90024 // USA
   william@CS.UCLA.EDU      ...!{uunet|ucbvax}!cs.ucla.edu!william


From ucla-cs!william@oahu.cs.ucla.edu Sun May 27 13:49:44 PDT 1990
Article: 23080 of comp.windows.x
Path: ucla-cs!william@oahu.cs.ucla.edu
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: Tgif-1.4 (Xlib based 2-D drawing tool) is available on expo ...
Keywords: drawing, tool, xlib, wysiwyg
Message-ID: <35730@shemp.CS.UCLA.EDU>
Date: 27 May 90 08:24:20 GMT
Sender: news@CS.UCLA.EDU
Organization: UCLA Computer Science Department
Lines: 8
Status: RO

There is a minor bug in tgif-1.3 related with disappearing print files.
I've just put tgif-1.4 in both the `contrib' directory of `expo.lcs.ucla.edu'
and the `pub' directory of `rye.cs.ucla.edu'.
--

-- Bill Cheng // UCLA Computer Science Department // (213) 206-7135
   3277 Boelter Hall // Los Angeles, California 90024 // USA
   william@CS.UCLA.EDU      ...!{uunet|ucbvax}!cs.ucla.edu!william


From ucla-cs!william@oahu.cs.ucla.edu Thu May 31 10:49:30 PDT 1990
Article: 23176 of comp.windows.x
Path: ucla-cs!william@oahu.cs.ucla.edu
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: Tgif-1.5 (Xlib based 2-D drawing tool) is available on expo ...
Message-ID: <35791@shemp.CS.UCLA.EDU>
Date: 30 May 90 16:49:17 GMT
Sender: news@CS.UCLA.EDU
Organization: UCLA Computer Science Department
Lines: 14
Status: RO

I've just put tgif-1.5 in the contrib directory on expo.lcs.mit.edu and the
pub directory on rye.cs.ucla.edu.

1) There are fixes to make the printing cleaner.  Thanks Christos Zoulas
   for the improvements.
2) There is also a minor bug fix for stretching splines, it used to leave
   crud on the screen if no stretching is actually done.
3) Imakefile is updated to make it more MIT-ish.  Thanks Andreas Stolcke
   for the improvements.
--

-- Bill Cheng // UCLA Computer Science Department // (213) 206-7135
   3277 Boelter Hall // Los Angeles, California 90024 // USA
   william@CS.UCLA.EDU      ...!{uunet|ucbvax}!cs.ucla.edu!william


From ucla-cs!usc!zaphod.mps.ohio-state.edu!think!redsox!campbell Sun Jun  3 17:57:53 PDT 1990
Article: 23312 of comp.windows.x
Path: ucla-cs!usc!zaphod.mps.ohio-state.edu!think!redsox!campbell
From: campbell@redsox.bsw.com (Larry Campbell)
Newsgroups: comp.windows.x
Subject: tgif makes mwm curl up in a loop
Message-ID: <1577@redsox.bsw.com>
Date: 3 Jun 90 19:48:32 GMT
Reply-To: campbell@redsox.bsw.com (Larry Campbell)
Distribution: usa
Organization: The Boston Software Works, Inc.
Lines: 16
Status: O

Apologies if this has already been hashed over here -- I just recently
started reading this group again.

On my system (details below), tgif builds OK, starts up and draws its
windows OK, but if I activate a popup menu, mwm curls up in a loop eating
CPU time and ignoring input events.  The server is still alive -- tgif still
"works", as far as I can tell -- but I can't talk to any other applications
and have to gun down mwm to do anything other than using tgif.

Has anyone else already encountered (and, hopefully, solved) this problem?

[System: 386/ix 2.0.2 running ISC X11R3 1.1 and Motif 1.0]
-- 
Larry Campbell                          The Boston Software Works, Inc.
campbell@redsox.bsw.com                 120 Fulton Street
wjh12!redsox!campbell                   Boston, MA 02109


From ucla-cs!usc!cs.utexas.edu!uunet!mcsun!ukc!icdoc!sot-ecs!Sebastian Tue Jun  5 00:00:40 PDT 1990
Article: 23343 of comp.windows.x
Path: ucla-cs!usc!cs.utexas.edu!uunet!mcsun!ukc!icdoc!sot-ecs!Sebastian
From: spqr@ecs.soton.ac.uk (Sebastian Rahtz)
Newsgroups: comp.windows.x
Subject: bugs in tgif
Message-ID: <5754.9006040954@cameron.ecs.soton.ac.uk>
Date: 4 Jun 90 09:54:10 GMT
Sender: spqr@ecs.soton.ac.uk
Lines: 13
Status: O

I just installed `tgif' version 1.5 and found it an attractive
program. However, for the benefit of others trying to make it work, I
should point out that there are two flaws in the printing part of it:
 + Encapsulated PostScript rarely has the %%BoundingBox _after_ a
   prolog of declarations. My dvi to PostScript converter (rightly, I
   think) threw up on the file until I moved the %%BB to the top (see
   file.c) 
 + the tgif2ps program manages to delete the %! line whose validity it
   is checking! I just commented out the check.... the absence of it
   makes your average printer vomit some rather wordy PostScript code
   in Courier.

Sebastian Rahtz


From ucla-cs!william@oahu.cs.ucla.edu Tue Jun  5 13:21:53 PDT 1990
Article: 23370 of comp.windows.x
Path: ucla-cs!william@oahu.cs.ucla.edu
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: Tgif-1.6 (Xlib based 2-D drawing tool) is available on expo ...
Keywords: draw, tool, postscript, latex, hierarchical, x11, xlib, wysiwyg
Message-ID: <35975@shemp.CS.UCLA.EDU>
Date: 5 Jun 90 20:19:21 GMT
Sender: news@CS.UCLA.EDU
Followup-To: william@cs.ucla.edu
Organization: UCLA Computer Science Department
Lines: 503
Status: RO

I've just put tgif-1.6 in the `contrib' directory of `expo.lcs.ucla.edu'
and the `pub' directory of `rye.cs.ucla.edu'.  Here's a short list of
added features/bug fixes.

1) Fix bugs reported by Sebastian Rahtz regarding the position of the
   PostScript bounding box and %!.
2) Add XDefault "Tgif*PrintCommand" to override lpr.
3) Add -DPSFILE_MOD in Imakefile to chmod the .ps file.
4) Update prtgif to use pipes instead of files.

Following is a patch file to bring tgif from release 1.5 to 1.6.
-------------------------------> cut here <-----------------------------------
-- Bill Cheng // UCLA Computer Science Department // (213) 206-7135
   3277 Boelter Hall // Los Angeles, California 90024 // USA
   william@CS.UCLA.EDU      ...!{uunet|ucbvax}!cs.ucla.edu!william


From ucla-cs!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!quanta.eng.ohio-state.edu!kcgl1.eng.ohio-state.edu!DAVISM Wed Jun  6 10:39:09 PDT 1990
Article: 23404 of comp.windows.x
Path: ucla-cs!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!quanta.eng.ohio-state.edu!kcgl1.eng.ohio-state.edu!DAVISM
From: DAVISM@kcgl1.eng.ohio-state.edu (Michael T. Davis)
Newsgroups: comp.windows.x
Subject: RE: Two simple user interfaces wanted (Summary)
Message-ID: <5076@quanta.eng.ohio-state.edu>
Date: 6 Jun 90 16:21:32 GMT
References: <5073@quanta.eng.ohio-state.edu>
Sender: news@quanta.eng.ohio-state.edu
Organization: Ohio State University
Lines: 41
Status: O


In article <5073@quanta.eng.ohio-state.edu>, I wrote:

>
>	I am modifying a program to be more user friendly under X (actually
>DECwindows 2.0 under VMS 5.3-1, but since I'm writing with "pure" Xlib, it
>should be pretty much the same).  Before I go off and possibly re-invent the
>wheel, I was wondering if anyone had a couple of Xlib-based routines to perform
>the following:
>
>	1) Given/passed a character string, display the string and two
>	   push-buttons labelled "Yes" and "No"; for example:
>
>[figure deleted]
>
>	2) Given/passed a character string, display the string, a text
>	   entry field and two push-buttons labelled "OK" and "Cancel";
>	   for example:
>
>[rest deleted]

	A few responses suggested that I use a toolkit to perform these
actions.  I'd rather avoid the extra performance overhead, minimal though it
may be, of a toolkit, since performance is an issue.

	Bill Cheng (william@cs.ucla.edu) suggested I look at the code for
tgif 1.6, which was recently announced here.  He pointed the way to the
routines YesNoCancel() in button.c and Dialog() in dialog.c.  I would suggest
taking a gander at these for code examples; they seem to be quite complete.

						    Thanks for the interest,
							     Mike

    ________________________________________________________________________
   |   InterNet> davism@{kcgl1.eng|rcgl1.eng|osu-20.ircc}.ohio-state.edu    |
   |                                  -or-                                  |
   |                       davis-m@eng.ohio-state.edu                       |
   |                         CompuServe> 73667,541                          |
   |************************************************************************|
   |                      These thoughts, they be mine                      |
    ------------------------------------------------------------------------


From ucla-cs!usc!apple!snorkelwacker!bloom-beacon!SHAMASH.MCRCIM.MCGILL.EDU!mouse Sun Jun 10 17:54:11 PDT 1990
Article: 23651 of comp.windows.x
Path: ucla-cs!usc!apple!snorkelwacker!bloom-beacon!SHAMASH.MCRCIM.MCGILL.EDU!mouse
From: mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  Chinese User Interface in X
Message-ID: <9006100105.AA16716@shamash.McRCIM.McGill.EDU>
Date: 10 Jun 90 01:05:06 GMT
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 52
Status: O

> I would like to know from those of you with infinite knowledge and
> experience with X and access to R4...

Hm, well, perhaps I'll do instead....

> 1) Does X11R4 have Chinese fonts? Please note that this is NOT the
>    same as the Japanese Katakana characters.

R4 has a Japanese font which includes hiragana, katakana, and kanji.
Obviously Chinese characters are not the same as Japanese kana, but
would a kanji font do, or did you mean to write "kanji" where you wrote
"katakana"?

> 2) If the fonts are not part of the standard distribution, are they
>    avaiable anywhere else?

The font of which I speak is on the R4 tape, in
mit/fonts/bdf/misc/k14.bdf.

> 3) Is there any support anywhere for the input of Chinese characters
>    under X?

There is kterm, a terminal emulator designed for use with Japanese.
Obviously, it has to have some way of typing kanji on a keyboard
labeled with a basically Latin alphabet.  I don't know details, though
from what I've seen written about such systems I would expect the user
to type romaji and then the system will effectively generate a menu of
the likely kanji, with some sort of escape for entering the unlikely
ones.  I don't know enough about the various transcription methods of
Chinese into alphabetic writing systems, but presumably something
similar could be done for Chinese, given a well-defined romanization.

I'm not certain where to get kterm; presumably it can be gotten from
expo with ftp, though I must admit I haven't tried doing so.

> 4) Has anyone had any experience with the load on the server when
>    using languages with large character sets (such as Chinese or
>    Japanese)?

Not me, though I would like to get kterm working here soon.

> Please reply by mail since I'll be back on the road shortly.  Mail
> will be forwared to me, but news won't.

Unfortunately you didn't sign with an address.  I'll try to mail to an
address derived from the header, but I'm also posting in the hope that
it will do some good.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu


From ucla-cs!elroy.jpl.nasa.gov!ames!ptolemy!eos!shelby!med!hanauma!rick Sun Jun 10 17:55:29 PDT 1990
Article: 23655 of comp.windows.x
Path: ucla-cs!elroy.jpl.nasa.gov!ames!ptolemy!eos!shelby!med!hanauma!rick
From: rick@hanauma.stanford.edu (Richard Ottolini)
Newsgroups: comp.windows.x
Subject: Re:  Chinese User Interface in X
Message-ID: <1478@med.Stanford.EDU>
Date: 10 Jun 90 16:50:25 GMT
References: <9006100105.AA16716@shamash.McRCIM.McGill.EDU>
Sender: news@med.stanford.edu (USENET News System)
Organization: Stanford University, Department of Geophysics
Lines: 12
Status: O

>> 1) Does X11R4 have Chinese fonts? Please note that this is NOT the
>>    same as the Japanese Katakana characters.

I thought X11R4 had several GuoBiao fonts (mainland ordering, simplified).
There were no indexes or client software.
Apple computer uploaded a one syllable pinyin index to soc.culture.china
a few months ago.   A bdf font and pinyin index are in anonymous ftp 36.51.0.16.

Pinyin indexes are less satisfying to native users of Chinese than shape-based
indexes.  GuoBiao fonts are less satisfying to non-mainland Chinese.
Most of the computerized activity seems to be in the IBM PC world rather
than UNIX.


From ucla-cs!tek Mon Jun 11 20:40:09 PDT 1990
Article: 23689 of comp.windows.x
Path: ucla-cs!tek
From: tek@penzance.cs.ucla.edu
Newsgroups: comp.windows.x
Subject: resources
Message-ID: <36159@shemp.CS.UCLA.EDU>
Date: 11 Jun 90 22:14:24 GMT
Sender: news@CS.UCLA.EDU
Reply-To: tek@CS.UCLA.EDU (Ted Kim (Random Dude))
Organization: UCLA
Lines: 94
Status: O

There seem to be so many ways to set your resources. I have tried to
enumerate all of them here. Please tell me if I have forgotten any.

	Toolkit Programs
	----------------
In order of descending precedence:

1. Command Line
  standard arguments include:
    A. command switches (-display, -fg, -foreground, +rv, etc.)
    B. resource manager directives (-name, -xrm)
    C. natural lanaguage directive (-xnllangauge)

2. User Environment File
  use the first source found from:
    A. file named by XENVIRONMENT environment variable
    B. $HOST/.Xdefaults-<host> file

3. Server/User Preference Resources 
  use the first source found from:
    A. RESOURCE_MANAGER property on root window (screen 0)
    B. $HOME/.Xdefaults file

4. Application User Resources 
  use the first "class" file found by XtResolvePathname using the:
    A. search path defined by the XUSERFILESEARCHPATH environment variable
    B. search path based on the XAPPLRESDIR environment variable: 
      $XAPPLRESDIR/%L/%C:$XAPPLRESDIR/%l/%C:$XAPPLRESDIR/%C:$HOME/%C
    C. default search path:
      $HOME/%L/%C:$HOME/%l/%C:$HOME/%C

5. Application Class Resources 
  use the first source found from:
    A. the "app-defaults" type file found by XtResolvePathname using the:
        1) search path defined by the XFILESEARCHPATH environment variable 
	2) default search path:
	  /usr/lib/X11/%L/app-defaults/%C:/usr/lib/X11/%l/app-defaults/%C:\
	  /usr/lib/X11/app-defaults/%C
    B. fallback resources defined by XtAppSetFallbackResources

In the specifications above:	
  %C = class name
  %L = the whole language specification
  %l = just the language part (no territory or codespec) 

	Special Processing
	------------------
1. Display (using XtOpenDisplay)
  use the first source found from:
    A. Program Provided Name
    B. -display Command Arg
    C. DISPLAY environment variable

2. Name (using XtOpenDisplay)
  use the first source found from:
    A. -name Command Arg
    B. Program Provided Name
    C. RESOURCE_NAME environment variable 
    D. basename of argv[0]
    E. default name of "main"

3. Natural Language
  use the first source found from:
    A. Command Line
    B. Server/User Preference Resources
    C. LANG environment variable
  (notice that User Environment File is not used, and
   Application User and Class Resources depend on langauge)


	Xlib Programs
	-------------
Xlib based programs can use:

1. XrmParseCommand
  to parse command line 

2. XGetDefaults 
  uses two sources:
    A. User Environment File
    B. Server/User Preference Defaults
  with instance <program>.<option> and class "Program.Name"

3. Xrm Routines
  to do custom resource lookup

4. Program Provided Defaults


-ted
Ted Kim                           
UCLA Computer Science Department  Internet: tek@penzance.cs.ucla.edu
3804C Boelter Hall                UUCP:    ...!{uunet|ucbvax}!cs.ucla.edu!tek
Los Angeles, CA 90024		  Phone:   (213) 206-8696


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!kit Wed Jun 13 09:02:14 PDT 1990
Article: 23746 of comp.windows.x
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!kit
From: kit@EXPO.LCS.MIT.EDU (Chris D. Peterson)
Newsgroups: comp.windows.x
Subject: Re: Athena Widget Set
Message-ID: <9006122017.AA26936@expo.lcs.mit.edu>
Date: 12 Jun 90 20:17:27 GMT
References: <9006121942.AA19570@Todi.ORC.Olivetti.Com>
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 43
Status: O


> text widgets stop accepting 
> any inputs. I don't see any connection between the two. Can you help me?

I have seen this behavior in R3, it seemed to be an interaction between Xt and
the window manager's focus management stuff.  I believe that this was fixed in
R4, however.  If you are running R4 and still having the problem, send me a
SHORT example program, and I will take a look.

> Also, I would like to use a toggle widget. But it seems that Chris Peterson has
> mentioned in the code for Toggle.c that...

This was necessary to allow the Toggle to override the Command's set() action. 
The hack I had to add is still necessary in R4, but the Toggle does work just
fine.  It should only affect you if you are subclassing your own widgets.

> I was told that toplevel shell can have only child, but it seems to me that
> the popup shell is also a child of toplevel. Am I wrong?

There are two types of Children in Xt, Popup children and Normal children. 
Popup children are things like menus and dialog boxes.  The shell can have only
1 normal child, but any number of popup children.  Popup children are not
managed by the geometry manager of their parent, and are not sub-windows of
their parent's window.  

> Suppose I have a cmdBtn which calls XtPopup ,to popup a dialog box with done and
> cancel buttons,in it's callback function. In the DialogDone or DialogCancel 
> function, is it possible to find out the name of that cmdBtn?

The callback functions return the widget that caused them to be invoked (in this
case the command buttons)  You can retreive the name of the Command button by
using the XtName() function on the widget argument to the callback routine.

> Thanks a LOT. Manu Das

You're welcome.

						Chris D. Peterson     
						MIT X Consortium 

Net:	 kit@expo.lcs.mit.edu
Phone:   (617) 253 - 9608	
Address: MIT - Room NE43-213


From ucla-cs!usc!snorkelwacker!bloom-beacon!TWNMOE10.BITNET!IIIG014 Wed Jun 13 21:12:46 PDT 1990
Article: 23789 of comp.windows.x
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!TWNMOE10.BITNET!IIIG014
From: IIIG014@TWNMOE10.BITNET (Chih-Chung Ko)
Newsgroups: comp.windows.x
Subject: Re: Chinese User Interface in X
Message-ID: <9006131559.AA03590@expo.lcs.mit.edu>
Date: 14 Jun 90 05:46:24 GMT
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 19
Status: O


> 2) If the fonts are not part of the standard .....
> 3) Is there any support anywhere for the input of Chinese char .....

As far as I know, there are three implementations that support
Chinese fonts and character input in Taiwan now.
The first is the Chinese X Window System from SEED Project of III,
the second comes from SUN and the third comes from HP.

> 4) Has anyone had any experience with the load on the server when using
>    language with large character sets .....

We need more memory to load Chinese character font, that's right.


Chih-Chung Ko
System Engineering Division, Institute for Information
3rd Fl 293-3 Fu-Hsing S Rd Sec 2 Taipei Taiwan R.O.C.
E-mail: iiig014%twnmoe10.bitnet@mitvma.mit.edu


From ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws Fri Jun 15 10:08:30 PDT 1990
Article: 23849 of comp.windows.x
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: Foreign Language Character Sets & Keyboard Mappings
Message-ID: <9006142303.AA09171@expire.lcs.mit.edu>
Date: 14 Jun 90 23:03:14 GMT
References: <9006142225.AA01077@hunter.crim.ca>
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 5
Status: O

Most of the languages you cite are covered by the ISO 8859 family of
character sets, as well as the ISO 6937 family.  You will find a table
which summarizes the use of Latin alphabetic characters in 41 different
languages in ISO 6937/2-1983.  Sorry, I don't know about documents
giving keyboard layouts.


From ucla-cs!william@oahu.cs.ucla.edu Fri Jun 15 20:31:17 PDT 1990
Article: 23872 of comp.windows.x
Path: ucla-cs!william@oahu.cs.ucla.edu
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: Tgif-1.7 (Xlib based 2-D drawing tool) is available on expo ...
Keywords: draw, tool, postscript, latex, hierarchical, x11, xlib, wysiwyg
Message-ID: <36273@shemp.CS.UCLA.EDU>
Date: 16 Jun 90 03:23:08 GMT
Sender: news@CS.UCLA.EDU
Followup-To: william@cs.ucla.edu
Organization: UCLA Computer Science Department
Lines: 536
Status: RO

I've just put tgif-1.7 in the `contrib' directory of `expo.lcs.ucla.edu'
and the `pub' directory of `rye.cs.ucla.edu'.  Here's a short list of
added features/bug fixes.

1) Fix bug related to displaying current font in the panel window when
   text is rotated on a black and white screen.
2) Make the version number show up in the top of the tool.
3) Fix bug related to the sqrt() DOMAIN error.

Following is a patch file to bring tgif from release 1.6 to 1.7.
-------------------------------> cut here <-----------------------------------
-- Bill Cheng // UCLA Computer Science Department // (213) 206-7135
   3277 Boelter Hall // Los Angeles, California 90024 // USA
   william@CS.UCLA.EDU      ...!{uunet|ucbvax}!cs.ucla.edu!william


From ucla-cs!william@oahu.cs.ucla.edu Sat Jun 16 16:09:07 PDT 1990
Article: 23886 of comp.windows.x
Path: ucla-cs!william@oahu.cs.ucla.edu
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: Tgif-1.8 (Xlib based 2-D drawing tool) is available on expo ...
Keywords: draw, tool, postscript, latex, hierarchical, x11, xlib, wysiwyg
Message-ID: <36286@shemp.CS.UCLA.EDU>
Date: 16 Jun 90 22:54:42 GMT
Sender: news@CS.UCLA.EDU
Followup-To: william@cs.ucla.edu
Organization: UCLA Computer Science Department
Lines: 146
Status: RO

I've just put tgif-1.8 in the `contrib' directory of `expo.lcs.ucla.edu'
and the `pub' directory of `rye.cs.ucla.edu'.  The only change from tgif-1.7
is that I retracted the changes in "select.c".  It runs funny when the
load of the machine is high.

Following is a patch file to bring tgif from release 1.7 to 1.8.
-------------------------------> cut here <-----------------------------------
-- Bill Cheng // UCLA Computer Science Department // (213) 206-7135
   3277 Boelter Hall // Los Angeles, California 90024 // USA
   william@CS.UCLA.EDU      ...!{uunet|ucbvax}!cs.ucla.edu!william


From ucla-cs!usc!samsung!umich!srvr1!caen.engin.umich.edu!grue Tue Jun 26 16:26:57 PDT 1990
Article: 24052 of comp.windows.x
Path: ucla-cs!usc!samsung!umich!srvr1!caen.engin.umich.edu!grue
From: grue@caen.engin.umich.edu (Paul Howell)
Newsgroups: comp.windows.x
Subject: X server for pmax running ultrix 3.1d
Keywords: ultrix
Message-ID: <1990Jun21.221131.20309@caen.engin.umich.edu>
Date: 21 Jun 90 22:11:31 GMT
Sender: news@caen.engin.umich.edu (CAEN Netnews)
Reply-To: grue@caen.engin.umich.edu (Paul Howell)
Organization: University of Michigan Engineering, Ann Arbor
Lines: 15
Status: O


DEC has moved pmax specific files from /usr/include/machine
to /usr/sys/io/tc.

Is it OK to just edit the server sources to reflect this change or
is there a more formal procedure for this sort of thing.

Thanks.

---
Paul Howell
grue@caen.engin.umich.edu

Computer Aided Engineering Network
University of Michigan, Ann Arbor


From ucla-cs!usc!zaphod.mps.ohio-state.edu!uwm.edu!uwvax!appenzell.cs.wisc.edu!tim Tue Jun 26 16:44:44 PDT 1990
Article: 24156 of comp.windows.x
Path: ucla-cs!usc!zaphod.mps.ohio-state.edu!uwm.edu!uwvax!appenzell.cs.wisc.edu!tim
From: tim@appenzell.cs.wisc.edu (Tim Theisen)
Newsgroups: comp.windows.x
Subject: New xgremlin on expo.lcs.mit.edu
Message-ID: <10656@spool.cs.wisc.edu>
Date: 25 Jun 90 13:39:01 GMT
Sender: news@spool.cs.wisc.edu
Organization: U of Wisconsin CS Dept
Lines: 21
Status: O

A new copy xgremlin has been placed on expo.lcs.mit.edu.
Changes include:

  - emacs style command line editing.
  - A new change text command which allows you to edit text strings
    in the picture, rather than retyping the whole thing.

For those of you that don't know, here is a very brief description of
xgremlin.

     Xgremlin is an interactive picture editor for producing line
     drawings.  It is a version of gremlin which displays a rough
     estimate of the current picture using the X window package.
     Output produced by the Xgremlin program is converted by
     grn(1) to produce roff commands.

--
Tim Theisen             Department of Computer Sciences
tim@cs.wisc.edu         University of Wisconsin-Madison
uwvax!tim               1210 West Dayton Street
(608)262-0438           Madison, WI   53706


From ucla-cs!usc!samsung!uunet!sco!mikep Tue Jun 26 16:45:20 PDT 1990
Article: 24158 of comp.windows.x
Path: ucla-cs!usc!samsung!uunet!sco!mikep
From: mikep@sco.COM (Mike Patnode)
Newsgroups: comp.windows.x
Subject: xfix 2.0 patches (patchlevel 7)
Message-ID: <6786@scolex.sco.COM>
Date: 24 Jun 90 20:10:22 GMT
Sender: news@sco.COM
Reply-To: mikep@sco.COM (Mike Patnode)
Distribution: na
Organization: The Santa Cruz Operation, Inc.
Lines: 113
Status: O



Here are some unofficial xfig 2.0 patches for SYSV.  The only real
problem was the program trying to get a char * from sprintf() which
returns an int on most SYSV machines.  Strangly, this was only a problem
in one file.  The rest were well behaved.  This fix is obviously just a
hack.  The code should be probably be changed.

Also there was a misplaced #endif.

BTW: My compiler choked on the multiline constant strings in f2ps.c, but
I imagine this isn't a problem for most other people.  If somebody wants
the diffs I'll send the along.  All I did was tack a \n on each line and
join them.

Oh yeah, one more thing: There was a file called @fig/roundboxes2.fig
in the 2.0 distribution which was 15 characters long.  I never unpacked
it and so far I haven't missed it.  The filename needs to be change.

Enjoy.


Mike Patnode					The Santa Cruz Operation 
SCO Software Engineer				400 Encinal Street
{ucscc,uunet}!sco!mikep	 mikep@sco.COM  	P.O. Box 1900
(408) 458-1422                                  Santa Cruz, CA 95061


*** Imakefile-	Fri Jun 22 19:42:55 1990
--- Imakefile	Fri Jun 22 19:42:33 1990
***************
*** 17,23 ****
  		msgsw.c panel.c popup.c print.c printfonts.c psbits.c\
  		psfonts.c puterr.c read.c read1_3.c redisplay.c\
  		remove.c rotate.c ruler.c save.c scale.c search.c\
! 		spline.c text.c trans.c turn.c undo.c util.c xtra.c 
  
  XFIGOBJ =	addpt.o arc.o arcbox.o arrow.o autoarrow.o bitmap.o\
  		blink.o bound.o box.o break.o canvas.o change.o\
--- 17,23 ----
  		msgsw.c panel.c popup.c print.c printfonts.c psbits.c\
  		psfonts.c puterr.c read.c read1_3.c redisplay.c\
  		remove.c rotate.c ruler.c save.c scale.c search.c\
! 		spline.c text.c trans.c turn.c undo.c util.c xtra.c bsdsprintf.c
  
  XFIGOBJ =	addpt.o arc.o arcbox.o arrow.o autoarrow.o bitmap.o\
  		blink.o bound.o box.o break.o canvas.o change.o\
***************
*** 29,35 ****
  		popup.o print.o printfonts.o psbits.o psfonts.o\
  		puterr.o read.o read1_3.o redisplay.o remove.o\
  		rotate.o ruler.o save.o scale.o search.o spline.o\
! 		text.o trans.o turn.o undo.o util.o xtra.o 
  
  F2PSRC =        arrow.c f2p.c free.c read.c read1_3.c troff_fonts.c psfonts.c 
  F2POBJ =        arrow.o f2p.o free.o read.o read1_3.o troff_fonts.o psfonts.o 
--- 29,35 ----
  		popup.o print.o printfonts.o psbits.o psfonts.o\
  		puterr.o read.o read1_3.o redisplay.o remove.o\
  		rotate.o ruler.o save.o scale.o search.o spline.o\
! 		text.o trans.o turn.o undo.o util.o xtra.o bsdsprintf.o
  
  F2PSRC =        arrow.c f2p.c free.c read.c read1_3.c troff_fonts.c psfonts.c 
  F2POBJ =        arrow.o f2p.o free.o read.o read1_3.o troff_fonts.o psfonts.o 
*** dir.c-	Fri Jun 22 19:39:14 1990
--- dir.c	Fri Jun 22 19:39:25 1990
***************
*** 50,57 ****
  	if (getcwd(direct,1024) == NULL)        /* get curent working dir */
  #else
  	extern char *getwd();
- #endif
  	if (getwd(direct) == NULL)	/* get curent working dir */
  		{
  		put_msg("%s", direct);	/* err msg is in directory */
  		*direct = '\0';
--- 50,57 ----
  	if (getcwd(direct,1024) == NULL)        /* get curent working dir */
  #else
  	extern char *getwd();
  	if (getwd(direct) == NULL)	/* get curent working dir */
+ #endif
  		{
  		put_msg("%s", direct);	/* err msg is in directory */
  		*direct = '\0';
*** bsdsprintf.c-	Sun Jun 24 12:19:06 1990
--- bsdsprintf.c	Fri Jun 22 18:05:13 1990
***************
*** 0 ****
--- 1,10 ----
+ /* Sure it's a hack, but it works */
+ #undef sprintf
+ 
+ char * bsdsprintf(s, f, a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10)
+     char *s, *f;
+     int  a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10;
+     {
+     sprintf(s, f, a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10);
+     return s;
+     }
*** patchlevel.h-       Sun Jun 24 12:23:22 1990
--- patchlevel.h        Sun Jun 24 12:23:55 1990
***************
*** 1,1 ****
! #define PATCHLEVEL 7
--- 1,1 ----
! #define PATCHLEVEL 7.1

-- 
Mike Patnode					The Santa Cruz Operation 
SCO Software Engineer				400 Encinal Street
{ucscc,uunet}!sco!mikep	 mikep@sco.COM  	P.O. Box 1900
(408) 458-1422                                  Santa Cruz, CA 95061


From ucla-cs!william@oahu.cs.ucla.edu Tue Jun 26 16:46:01 PDT 1990
Article: 24268 of comp.windows.x
Path: ucla-cs!william@oahu.cs.ucla.edu
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: Tgif-1.9 (Xlib based 2-D drawing tool) is available on expo ...
Keywords: draw, tool, postscript, latex, hierarchical, x11, xlib, wysiwyg
Message-ID: <36533@shemp.CS.UCLA.EDU>
Date: 26 Jun 90 23:03:16 GMT
Sender: news@CS.UCLA.EDU
Organization: UCLA Computer Science Department
Lines: 1317
Status: RO

I've just put tgif-1.9 in the following places for anonymous ftp:

	expo.lcs.mit.edu	contrib/tgif-1.9.tar.Z
	rye.cs.ucla.edu		pub/tgif-1.9.tar.Z

Here's a short list of added features/bug fixes.

1) Show editing status.
-------------------------------> cut here <-----------------------------------
-- Bill Cheng // UCLA Computer Science Department // (213) 206-7135
   3277 Boelter Hall // Los Angeles, California 90024 // USA
   william@CS.UCLA.EDU      ...!{uunet|ucbvax}!cs.ucla.edu!william


From ucla-cs!usc!ucsd!ucbvax!bloom-beacon!EXPO.LCS.MIT.EDU!rws Tue Jun 26 16:47:35 PDT 1990
Article: 24209 of comp.windows.x
Path: ucla-cs!usc!ucsd!ucbvax!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: X11R4 public fix #12 now available on expo
Message-ID: <9006251805.AA19965@expire.lcs.mit.edu>
Date: 25 Jun 90 18:05:36 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 35
Status: O

Patches for a variety of problems in Xt are now available via anonymous ftp
or the xstuff mail archive server on expo.lcs.mit.edu (18.30.0.212).  This
patch fixes the following problems:
	call XtUninstallTranslations with a real widget in SetValues
	hack around problem with children destroying ancestors
	make XtIsObject return True when objects really are
	make '$' be abbreviation for Meta, per spec, not Alt, in translations
	unregister widgets with MappingNotify translations when destroyed
	fix shared GC support for multiple screens w/multiple depths
	bugs with type conversion on constraint resources in XtVaSetValues
	incorrect test being used for calling constraint methods
	fix some ANSI C problems

Fixes are available via anonymous ftp to expo.lcs.mit.edu (18.30.0.212), in
the directory /pub/R4/fixes/, in files with prefix "fix-".  The latest fix
is "fix-12".  Fixes get put on expo in batches at intervals only.  Fixes
usually propagate to other distribution sites as well, so it may pay to
check at a nearer site first.

For those without ftp access, individual fixes can be obtained by mail by
sending a message to xstuff@expo.lcs.mit.edu.  In the usual case, the
message should have a subject line and no body, or a single-line body and
no subject, in either case the line looking like:
	send fixes 12
(e.g. to get fix 12).  To get a summary of fixes, make the line:
	index fixes
If you need help, make the line:
	help
Some mailers produce mail headers that are unusable for extracting return
addresses.  If you use such a mailer, you won't get any response.  If you
happen to know an explicit path, you can include a line like
	path foo%bar.bitnet@mitvma.mit.edu
or
	path zot!gzork!me@uunet.uu.net
in the body of your message, and the daemon will use it.


From ucla-cs!usc!samsung!xylogics!bu.edu!ics!xug Wed Jul  4 20:18:17 PDT 1990
Article: 24414 of comp.windows.x
Path: ucla-cs!usc!samsung!xylogics!bu.edu!ics!xug
From: xug@ics.com (X User's Group)
Newsgroups: comp.windows.x,ba.windows.x,comp.windows.misc
Subject: Frequently Asked Questions about X with Answers [long monthly posting]
Message-ID: <1990Jun29.162846.693@ics.com>
Date: 29 Jun 90 16:28:46 GMT
Expires: Sun, 01 Aug 90 00:00:00 GMT
Organization: the World
Lines: 1469
Xref: ucla-cs comp.windows.x:24414 comp.windows.misc:1658
Status: O

[Last changed: 27 Jun 90]

This article contains the answers to some Frequently Asked Questions (FAQ) 
often seen in comp.windows.x. It is posted to help reduce volume in this 
newsgroup and to provide hard-to-find information of general interest.
		Please redistribute this article!

This article includes answers to the following questions. Ones marked with
a + indicate questions new to this issue; those with changes of content since
the last issue are marked by *:

0) Where can I obtain X source?
1)* Where can I obtain X11R4?
2)* Where can I obtain patches to X11R4?
3) Where can I obtain Motif?
4) Where can I obtain toolkits implementing Open Look?
5)* Where can I obtain other X sources?
6) What is the xstuff mail-archive?
7) Where can I find books/articles on X that are good for beginners?
8) What courses on X are available?
9) Is there a skeleton X program available?
10) What are these common abbreviations?
11) What is XUG?
12) What is EXUG?
13) What is the X Consortium and how do I join?
14) What is xpert?
15)* What conferences on X are coming up?
16)* What is the current state of the world in X terminals?
17)* How can I get an X server on a PC?
18) What terminal emulators other than xterm are available?
19) How can I get an X server on a Macintosh running MacOS?
20) Where can I obtain an X-based editor or word-processor?
21) Where can I obtain an X-based paint/draw program?
22)* Where can I obtain an X-based spreadsheet?
23) Where can I get a PostScript previewer for X?
24) Where can I get a troff previewer for X?
25)+ How can I design my own font?
26)+ What is PEX?
27) How do I convert Mac/TIFF/GIF/Sun/PICT/Face/img/FAX images to X?
28) How do I use another window manager with DEC's session manager?
29) How do I build X with gcc?
30) What are these funny problems compiling X11R3 on the Sun4?
31) What are these problems installing R4 on the Sun running SunOS 4?
32)* Where can I get a fast X server for a workstation?
33)*  How can I change the titlebar of my xterm window?
34) Why doesn't anything appear when I run this simple program?
35) What is the difference between a Screen and a screen?
36)+ How do I determine the name of an existing widget?
37)* Why do I get a BadDrawable error drawing to XtWindow(widget)?
38) Can XGetWindowAttributes get a window's background pixel/pixmap?
39) Why does the pixmap I copy to the screen show up as garbage? 
40)* Why doesn't my program get the keystrokes I select for?
41) How can my application iconify itself?
42) How do I check whether a window ID is valid?
43)+  Can I have two applications draw to the same window?
44) Why can't I set the backgroundPixmap resource in my defaults file?
45) Why does the R3 xterm, et al, fail against the R4 server?
46)+  Does Motif work with X11R4?
47)* Where can I obtain alternate language bindings to X?

If you have suggestions or corrections for any of these answers or any 
additional information, please send them directly to xug@expo.lcs.mit.edu;
the information will be included in the next revision (or possibly the one 
after that; thanks for the many suggestions which haven't been incorporated 
yet).  The answers in this iteration are acknowledged to be partial and to 
lean more towards products than to programming.

This posting is intended to be distributed at approximately the beginning of 
each month.

The information contained herein has been gathered from a variety of sources. In
many cases attribution has been lost; if you would like to claim responsibility
for a particular item, please let us know. 

Conventions used below: telephone numbers tend to be Bell-system unless 
otherwise noted; prices on items are not included.

--------------------------------------------------
Subject: 0) Where can I obtain X source?

	Intelligent Software Products, Inc., (516-766-2867) ships X11R3
[formats are unknown]. 

	Integrated Computer Solutions, Inc., (617-547-0510) ships X11R3 on 
half-inch and quarter-inch formats. 

	The Free Software Foundation (617-876-3296) sells X11R3 on half-inch 
tapes and on QIC-24 cartridges.  

	Automata Design Associates (215-646-4894) sells X11R3 source on 5.25" 
high-density floppies and QIC-24 quarter-inch cartridge tapes. 

	European sites can obtain a free distribution from Jamie Watson, who 
may be reached at chx400!pan!jw or cernvax!pan!jw. [1/90]

	IXI Limited (+44 223 462 131) is selling X11R3 source on quarter-inch 
cartridge formats and on 5.25" and 3.5" floppy, with other formats available on
request. [IXI, 2/90]

[Note that some distributions are media-only and do not include docs.]
[The MIT Software Center no longer distributes X11R3.]
	(See below for FTP sites.)

--------------------------------------------------
Subject: 1)* Where can I obtain X11R4?

	The MIT Software Center is shipping X11R4 on four 1600bpi half-inch 
tapes. Call the X Hotline at (617) 258-8330 for prerecorded ordering 
information and a good product description.

	Integrated Computer Solutions, Inc., ships X11R4 on half-inch, 
quarter-inch, and TK50 formats. Call 617-547-0510 for ordering information.

	The Free Software Foundation (617-876-3296) sells X11R4 on half-inch 
tapes and on QIC-24 cartridges.  

	Yaser Doleh (doleh@math-cs.kent.EDU; P.O. Box 1301, Kent, OH 44240) is
making X11R4 available on HP format tapes, 16 track, and Sun cartridges. [2/90]

	European sites can obtain a free X11R4 distribution from Jamie Watson,
who may be reached at chx400!pan!jw or cernvax!pan!jw. [1/90]

	IXI Limited (+44 223 462 131) is selling X11R4 source on quarter-inch 
cartridge formats and on 5.25" and 3.5" floppy, with other formats available on
request. [IXI, 2/90]

	Virtual Technologies (703-430-9247) provides the entire X11R4 
compressed source release on a single QIC-24 quarter-inch cartridge and also on
1.2meg or 1.44 meg floppies upon request. [Conor Cahill (cpcahil@virtech.uu.net)
2/90]

[Note that some distributions are media-only and do not include docs.]

	Canadian sites can send email to xhacks@csri.toronto.edu to arrange for
the exchange of tapes; the offer is subject to "time availability".
[information from Mark Moraes (moraes@csri.toronto.edu), 2/90]

	UK sites can obtain R4 through the UKUUG Software Distribution Service,
from the Department of Computing, Imperial College, London, in several tape 
formats.  You may also obtain the source via Janet (and therefore PSS) using 
Niftp (Host: uk.ac.ic.doc.src Name: guest Password: your_email_address). 
Queries should be directed to Lee McLoughlin, 01-589-5111#5037, or to 
ukuug-soft@uk.ac.ic.doc. Also offered are copies of comp.sources.x logs.

	X11R4 is ftp-able from expo.lcs.mit.edu; these sites are preferable, 
though, and are more direct:

                        Machine                  Internet      FTP
    Location            Name                     Address       Directory
    --------            -------                  --------      -------------
(1) West USA            gatekeeper.dec.com       16.1.0.2      pub/X11/R4
    Central USA         mordred.cs.purdue.edu    128.10.2.2    pub/X11/R4
(2) Central USA         giza.cis.ohio-state.edu  128.146.8.61  pub/X.V11R4
    Southeast USA       uunet.uu.net             192.48.96.2   X/R4
(3) Northeast USA       crl.dec.com              192.58.206.2  pub/X11/R4
(4) UK Janet            src.doc.ic.ac.uk         129.31.81.36  X.V11R4
    UK niftp            uk.ac.ic.doc.src                       <XV11R4>
(5) Australia           munnari.oz.au            128.250.1.21  X.V11/R4

The giza.cis.ohio-state.edu site, in particular, is known to have much of the
contrib stuff that can be found on expo. 

The release is available to DEC Easynet sites as CRL::"/pub/X11/R4".

Sites in Australia may contact this address: ftp.Adelaide.EDU.AU [129.127.40.3]
and check the directory pub/X/R4. The machine shadows expo and archives
comp.sources.x. (Mark Prior, mrp@ucs.adelaide.edu.au, 5/90)

Note: a much more complete list is distributed regularly by Dan Heller 
(argv@sun.com) as part of the introductory postings to comp.sources.x.

--------------------------------------------------
Subject: 2)* Where can I obtain patches to X11R4?

	The xstuff server now has twelve patches for X11R4 [6/90]. Send to 
xstuff@expo.lcs.mit.edu the Subject line
		send fixes #
where # are numbers in the range of 1 to 12 (e.g. `send fixes 3 5 7 8 10`).

	Patches are sometimes also distributed through the newsgroup 
comp.sources.x, with some lagtime, and are typically archived on sites from
which X11R4 is available.

	Some source re-sellers may be including patches in their source 
distributions of X11R4.

--------------------------------------------------
Subject: 3) Where can I obtain Motif?
	
	Various hardware vendors produce developer's toolkits of binaries, 
header files, and documentation; check your hardware vendor, particularly if
that vendor is an OSF member. Systems known to be shipping now: HP (sans UIL), 
Apollo (sans UIL), SCO, ISC, Mips (RISCwindows=X11R3 + full Motif), IBM. 

	In addition, independent binary vendors produce Motif toolkits. ICS 
makes several binary kits, notably for Sun, DEC, Apple; Quest (408-988-8880) 
sells kits for Suns, as well; IXI (+44 223 462 131) offers kits for Sun3 (SunOS
3.5 or later, and Sun4 (SunOS 4.0.1 or later). Unipalm XTech (+44 954 211862) 
offers a binary kit for Sun 4, Sun 3, and Sun 386i.
	The kits include varied levels of bug-fixing and support for shared 
libraries.

	An OSF/Motif source license must be obtained from OSF before source can
be obtained from the Open Software Foundation or any value-added vendor. Call 
the Direct Channels Desk at OSF at 617-621-7300 for ordering information.

--------------------------------------------------
Subject: 4) Where can I obtain toolkits implementing Open Look?

	Sun's XView has a SunView-style API. A new version is on the X11R4 
tape; a newer version is also available (as of 2/90) on expo.lcs.mit.edu 
for anonymous ftp. Supported binaries of XView include: 

	AT&T's Open Look GUI 2.0 Xt-based toolkit is now generally available 
[2/90]; contact 1-800-828-UNIX#544 for information. Binaries are produced
for SPARC systems by International Quest Corporation (408-988-8289).

	Sun is shipping OpenWindows 1.0 for Sparc, Sun-3, and Sun386i machines;
contact your local sales representative for more details.

	Solbourne's extensible C++-based Object Interface Library will be 
distributed by AT&T [date of availability appx. 6/90].

--------------------------------------------------
Subject: 5)* Where can I obtain other X sources?

	User-contributed software is distributed through the newsgroup
comp.sources.x, moderated by Dan Heller (argv@sun.com); also check that group 
for posting information.


	The machine expo.lcs.mit.edu has a great deal of user-contributed
software in the contrib/ directory; a good deal of it is present in current or 
earlier versions on the X11R3 and X11R4 contrib tapes. There is a new directory
contrib/R4fixes/ for fixes to R4 contrib software. [Jim Fulton, 2/90]

	The material on giza.cis.ohio-state.edu, which tends to duplicate 
the expo archives, is also available via anonymous UUCP from osu-cis, at TB+ 
and V.32 speeds.  Write to uucp@cis.ohio-state.edu (same as osu-cis!uucp) for 
instructions. [the archive is now maintained by Karl Kleinpaste]

	A new west-coast UUCP X11 Archive is administered by Mark Snitily 
(mark@zok.uucp) and contains the full X11R4 distribution, the XTEST
distribution, an entire archive of comp.sources.x and other goodies.
	The machine zok has a TB+ modem which will connect to 19.2K, 2400, 
1200 baud (in that order).  The anonymous UUCP account is UXarch with password 
Xgoodies.  The modem's phone number is 408-996-8285.
	A sample Systems (or L.sys) entry might be:
   		zok Any ACU 19200 4089968285 in:--in: UXarch word: Xgoodies
	To get a current listing of the files that are available, download
the file "/usrX/ls-lR.Z".
	A full subject index of the comp.sources.x files is available in the
file "/usrX/comp.sources.x/INDEX".
	The machine has just the one modem, so please do not fetch large 
amounts of data at one sitting.
[courtesy Mark Snitily, 2/90]


	FTP sites and software available (list as of X11R3; also see above):
brazos.rice.edu            128.42.42.2    pub/X11R3/core.src
charon.mit.edu             18.80.0.13     perl+patches, xdvi
cs.purdue.edu              128.10.2.1     rcs,xspeed
j.cc.purdue.edu            128.210.0.3    comp.sources.{unix,x,amiga}, elm, uupc
nl.cs.cmu.edu              128.2.222.56   Fuzzy Pixmap 0.84 in /usr/mlm/ftp
shambhala.berkeley.edu     128.32.132.54  xrn
terminator.cc.umich.edu    35.1.33.8      xscheme, msdos, atari
cayuga.cs.rochester.edu    192.5.53.209   Xfig,LaTeX styles,Jove
cfdl.larc.nasa.gov         128.155.24.55  gnu, rfc, sun, X, ucb, odu, vm
cheddar.cs.wisc.edu        128.105.2.113  Common Lisp stuff, X11 courier fonts
cs.orst.edu                128.193.32.1   Xlisp
dinorah.wustl.edu          128.252.118.101 X11R3/core.src 
expo.lcs.mit.edu           18.30.0.212    a home of X, portable bitmaps
gatekeeper.dec.com         128.45.9.52    X11,etc...
giza.cis.ohio-state.edu    128.146.8.61   miscellaneous similar to expo
hotel.cis.ksu.edu          129.130.10.12  XBBS, msdos, U3G toolkit
icarus.riacs.edu           128.102.64.1   SLIP, chkpt, macdump, Xpostit
interviews.stanford.edu    36.22.0.175    InterViews X toolkit
jpl-mil.jpl.nasa.gov       128.149.1.101  Tex, Mac, Gnu, Xv11R{2,3}
m9-520-1.mit.edu           18.80.0.45     Xim (X image viewer)
mordred.cs.purdue.edu      128.10.2.2     X11R3
polyslo.calpoly.edu        129.65.17.1    src/spaceout.tar.Z for X11
scam.berkeley.edu          128.32.138.1   X sources, etc.
sun.soe.clarkson.edu       128.153.12.3   X11 fonts, TeX
think.com                  10.4.0.6       X11.2 Interviews 3d
vaxa.isi.edu               128.9.0.33     X, db
wheaties.ai.mit.edu        128.52.32.13   "tX11" 
xanth.cs.odu.edu           128.82.8.1     comp.srcs.{x,unix,misc,games,amiga},X
[This is from a file posted in early July 1989 and is attributable to Edward
Vielmetti (emv@math.lsa.umich.edu) and Jon Granrose (odin@pilot.njin.net).
This list does need updating; help is invited.]


In addition, UUNET Source Archives (703-876-5050) tracks comp.sources.x and 
provides 600MB+ of compressed programs on two 6250 bpi or five 1/4" tapes. 
	
--------------------------------------------------
Subject: 6) What is the xstuff mail-archive?

	The xstuff server is a mail-response program. That means that you mail 
it a request, and it mails back the response.
	Any of the four possible commands must be the first word on a line. The 
xstuff server reads your entire message before it does anything, so you can 
have several different commands in a single message (unless you ask for help). 
The xstuff server treats the "Subject:" header line just like any other line 
of the message.
	The archives are organized into a series of directories and 
subdirectories.  Each directory has an index, and each subdirectory has an 
index. The top-level index gives you an overview of what is in the 
subdirectories, and the index for each subdirectory tells you what is in it.

	1) The command "help" or "send help" causes the server to send you a 
more detailed version of this help file.
	2) if your message contains a line whose first word is "index", then 
the server will send you the top-level index of the contents of the archive. If
there are other words on that line that match the name of subdirectories, then 
the indexes for those subdirectories are sent instead of the top-level index. 
For example, you can say "send index fixes" (or "index fixes"). A message that 
requests an index cannot request data.
	3) if your message contains a line whose first word is "send", then the
xstuff server will send you the item(s) named on the rest of the line. To name 
an item, you give its directory and its name. For example
                send fixes 1 3 4
	You may issue multiple send requests. The xstuff server contains many 
safeguards to ensure that it is not monopolized by people asking for large 
amounts of data. The mailer is set up so that it will send no more than a fixed 
amount of data each day. If the work queue contains more requests than the 
day's quota, then the unsent files will not be processed until the next day. 
Whenever the mailer is run to send its day's quota, it sends the requests out 
shortest-first.
	4) Some mailers produce mail headers that are unusable for extracting 
return addresses.  If you use such a mailer, you won't get any response.  If 
you happen to know an explicit path, you can include a line like
        path foo%bar.bitnet@mitvma.mit.edu
or
        path bar!foo!frotz
in the body of your message, and the daemon will use it.

	The xstuff server itself can be reached at xstuff@expo.lcs.mit.edu. If 
your mailer deals in "!" notation, try sending to 
{someplace}!mit-eddie!expo.lcs.mit.edu!xstuff.

[based on information from the MIT X Consortium, 8/89, 4/90.]

--------------------------------------------------
Subject: 7) Where can I find books/articles on X that are good for beginners?

	Ken Lee of the DEC Western Software Laboratory (klee@wsl.dec.com) 
regularly posts to comp.windows.x and ba.windows.x a list of reference books 
and articles on X and X programming.  Here is an unordered set of useful 
reference books and tutorials, most of which appear on that list [comments are 
gathered from a variety of places and are unattributable]:

Jones, Oliver, "Introduction to the X Window System," Prentice Hall, 1989. A 
fine introduction to programming with Xlib; fairly good background to the X 
protocol; nice discussion of Xlib, the X library. ISBN 0-13-499997-5.
 
Young, Doug. "The X Window System: Applications and Programming with Xt (Motif 
Version)," Prentice Hall, 1989 (ISBN 0-13-497074-8). The excellent tutorial 
"X Window Systems Programming and Applications with Xt," (ISBN 0-13-972167-3) 
updated for Motif. [The examples from the Motif version are available on expo 
in ~ftp/contrib/young.motif.tar.Z]
 
Scheifler, Robert, James Gettys, and Ron Newman, "X Window System: C Library 
and Protocol Reference," Digital Press, 1988. The bible on X.  This is the most
complete published description of the X programming interface and X protocol. 
It should not be one's first book on X, though. ISBN 1-55558-012-2.  DP order 
number EY-6737E-DP.  
 	
Nye, Adrian, "Xlib Programming Manual, Volume 1" and "Xlib Reference Manual, 
Volume 2," O'Reilly and Associates, 1988. A superset of the MIT X documentation;
the first volume is a tutorial with broad coverage of Xlib, and the second
contains reference pages for Xlib functions and many useful reference 
appendices.  ISBN 0-937175-26-9 (volume 1) and ISBN 0-937175-27-7 (volume 2).
[A version updated for X11R4 is available (4/90).]

Nye, Adrian, and Tim O'Reilly, "X Toolkit Programming Manual, Volume 4,"
O'Reilly and Associates, 1989. The folks at O'Reilly give their comprehensive
treatment to programming with the MIT X11R3 Intrinsics; some information on 
X11R4 is included.

O'Reilly, Tim, ed.,  "X Toolkit Reference Manual, Volume 5," O'Reilly and 
Associates, 1989.  A professional reference manual for the MIT X11R3 Xt; some 
information on X11R4 is included.

Rosenthal, David S.H., "Inter-Client Communication Conventions Manual Version 
1.0 (MIT Consortium Standard)." The first real ICCCM, available on the R4 tape;
a version is also available from the xstuff mail-archive-server.

(Prentice-Hall ordering is 201-767-5937. O'Reilly ordering is 800-338-NUTS.)

In addition, check the X11R4 core distribution in doc/tutorials for some useful
papers and tutorials, particularly the file doc/tutorials/answers.txt.  "Late 
Night's Top Ten X11 Questions" by Dave Lemke (lemke@ncd.com) and Stuart Marks 
(smarks@sun.com) answers other common questions and some of these here in more 
detail.

--------------------------------------------------
Subject: 8) What courses on X are available?

	Advanced Computing Environments periodically offers at least a two-day
Introduction course. Contact Susie Karlson at 415-941-3399 for information.

	Communica Software Consultants offers three-day hands-on courses in X 
designed for the X Window system developer and programmer. Contact Nicholas
Davias, telephone (08) 232 2626, e-mail nick@manic.communica.oz. [4/90]

	Integrated Computer Solutions, Inc., offers several multi-day, hands-on
courses on X, Xt, and the Xaw and Motif widget sets, in particular. 
Information is available at 617-547-0510 and info@ics.com.

	Intelligent Visual Computing teaches several Xt-based lab courses 
on-site. IVC is at 919-481-1353 or at info@ivc.uu.net.

	IXI Limited (+44 223 462 131) offers regular X training courses for 
both programmers and non-technical managers.

	Lurnix offers 4-day "type-along courses" on Xt; the course is being
ported from Xaw to Xm. Information is available at 800-433-9337 (in CA: -9338).

	OSF Educational Services (617-621-8778) offers one-day and one-week 
Motif courses.

	Unipalm XTech (+44 (0954) 211862) offers X and Xt courses.

	Various vendors are also beginning to offer X training, usually 
specific to Xt and a proprietary widget set; HP and DEC are also offering Xlib 
courses. Sun offers an XView course.

	Various universities are offering short X courses or overviews: UCLA,
Dartmouth, University of Lowell, University of Canberra (within Australia: 
062-522422) ...

	Among the best places to find courses are at the various Unix 
conferences -- Uniforum, Usenix, Unix Expo, Xhibition, the MIT X Technical
Conference, &c.

[additional information to be filled in as received]

--------------------------------------------------
Subject: 9) Is there a skeleton X program available?
	
	There is no general framework such as the TransSkel program for the 
Macintosh which handles lots of the odds and ends and overhead of development 
under a window system and which can be used as a platform for additional 
development. In X, the problem is typically solved by using an interactive 
application builder tool or by using cut&paste on existing X applications. Good
applications which you might look to manipulate when you want to "test just 
this one little thing" include contrib/clients/xskel, a simple R4 program that 
puts up a window and allows sketching in it and offers a starting point for
quick hacks, the Xaw examples in the examples/ directory in the R3 and R4 
distributions, and the Xlib "Hello World" example in the R3 doc/HelloWorld and 
R4 doc/tutorials/HelloWorld; an updated version of this program which uses R4 
Xlib calls and current ICCCM conventions was posted in 2/90 to comp.windows.x  
by Glenn Widener of Tektronix. 	[3/90]

--------------------------------------------------
Subject: 10) What are these common abbreviations?

	Xt: The X Toolkit Intrinsics is a library layered on Xlib which 
provides the functionality from which the widget sets are built. An "Xt-based" 
program is an application which uses one of those widget sets and which uses 
Intrinsics mechanisms to manipulate the widgets.
	Xmu: The Xmu library is a collection of Miscellaneous Utility functions
useful in building various applications and widgets.
	Xaw: The Athena Widget Set is the MIT-implemented sample widget set
distributed with X11 source since X11R2.
	Xm: The OSF/Motif widget set from the Open Software Foundation; binary
kits are available from many hardware vendors
	XUI: DEC's X-programmer's toolkit, including a widget set and a high-
level widget description language, is being phased out.
	Xhp (Xw): The Hewlett-Packard Widget Set was originally based on R2++, 
but several sets of patches exist which bring it up to R3, as it is distributed
on the X11R4 tapes.
	dxwm: The DECwindows window manager is part of DEC's current X release.
	mwm: The Motif Window Manager is distributed with OSF/Motif source and
is available from vendors in binary form.
	CLX: The Common Lisp X Interface is a Common Lisp equivalent to Xlib.
	XDMCP: The X Display Manager Protocol provides a uniform mechanism for 
a display such as an X terminal to request login service from a remote host.
	XLFD: The X Logical Font Description Conventions describes a standard
logical font description and conventions to be used by clients so that they
can query and access those resources.
	ICCCM: The Inter-Client Communication Conventions Manual explains the
set of standard conventions which X clients should follow to allow them to
cooperate in the areas of selections, cut buffers, window management, session
management, and resources. The latest version is on the X11R4 tape.
	RTFM: Common expert-speak meaning "please locate and consult the 
relevant documentation -- Read the Manual"
	UTSL: A common expression meaning "take advantage of the fact that you 
aren't limited by a binary license -- Use The Source, Luke".

--------------------------------------------------
Subject: 11) What is XUG?

	The X User's Group was formed in January of 1988.  Its purpose is to 
encourage X development by providing information on the X Window System to all 
who are interested.

	- Local Area Groups: [this list is in the process of being updated]:
		Bay Area 		Jim Turner, 415/960-0123
		Boston 			Mitch Trachtenberg, 617/621-8700
		Cleveland 		Mike Kolberg, 216/243-1198
		New York City 		#TBC#
		Princeton, NJ 		Joe Camaratta, 609/734-6500
		Research Triangle Park 	Steven Thiedke, 919/481-1353
		Washington, DC 		Thomas Fagre, 703/866-7425
		Rocky Mountain		Jim West, 719/260-3463
		England 		Ray Anderson, +44 223 462131
		France 			Daniel Dardailler, +33 93 65 77 71
		Singapore		Chee Keong Law, 772-3116
		Milan			Richard Glover, (39) 961-743-486

	- XNextEvent: the several-times-yearly newsletter includes articles of 
general interest.

	To join, form a local group, contribute to XNextEvent, or help out in 
any other way, contact Alex Fisher at XUG, c/o Integrated Computer Solutions, 
163 Harvard Street, Cambridge, MA  02139, 617/547-0634, or email to 
xug@expo.lcs.mit.edu (please make sure to include a return address, particularly
if you connect to the world via a UUCP connection). Note that this address is
not a mail server. [Note also that XUG does not currently send this list via
email to a mailing list, though individual requests will be answered.]

--------------------------------------------------
Subject: 12) What is EXUG?

The European X User Group was formed in 1989 to represent X users in Europe.  
It holds technical conferences at regular intervals, the next one being a
three-day conference at the University of Surrey, England, September 24-26.

The EXUG also publishes a regular newsletter which is distributed free of 
charge to members.  The EXUG also runs a email mailing list for members which 
is frequently used to address issues of European interest in X.

The EXUG can be contacted by email at: exug@unipalm.uucp or by snail mail at:   
The EXUG, Mitchell House, 185 High Street, Cottenham, Cambridge CB4 4RX, 
England; phone +44 954 211860.

[from Bevis King (brwk@doc.ic.ac.uk), 4/90]

--------------------------------------------------
Subject: 13) What is the X Consortium and how do I join?

	The MIT X Consortium was formed in January of 1988 to further the
development of the X Window System and has as its major goal the promotion of 
cooperation within the computer industry in the creation of standard software 
interfaces at all layers in the X Window System environment.
	MIT's role is to provide the vendor-neutral architectural and 
administrative leadership required to make this work. Membership in the 
Consortium open to any organization.  There are two categories of membership, 
Member (for large organizations) and Affiliate (for smaller organizations).
	Most of the Consortium's activities take place via electronic mail, 
with meetings when required.  As designs and specifications take shape,
interest groups are formed from experts in the participating organizations.  
Typically a small multi-organization architecture team leads the design, with 
others acting as close observers and reviewers.  Once a complete specification
is produced, it may be submitted for formal technical review by the Consortium
as a proposed standard.  The standards process typically includes public 
review (outside the Consortium) and a demonstration of proof of concept.
	Your involvment in the public review process or as a Member or 
Affiliate of the Consortium is welcomed.
	Write to: Bob Scheifler, MIT X Consortium, Laboratory for Computer 
Science, 545 Technology Square, Cambridge, MA 02139.

[For complete information see the XCONSORTIUM man page from the X11R4
distribution, from which this information is adapted.] [2/90]

--------------------------------------------------
Subject: 14) What is xpert?

	The xpert mailing list is the general, public mailing list on X
maintained by the X Consortium. The mailings are gatewayed, so xpert is almost 
identical to the comp.windows.x Usenet newgroup. 

	***	If you get comp.windows.x, you don't need to 	***
	***	be added to the xpert mailing list. 		***

	Otherwise, you can join the list to receive X information 
electronically. It is best to find a local distribution; perhaps someone within
your company is already receiving the mailing. As a last resort, send mail to 
xpert-request@expo.lcs.mit.edu with a valid return electronic address. 

--------------------------------------------------
Subject: 15)* What conferences on X are coming up?

	The next European X User Group Conference is a three-day affair at the
University of Surrey, England, September 24-26. Papers are invited on these
topics: server technology, server extensions, applications, user interfaces,
graphics, user inexperiences, network support, standardization efforts. There
is an associated vendor show. Information: +44 954 211860 or 
exug90@unipalm.co.uk.

	The MIT Technical Conference is typically held in January in Boston,
mostly for historical reasons; the Fifth Annual is January 14-16, 1991, at the 
Boston Marriott Copley Place. Information: +1 617 253 8861.

	The Xhibition 91 X trade show and conference, with tutorials, panels, 
presentations, and vendor exhibits, will probably be held in San Jose, June 
2-7. Information: +1 617 547 0510. 

	Other trade shows -- UnixExpo, Uniforum, Siggraph -- show an increasing
presence of X, including tutorials and exhibits.

--------------------------------------------------
Subject: 16)* What is the current state of the world in X terminals?

	Here is a selection of vendors with "impressions of consensus opinions".

	Acer (408-922-0333) has the Xebra 1000, based on an 8086 cpu, with a
640x480 monochrome screen. "Low performance." "May not be sold anymore."

	AT&T's (800-247-1212; ask for local dealer) 730X has a 1Kx1K monochrome
(amber or white) display with a 1:1 aspect ratio. The terminal supports 
multiple Telnet sessions and AT&T windowing in addition to X. The 730 supports
ISO or TCP/IP over twisted pair. "Very, very nice."

	C. Itoh (714-660-1421; also 800-347-2484) produces the CIT-X Network 
Display Station based on a 12.5MHZ 68301 main processor with a 34010 graphics 
processor. "C. Itoh may pull out of the business."

	DEC (800-343-4040) offers the VT1000, a home-brew 15" 1024x864 
monochrome terminal using the TI 34010. "Digital has it now?"

	Gipsi S.A. (+33 (1) 30.60.75.00 or Jeff Abramatic at jfa@gipsi.fr) in 
10/89 announced "le tX", a line of 68030-based X terminals running X11R3. 
High-end models, at least, feature downloadable X servers.
	 Model Memory Resolution   Display Refresh (Hz)  Price (FF)
	   M    2 MB  1280x960x1  19" B&W       66        32 400
	   Me   2 MB  1280x960x2  19" Greyscale 66        38 000
	   C4   2 MB  1280x768x4  16" Colour    60        59 900
	   C8   4 MB  1280x1024x8 19" Colour    60        79 400
		Expansion is up to 8MB and 8 planes.
The exclusive US distributor is Peripheral Design, Inc (404-263-0067).
"Looks fairly nice; shouldn't be overlooked."

	GraphOn (800-472-7466) OptimaX 200 runs a server on the host which 
translates from X protocol to a proprietary protocol which can run over a 
serial line. The screen is 14". The terminal is based on a 12MHz 68000.  (See 
the December 1989 issue of XNextEvent for an informal review.) "Best available
solution for RS232C lines."

	HP (800-752-0900; ask for nearest sales office) offers the 700/X series
of terminals using on the TI 34010. Bit-mapped graphics monitors with 
resolutions of 640x480, 800x600, and 1024x768 are supported.  All units come 
standard with 1 Mbyte of RAM expandable up to 4 Mbytes and display 16 colors 
from a palette of 4096 or up to 16 levels of gray-scale. (They can be
converted into workstations.)

	Human Design Systems (800-437-1551) offers several combinations of 14",
16", and 19" color, grey-scale, and mono screens, at least 1Kx1K. All support 
thin and thick Ethernet. High-end models are expandable to 8.5MB. "Slow."

	IBM's Xstation 120 starts with 512KB of memory and features support
for simultaneous Token-Ring and Ethernet connections. [2/90] AGE (619-565-7373)
has software that allows it to work with Suns, RTs, and DECstations as well as 
the IBM Powerstation machines.

	Jupiter Systems (415-523-9000, 508-836-4400) produces the Model 310
which features a 19-inch 1280x1024 color monitor. "A price leader, but also a 
performance leader." The Model 410 has a 19", 1280x1024 monitor and offers
a large palette and high memory expansion. [5/90]

	Micronics (415-651-2300) offers the MaxTerm, based on a 25MHz 80386 and
featuring  a 19", 1280x1024 screen. The MaxTerm offers virtual memory. [5/90]

	Network Computing Devices (415-694-0650) offers several terminals. The 
NCD16 has a 1Kx1K 16" square display, a 12.5MHz 68000, a non-optical mouse, a 
DEC-influenced keyboard, and an X11R3 server.  The base configuration comes 
with 1.5M memory. There is an option for down-loading the server into RAM.
There is also a 19" version with 1280x1024 resolution. The new 17c is an 8-bit 
color 1024x768 display. "Nice engineers' terminals."

	NCR (513-445-2033) offers the Towerview with 1024x840 resolution and a 
PROM-based server. The Towerview supports serial connections. Fonts are
down-loaded. The XL15 and XL19 have 15", 1024x800 and 19", 1280x1024 displays,
respectively. "Seems to be designed for the PC office." NCR has recently [5/90]
added a series of color terminals to its line; the terminals use a 68020 and
a TI34010 for low-level graphics. Offerings include a 14", 800x600 terminal,
one at 17" and 1024x768, and one at 19" and 1024x768.

	Northwest Digital Systems (206-524-0014).

	Princeton Graphic Systems (800-221-1490) has introduced the Ultra X line
with monochrome up to 1024x768 and color up to 1024x1280, expandable to 8MB.

	Qume (408-942-4000) has announced an X terminal called the QXT 10 X.

	Samsung Software America has introduced the SGS-19, offering a 19",
1280x1024 display; it is based on the RISC Am29000. [5/90] "VERY fast mono."

	Spectragraphics (619-450-0611) offers an X terminal with emulation for
the IBM 3270 and related terminals.

	Tektronix (203-877-1494; or Rick Kamp rickka@orca.WV.tek.com) offers 
the Model 4211 Graphics Netstation using the TI 34010 graphics processor. The 
15" screen is 1024x768 color. The XN11 is a PseudoColor device with up to 8 
planes. The 16" and 19" monitors have the 1024x768 resolution. There is also an
XN10, which features a 19", 1024x768 color monitor.

	Visual Technology (800-VISUALC; MA 508-836-4400) offers three models
of terminals:
   Model             Resolution                  Processor       Refresh
   -----             ----------                  ---------       -------
   X15 (15" screen)  1024 x 800                  16.6 MHz 68000  76 Hz
   X19+(19" screen)  1152 x 900 ("Sun" standard) 16.6 MHz 68000  72 Hz
   X19Turbo          1280 x 1024                 20 MHz 68020    72 Hz
The X15 and X19+ offer optimized monochrome graphics at advanced processor
speeds, with 1 - 4M RAM.  The X19Turbo offers optimized monochrome graphics,
with 2 - 8M RAM and the option for grayscale expansion.  The X19Turbo offers 
hardware-assisted grayscale drawing. "Good low-cost-per-seat performance 
stations." [5/90]

Digital Review's 2/26/90 issue evaluates a subset of these terminals. 
Corrections are in the 3/5 issue, p.4. A rebuttal from Jupiter appears 3/19. 

Digital News' 4/16/90 issue evaluates a subset of these terminals.

[Note to vendors, in particular: it is becoming difficult to keep up with the
introduction of new models. Any updates to the above?]

--------------------------------------------------
Subject: 17)* How can I get an X server on a PC?

	Locus Computing (800-955-6287; CA: 213-670-6500; UK: +44 296 89911) has 
a server called PC-Xsight which also appears in Acer's X terminal.

	HP (800-752-0900) has the "HP Accelerated X Window Display Server"
(HP AXDS/PC; HP part D2300B) which will run on any AT-class DOS machine with 
640KB, MSDOS 3.1 or higher, and the HP Intelligent Graphics Controller 10 card,
to which the X11R3-based server is downloaded (avoiding performance-limitations
from PC RAM-size and processor speed). [from John Kempff (kempff@hppad.hp.com),
3/90]

	Graphic Software Systems (GSS) (503-641-2200) makes PC-Xview, an 
MSDOS-based X server which interfaces with PC/TCP Plus networking software from
FTP Software and Excelan's LAN WorkPlace for DOS.  The server works with 
(a) 286, 386, 486 (b) EGA, VGA, DGIS displays. (c) DOS 3.2 and above
(d) Microsoft, Logitech, Mouse Systems Mice (e) 640k memory up to 16 MB memory
[the PC-Xview/16 is available for PCs with extended memory].

	VisionWare's XVision is a Microsoft Windows-based X server which allows
an IBM-compatible PC or PS/2 to display X clients running on a networked 
computer at the same time as local DOS programs. VisionWare is at 612-377-3627 
or vision@vware.mn.org (UK: +44 532 788858 and vware@vision.uucp).
	
	Integrated Inference Machines (714-978-6201 or -6776) is shipping 
X11/AT, an X server that runs under MS-windows. The server converts an IBM-AT 
into an X terminal which can simultaneously run MS-DOS and Microsoft Windows 
applications.  

	IBM is rumored to offer a product; part #5709-029.

	Hummingbird Communications (Canada 416-470-1203) produces the 
HCL-eXceed and HCL-eXceed Plus for EGA, VGA, and VGA+ controllers. 

	Information Network Solutions also offers a product called HCL-eXceed
for the *86. The fax is 02-4122079 inside Australia, 612-4122079 from overseas.

	PC DECwindows a.k.a. the PC DECwindows Display Facility is an MS-DOS 
application that turns your PC into an X11R3 terminal. It supports DECnet.
Available from DEC. [Dennis Giokas (giokas@mosaic.enet.dec.com), 3/90]

	AGE (619-565-7373) offers the XoftWare TIGA.

	Bell Technologies (Fremont, CA: 415-659-9097)

	Intelligent Decisions, Inc. (Sunnyvale, CA: 408-734-3730)

	Pericom's TeemTalk-X for IBM clones allows toggling between X and DOS. 
Information: +44 (0908) 560022.	[5/90]

	DESQview/X from Quarterdeck (?) incorporates X into the DESQview
multi-tasking DOS environment.

--------------------------------------------------
Subject: 18) What terminal emulators other than xterm are available?

	Grafpoint's TGRAF-X provides emulation of the Tektronix 41xx and 42xx 
series. Information: 408-446-1919. [5/90]

	IXI's X.deskterm, a package for integrating character-based 
applications into an X environment, includes a number of terminal-emulation
modules. Information: +44 (0223) 462131. [5/90]

	Pericom produces Teem-X, a set of several emulation packages for a
number of Tek, DEC, Westward, and Data General terminals. The software runs on
Sun 3, Sun 4, Apollo, DEC, ISC, IBM/AIX. Information: US: 609-895-0404, 
UK: +44 (0908) 560022. [5/90]

--------------------------------------------------
Subject: 19) How can I get an X server on a Macintosh running MacOS?

	eXodus from White Pine Software (603-886-9050) runs on any Mac with
at least 1MB of memory and runs the X server within a standard Macintosh 
window.  eXodus II uses the math co-processor and other features of high-end
Macs. [info current as of 6/89] Version 2.0 supports DECwindows colors, fonts,
and cursors, and session management, and supports color and multiple screens.
[5/90]

	Apple's MacX runs on MacPlus or newer machines with >= 2MB of memory
and system software 6.0.4 or later. It is an "X11R3.5" server that includes 
support for an optional built-in ICCCM-compliant window manager, X11R4 fonts 
and colors, a built-in BDF font compiler, and built-in standard colormaps, and 
it supports the X11R4 notion "all visuals that make sense" for color displays. 
Version 1.0 started shipping at the end of May. 
[courtesy Alan Mimms (alan@apple.com], 3/90] "X for the rest of us."

--------------------------------------------------
Subject: 20) Where can I obtain an X-based editor or word-processor?

	You can ftp the latest version of emacs, including X11 support, from
prep.ai.mit.edu [18.71.0.38].  The file you probably want is
~ftp/pub/gnu/emacs-18.55.tar.Z, or similarly-named files. 
	
	Epoch is a modified version of Gnu Emacs with additional facilities
useful in an X environment. Epoch is available by anonymous ftp from 
cs.uiuc.edu (128.174.252.1), in the directory pub/epoch-files.  There are two 
subdirectories:  epoch contains the epoch source, and gwm contains the source 
to the programmable window manager GWM, with which epoch works well.

	The Andrew system on the X11R4 tape has been described as one of the
best word-processing packages available. It supports word processing with 
multi-media embedded objects: rasters, tables/spread sheets, drawings, style 
editor, application builder, embedded programming language, &c. 
[Fred Hansen (wjh+@ANDREW.CMU.EDU)]

In addition:

	FrameMaker and FrameWriter are available as X-based binary products for
several machines. Frame is at 800-843-7263 (CA: 408-433-3311).

	InDepthEdit is available from Non Standard Logics (+33 (1) 43 36 77 50).

	DECwrite is available from DEC for some DEC hardware and SunWrite is
available from Sun.

	IslandWrite will soon be available from Island Graphics (415-491-1000) 
for some HP & Apollo platforms.

	Interleaf is currently available from Interleaf (800-241-7700, 
MA: 617-577-9800) on all Sun and DEC platforms; others are under development.

	The Alis office-productivity tool from Applix (1-800-8APPLIX, MA: 
508-870-0300) includes a multi-font WYSIWG document composer; for several
systems.

	ArborText, Inc. provides an X11 version of its Electronic Publishing 
program called "The Publisher". The Publisher is available on Sun, HP and 
Apollo workstations. Contact Arbortext at 313-996-3566. [5/90]

--------------------------------------------------
Subject: 21) Where can I obtain an X-based paint/draw program?

	xpic is an object-oriented drawing program. It supports multiple font 
styles and sizes and variable line widths; there are no rotations or zooms.
xpic is quite suitable as an interactive front-end to pic, though the 
xpic-format produced can be converted into PostScript. (The latest version is 
on the R4 contrib tape in clients/xpic.)

	xfig is an object-oriented drawing program supporting compound objects.
The text-handling is limited. The xfig-format can be converted in PostScript or
other formats. One version is on the R4 contrib tape in clients/xfig; it is one 
of the several 'xfig' programs which several groups independently developed 
parallel versions of from the R3 xfig.

	idraw 2.5 supports numerous fonts and various line styles and arbitrary
rotations. It supports zoom and scroll and color draws and fills. On the R4 
tape; see also interviews-request@interviews.stanford.edu.

[courtesy Jim Helman (jim@kaos.Stanford.EDU) 7/89; some comments added by XUG]

In addition:

	dxpaint is a bitmap-oriented drawing program most like MacPaint; it's 
good for use by artists but commonly held to be bad for drawing figures or 
drafting. dxpaint is part of the Ultrix 3.x release.

	FrameMaker has some draw capabilities. [4/90]

	ArborText (313-996-3566) offers PubDraw, an X11-based drawing program,
on Sun, HP and Apollo workstations.
	
--------------------------------------------------
Subject: 22)* Where can I obtain an X-based spreadsheet?

Vendor                        Product    Phone
------                        -------    -----
Access Technology             20/20      (508) 655-9191
Informix                      WingZ      (800) 331-1763
Quality Software Products     Q-Calc/eXclaim    800-628-3999 (CA:213-410-0303) 
Unipress                      Q-Calc     (201) 985-8000
Uniplex                       Uniplex    (214) 717-0068, (800) 356-8063
[above from Walter E. Gillett (gillett@AI.MIT.EDU)]
Digital				DECdecision   1-800-DIGITAL

BBN Software Products         BBN/Slate  617-873-3984 (Scott Richardson)
	(the product includes WordProcessing, Spreadsheet, Graphics, Image 
	Processing, Foreign Language WordProcessing, Electronic Mail, and 
	Elecronic Conferencing)

The Alis office-productivity tool from Applix (1-800-8APPLIX, MA: 508-870-0300)
includes a spreadsheet.

There is a spreadsheet program in the Andrew Toolkit on the R4 contrib tape.

--------------------------------------------------
Subject: 23) Where can I get a PostScript previewer for X?

	xps is available from almost everywhere that the X11 contributed source
can be found. The version currently on expo is based on Crispin Goswell's 
PostScript interpreter with fixes and speedups by John Myers and Barry Shein 
and an X11 driver by Terry Weissman.  There are known problems with fonts. The 
package is good for lowering the edit-print-edit cycle in experimenting with 
particular PostScript effects.

	Ghostscript is distributed by the Free Software Foundation 
(617-876-3296) and includes a PostScript interpreter and a library of graphics
primitives. The README for the current version, 1.3, points out that it doesn't
take advantage of many of the facilities offered by X but that this is intended
to change in the future. The software can probably be found on prep.ai.mit.edu.
A 1.4beta may be found on uunet. [2/90]

In addition:

	ScriptWorks is Harlequin's software package for previewing and printing
PostScript(R) descriptions of text and graphics images; previewers for X are 
available. For information call +44-223-872522 or send email to 
scriptworks-request@uk.co.harlqn.

	Digital's dxpsview runs on UWS 2.1 and 2.2.

	Sun's pageview runs with the X11/NeWS server. 

--------------------------------------------------
Subject: 24) Where can I get a troff previewer for X?

	X11R4 has two previewers for device-independent troff: the supported 
client xditview, and the contributed-but-well-maintained xtroff. An earlier 
version of xtroff also appeared on the R3 contributed source.

In addition:

	Elan Computer Group (CA: 415-964-2200) produces eroff, a modified 
troff implementation, and Elan/Express, an X11 eroff previewer (misleadingly)
labeled "WYSIWYG".

	SoftQuad (416-963-8337; USA only 800-387-2777, mail@sq.uu.net or
mail@sq.com) offers SoftQuad Publishing Software, including a substantially-
rewritten troff formatter, a better intermediate language with backwards 
compatibility, and an X11[R3,R4] previewer. (This is the package adopted by 
AT&T's own MIS department, and used in and re-sold by many parts of AT&T). 
[information from Ian Darwin, SoftQuad (ian@sq.com) 3/90]

	Image Network (1-800-TOXROFF; CA: 415-967-0542) has the 'xroff' 
package, which includes a fine modified troff implementation and a set of 
X11-based page previewers. (This is the package OEM'ed by several hardware 
vendors.)

[mostly courtesy moraes@cs.toronto.edu (Mark Moraes)] [2/90]

--------------------------------------------------
Subject: 25)+ How can I design my own font?

	One way is to use the "bitmap" client or some other bitmap-editor (e.g.
Sun's icon-editor tool, post-processed with pbmplus) to design the individual 
characters and then to do some large amount of post-processing to concatenate 
them into the BDF format.
	The R3 contrib/ area (in fonts/utils/ and in clients/xtroff) contained 
a number of useful utilities, including some to convert between BDF font format
and a simple character format which can be edited with any text editor.
	An easier way is to use the "xfed" client to modify an existing font; a
recent version is on the R4 tape in contrib/clients/xfed; there are older 
versions on the R3 contrib tape.

--------------------------------------------------
Subject: 26)+ What is PEX?

	The PHiGS Extension to X is a proposed X Consortium standard awaiting 
proof of concept. Sun Microsystems is currently contracted to develop a freely 
redistributable (copyright similar to the current X copyright) sample
implementation.  The current schedule calls for this implementation to be 
publicly available in early 1991. Several vendors, including DEC and E&S, are 
currently selling independently-developed PEX servers for their workstations.
[6/90]

--------------------------------------------------
Subject: 27) How do I convert Mac/TIFF/GIF/Sun/PICT/Face/img/FAX images to X?

	The likeliest program is an incarnation of Jef Poskanzer's useful++ 
Portable Bitmap Toolkit, which includes a number of programs for converting 
among various image formats. It includes support for many types of bitmaps, 
gray-scale images, and full-color images. The latest version, PBMPLUS, was 
posted to the net about 11/22/89; it is also on the R4 tape under 
contrib/clients/pbmplus.
	The package has been independently updated to support XPM images for
pixmaps.
	Useful for viewing some image-formats is Jim Frost's xloadimage, a
version of which is in the R4 directory contrib/clients/xloadimage. 

	[Both PBMPLUS and xloadimage are under active development; watch for
updated versions.]

--------------------------------------------------
Subject: 28) How do I use another window manager with DEC's session manager?

	DEC's session manager will start dxwm up by default. To override this, 
add to your .Xdefaults file something like this line, naming the full pathname:

	sm.windowManagerName:   /usr/bin/X11/your_favorite_wm

--------------------------------------------------
Subject: 29) How do I build X with gcc?

	MIT is now using regularly the Free Software Foundation's
GNU-CC to build the X distribution and uses gcc-built servers to test 
performance increases.

	[These options are gathered from several descriptions of building
X with gcc 1.34, 1.35, and 1.36]:

	Use the options
		-O -fstrength-reduce -fpcc-struct-return

		-traditional may also be necessary if your version of
gcc is sufficiently old.

	Do not use -finline-functions, particularly on the R4 server.

	--->	Make sure to run 'fixincludes' from the gcc distribution 
	--->	before doing anything, or you will get fatal errors such as:
	--->	xterm: Error 15, errno 25: Inappropriate ioctl for device.

HOWEVER, there is a bug in gcc 1.34 and 1.36 (but not in 1.35 or 1.37) which 
miscompiles things of the form (expr == 0 ? exp1 : exp2).  The fix needed in 
X11R4 (and probably X11R3) is to change the definition of XtNewString in 
Intrinsic.h to:
  #define XtNewString(str) \
  ((str) != NULL ? (strcpy(XtMalloc((unsigned)strlen(str) + 1), str)) : NULL)
A work-around is also in fix-2 to X11R4.

--------------------------------------------------
Subject: 30) What are these funny problems compiling X11R3 on the Sun4?

	cc -c -O -I. -I../../include -I../../.././X11 -I../mfb   cfbbitblt.c
	cc: Fatal error in iropt: Illegal instruction (core dumped)

	Known problems with the Sun4 optimizer render the -O flag unusable
on this file. 

	In addition, there is a problem in all of the procedures that return a
parameter that was never referenced.  Instead of returning the string, the 
compiler with optimization seems to be returning the last value computed.  You 
can compile lib/Xt/TMparse.c without optimization; alternatively, you can 
replace the "return str" in various routines to use that parameter [courtesy of
Jim Fulton, MIT X Consortium]:

#ifdef sparc
/*
 * The silly optimizer in SunOS 4.0.3 and below generates bogus code that
 * causes the value of the most recently used variable to be returned instead
 * of the value passed in.
 */
static String silly_optimizer_kludge;
#define BROKEN_OPTIMIZER_HACK(val) silly_optimizer_kludge = (val)
#else
#define BROKEN_OPTIMIZER_HACK(val) val
#endif

and have routines end with
    return BROKEN_OPTIMIZER_HACK(str);

Note also that the SPARCstation1 has a bug in its use of -misalign; a fix 
to cc should be obtained from Sun.

--------------------------------------------------
Subject: 31) What are these problems installing R4 on the Sun running SunOS 4?
All of the executables that I try to run have the following results:
	ld.so: libXmu.so.4: not found
or even:
	ld.so: call to undefined procedure __GetHostname from 0xf776a96c

	If you are building with shared libraries on a Sun, remember that you 
need to run "ldconfig" as root after installing the shared libraries (if you've
installed X on a file-server, run it on the server's clients, too).  While 
building and installing the distribution, you need to be careful to avoid 
linking against any existing X shared libraries you might have (e.g. those 
distributed with OpenWindows).  You should make sure you do not have 
LD_LIBRARY_PATH set in your environment during the build or the installation.  
If you are going to keep xterm and xload as setuid programs, please note that 
the shared libraries must be installed in /usr/lib, /usr/local/lib, or 
/usr/5lib for these programs to work (or else those programs must be linked 
statically). [courtesy MIT X Consortium]

--------------------------------------------------
Subject: 32)* Where can I get a fast X server for a workstation?

	The R4 server should be among the fastest available for most machines.

	The "Purdue" speedups significantly speed up the X11R3 server.  Look on
expo.lcs.mit.edu:contrib/Purdue.2.[01]-tar.Z. (You'll also need gcc.)

	International Quest Corporation (408-988-8289) has an optimized R3 
server for Sun3/4/386i under SunOS 4.0 and also an optimized R4 server. 

	Unipalm XTech (+44 954 211244) makes several R3-based and R4-based 
tuned servers, most notably for Sun 3 and Sun 4.  (Note: the original work
was inherited from Torch Technology.)

	Xgraph's Xtool (408-492-9031) is an X server implemented in SunView 
which boasts impressive results on Sun 3 and SPARC systems. [6/90]

Several companies are making hardware accellerator boards:

	Dupont Pixel Systems (302-992-6911), for Sun.

	Megatek's (619-455-5590) X-cellerator board for the Sun 3 and Sun 4 is 
based on the TI 34020; the company claims performance improvements of 5x to 
10x over the sample X11R3 server.

--------------------------------------------------
Subject: 33)*  How can I change the titlebar of my xterm window?

	The solution involves sending an escape sequence to xterm which will
cause it to update the property which the window manager relies upon for the
string which appears in the window titlebar.
	A solution is as easy as typing this in an xterm running a shell:
		echo "ESC]2;TEXT^G"
where ESC is the escape key, TEXT is the string you wish to have displayed,
and ^G is a Control-G (the BEL character).

	Here is a more complicated csh alias which changes the titlebar to
the current working directory when you change directories:
		alias newcd 'cd \!* ; echo ESC]2\;$cwd^G'

	The digit '2' in these strings indicates to xterm that it should 
change only the title of the window; to change both the title and the name 
used in the icon, use the digit '0' instead, and use '1' to change only the 
icon name.

	These sequences work for both R3 and R4 xterm windows; the R4 xterm,
however, does not accept the looser sequences which worked under R3 and
demands a semicolon, above, for example, where the R3 xterm allowed any
character.

[For more information, see the article by Skip Montanaro of GE CR&D on Xterm
control sequences in the December 1989 XNextEvent.]

--------------------------------------------------
Subject: 34) Why doesn't anything appear when I run this simple program?

> ...
> the_window = XCreateSimpleWindow(the_display,
>      root_window,size_hints.x,size_hints.y,
>      size_hints.width,size_hints.height,BORDER_WIDTH,
>      BlackPixel(the_display,the_screen),
>      WhitePixel(the_display,the_screen));
> ...
> XSelectInput(the_display,the_window,ExposureMask|ButtonPressMask|
> 	ButtonReleaseMask);
> XMapWindow(the_display,the_window);
> ...
> XDrawLine(the_display,the_window,the_GC,5,5,100,100);
> ...

	You are right to map the window before drawing into it. However, the 
window is not ready to be drawn into until it actually appears on the screen --
until your application receives an Expose event. Drawing done before that will 
generally not appear. You'll see code like this in many programs; this code 
would appear after window was created and mapped:
  while (!done)
    {
      XNextEvent(the_display,&the_event);
      switch (the_event.type) {
	case Expose:	 /* On expose events, redraw */
		XDrawLine(the_display,the_window,the_GC,5,5,100,100);
		break;
	...
	}
    }

	Note that there is a second problem: some X servers don't set up the 
default graphics context to have reasonable foreground/background colors, and 
your program should not assume that the server does, so this program could 
previously include this code to prevent the case of having the foreground and 
background colors the same:
  ...
  the_GC_values.foreground=BlackPixel(the_display,the_screen);	/* e.g. */
  the_GC_values.background=WhitePixel(the_display,the_screen);	/* e.g. */
  the_GC = XCreateGC(the_display,the_window,
                GCForeground|GCBackground,&the_GC_values);
  ...
 
Note: the code uses BlackPixel and WhitePixel to avoid assuming that 1 is 
black and 0 is white or vice-versa.  The relationship between pixels 0 and 1 
and the colors black and white is implementation-dependent.  They may be 
reversed, or they may not even correspond to black and white at all.

--------------------------------------------------
Subject: 35) What is the difference between a Screen and a screen?

	The 'Screen' is an Xlib structure which includes the information about
one of the monitors or virtual monitors which a single X display supports. A 
server can support several independent screens. They are numbered unix:0.0,
unix:0.1, unix:0.2, etc; the 'screen' or 'screen_number' is the second digit --
the 0, 1, 2 which can be thought of as an index into the array of available 
Screens on this particular Display connection.
	The macros which you can use to obtain information about the particular
Screen on which your application is running typically have two forms -- one
which takes a Screen and one with takes both the Display and the screen_number.
	In Xt-based programs, you typically use XtScreen(widget) to determine 
the Screen on which your application is running, if it uses a single screen.
	(Part of the confusion may arise from the fact that some of the macros
which return characteristics of the Screen have "Display" in the names -- 
XDisplayWidth, XDisplayHeight, etc.)
	
--------------------------------------------------
Subject: 36)+ How do I determine the name of an existing widget?
I have a widget ID and need to know what the name of that widget is.

	You can use this simple bit of code to do what you want. Note that it
depends on the widget's internal data structures and may not be portable to
future versions of Xt; the same functionality may be provided in the future by
some other function.

	#include <X11/CoreP.h>
	String XtNameFromWidget (widget)
	Widget widget;
	{
	return widget->core.name;
	}

[6/90]

--------------------------------------------------
Subject: 37)* Why do I get a BadDrawable error drawing to XtWindow(widget)?
I'm doing this in order to get a window into which I can do Xlib graphics
within my Xt-based program:

> canvas = XtCreateManagedWidget ( ...,widgetClass,...) /* drawing area */
> ...
> window = XtWindow(canvas);	/* get the window associated with the widget */
> ...
> XDrawLine (...,window,...);	/* produces error */

	The window associated with the widget is created as a part of the 
realization of the widget.  Using a window id of NULL ("no window") could 
create the error that you describe.  It is necessary to call XtRealizeWidget() 
before attempting to use the window associated with a widget. 
	Note that the window will be created after the XtRealizeWidget() call, 
but that the server may not have actually mapped it yet, so you should also 
wait for an Expose event on the window before drawing into it.

--------------------------------------------------
Subject: 38) Can XGetWindowAttributes get a window's background pixel/pixmap?

	No.  Once set, the background pixel or pixmap of a window cannot be 
re-read by clients.  The reason for this is that a client can create a pixmap,
set it to be the background pixmap of a window, and then free the pixmap. The 
window keeps this background, but the pixmap itself is destroyed.  If you're 
sure a window has a background pixel (not a pixmap), you can use XClearArea() 
to clear a region to the background color and then use XGetImage() to read 
back that pixel.  However, this action alters the contents of the window, and 
it suffers from race conditions with exposures. [courtesy Dave Lemke of NCD 
and Stuart Marks of Sun]

	Note that the same applies to the border pixel/pixmap. This is a 
(mis)feature of the protocol which allows the server is free to manipulate the
pixel/pixmap however it wants.  By not requiring the server to keep the 
original pixel or pixmap, some (potentially a lot of) space can be saved. 
[courtesy Jim Fulton, MIT X Consortium]

--------------------------------------------------
Subject: 39) Why does the pixmap I copy to the screen show up as garbage? 

	The initial contents of pixmaps are undefined.  This means that most
servers will allocate the memory and leave around whatever happens to be there 
-- which is usually garbage.  You probably want to clear the pixmap first using
XFillRectangle() with a function of GXcopy and a foreground pixel of whatever 
color you want as your background (or 0L if you are using the pixmap as a 
mask). [courtesy Dave Lemke of NCD and Stuart Marks of Sun]

--------------------------------------------------
Subject: 40)* Why doesn't my program get the keystrokes I select for?

	The window manager controls how the input focus is transferred from one
window to another.  In order to get keystrokes, your program must ask the
window manager for the input focus.  To do this, you must set up what are
called "hints" for the window manager.  If your applications is Xlib-based, you
can use something like the following:

        XWMHints wmhints;
        ...
        wmhints.flags = InputHint;
        wmhints.input = True;
        XSetWMHints(dpy, window, &hints)


If your application is based on the Xt Intrinsics, you can set the XtNinput 
resource to be True (as you probably want to in any case); if you don't have
source, you can start up the application with the resource '*input:True'.

Certain window managers, notably dxwm and olwm, are very picky about having 
this done.

[mostly courtesy Dave Lemke of NCD and Stuart Marks of Sun]

--------------------------------------------------
Subject: 41) How can my application iconify itself?

	The ICCCM provides a mechanism for this; your application sends a
client message which includes a data value indicating that it wishes to be
iconified.  Here is a sample callback that will iconify the application shell, 
wait 3 seconds, and pop it back up. Note that ApplicationShellWidget below
is global; it would make more sense in real use to walk up the tree via 
XtParent() to find the shell containing the active widget.

   void IconifyShell(w, d1, d2)
        Widget w;
        caddr_t d1, d2;
   {
     XClientMessageEvent event;
     Window win;
     Display *dpy;

     event.type = ClientMessage;
     event.send_event = True;
     dpy = event.display = XtDisplay(w);
     win = event.window = XtWindow(ApplicationShellWidget);
     event.message_type = XInternAtom(dpy, "WM_CHANGE_STATE", False);
     event.format = 32;
     event.data.l[0] = IconicState;
     XSendEvent(dpy, DefaultRootWindow(dpy), False,
                SubstructureRedirectMask | SubstructureNotifyMask, &event);
     XFlush(dpy);
     sleep(3);
     XMapWindow(dpy,win);
   }

[courtesy David Brooks (dbrooks@osf.osf.org), 4/90]

R4 users may find it easier to use this routine:

    /*
     * This function instructs the window manager to change this window from
     * NormalState to IconicState.
     */
    Status XIconifyWindow (dpy, w, screen)
        Display *dpy;
        Window w;
        int screen;

[courtesy Jim Fulton, MIT X Consortium, 6/90]

--------------------------------------------------
Subject: 42) How do I check whether a window ID is valid?
My program has the ID of a window on a remote display. I want to check whether
the window exists before doing anything with it.

	Because X is asychronous, there isn't a guarantee that the window would
still exist between the time that you got the ID and the time you sent an
event to the window or otherwise manipulated it. What you should do is send
the event without checking, but install an error handler to catch any BadWindow
errors, which would indicate that the window no longer exists. This scheme
will work except on the [rare] occasion that the original window has been
destroyed and its ID reallocated to another window.

[courtesy Ken Lee (klee@wsl.dec.com), 4/90]

--------------------------------------------------
Subject: 43)+  Can I have two applications draw to the same window?

	Yes. The X server assigns IDs to windows and other resources, and any
application that knows the ID can manipulate the resource.
	The problem you face is how to disseminate the window ID to multiple 
applications. A simple way to handle this (and which solves the problem of the
applications' running on different machines) is in the first application to 
create a specially-named property on the root-window and put the window ID into 
it. The second application then retrieves the property, whose name it also
knows, and then can draw whatever it wants into the window.
	[Note: this scheme works iff there is only one instance of the first
application running, and the scheme is subject to the limitations mentioned
in the Question about using window IDs on remote displays.]
	[Note also that you will still need to coordinate any higher-level 
cooperation among your applications.]

[mostly courtesy Phil Karlton (karlton@wpd.sgi.com) 6/90]

--------------------------------------------------
Subject: 44) Why can't I set the backgroundPixmap resource in my defaults file?
I want to be able to do something like this:
	xclock*backgroundPixmap:      /usr/include/X11/bitmaps/rootweave

	You can't do this. The backgroundPixmap resource is a pixmap of the 
same depth as the screen, not a bitmap (which is a pixmap of depth 1). Because 
of this, writing a generic String to Pixmap converter is impossible, since 
there is no accepted convention for a file format for pixmaps. Therefore, 
neither the X Toolkit or the Athena widget set define a String to Pixmap 
converter; because there is no converter you cannot specify this value as a 
resource.

	The Athena widget set does define a String to Bitmap converter for use 
in many of its widgets, however.

[courtesy Chris D. Peterson (kit@expo.lcs.mit.edu), 4/90]

	[Note: the leading general-purpose format for pixmaps is the XPM format
used by Groupe Bull in several of its programs, including the GWM window 
manager, by AT&T in its olpixmap editor, and by ICS in its interface builder. 
XPM is being now handled by Richard Hess (rhess@cimshop.uu.net). The
XPM distribution, available on expo as contrib/xpm.tar.Z, includes read/write
routines which can easily be adapted to converters by new widgets which want
to allow specification of pixmap resources in the above manner.]

--------------------------------------------------
Subject: 45) Why does the R3 xterm, et al, fail against the R4 server?

	The value given to a window's do_not_propagate mask is the likely 
culprit.  R3 allowed bogus values to be set, and early version of both Andrew 
and Interviews did, as well. Similar problems also occur in the R3 Motif
PanedWindow widget.

	If it is impossible to fix client source, use 'xset bc' to put the 
X11R4 server into bug-compatibility mode.

--------------------------------------------------
Subject: 46)+  Does Motif work with X11R4?

	Applications based on OSF/Motif 1.0 will run against an R4 server if it
is set to bug-compatibility mode or if a patch to the XmPanedWindow is obtained.

	Applications based on OSF/Motif 1.0 can be built or linked on a system 
with X11R4 libraries provided that the Motif version of the R3 Intrinsics is 
used; the R4 Xt should not be used with Motif 1.0 programs.

	Motif 1.1, available in source form from OSF in August, uses the 
"vanilla" X11R4 Intrinsics, where "vanilla" means "with just a few patches".

--------------------------------------------------
Subject: 47)* Where can I obtain alternate language bindings to X?

	Versions of the CLX Lisp bindings are part of the X11R3 and X11R4 core 
source distributions. The latest version of CLX (R4.1) is available from expo 
for ftp as contrib/CLX.R4.1.tar.Z [Chris Lindblad (cjl@AI.MIT.EDU), 4/90];
this version fixes bugs reported against the R4 distribution.

	Ada bindings were written by Mark Nelson and Stephen Hyland at SAIC 
for the DOD. The bindings can be found on hapo.sei.cmu.edu or on 
wsmr-simtel20.army.mil and are also in the Ada Software Repository (ASR). 
R3 bindings should be available by the end of 1/90. [1/90]

	Prolog bindings (called "XWIP") written by Ted Kim at UCLA while
supported in part by DARPA are available by anonymous FTP from
expo.lcs.mit.edu:contrib/xwip.tar.Z or ftp.cs.ucla.edu:pub/xwip.tar.Z.
These prolog language bindings depend on having a Quintus-type foreign function
interface in your prolog. The developer has gotten it to work with Quintus and 
SICStus prolog. Inquiries should go to xwip@cs.ucla.edu. [3/90]

	GHG is developing X bindings and a complete Ada re-implementation
of X; check Lionel Hanley at 713-488-8806. [4/90]

	Ada bindings to Motif, explicitly, will eventually be made available by
the Jet Propulsion Laboratories, probably through the normal electronic
means.  Advance information can be obtained from dsouleles@dsfvax.jpl.nasa.gov,
who may respond as time permits.

-- 

The X User's Group		xug@expo.lcs.mit.edu	+1 617 547 0634
"No, I'm a member of the X User's Group, not the Ex-User's Group."


From ucla-cs!usc!ucsd!hub.ucsb.edu!hub.ucsb.edu!aks Thu Jul  5 22:47:23 PDT 1990
Article: 24692 of comp.windows.x
Path: ucla-cs!usc!ucsd!hub.ucsb.edu!hub.ucsb.edu!aks
From: aks@iti.org (Alan Stebbens)
Newsgroups: comp.sys.dec,comp.windows.x
Subject: How to install new fonts?
Summary: This is a query on the correct procedure to install a new font
Keywords: Fonts X
Message-ID: <5896@hub.ucsb.edu>
Date: 6 Jul 90 02:20:57 GMT
Sender: news@hub.ucsb.edu
Organization: CCSE, Univ. of CA, Santa Barbara
Lines: 26
Xref: ucla-cs comp.sys.dec:3712 comp.windows.x:24692
Status: O

I have just obtained the marumoji fonts, and am trying to install them
on my DECstation 3100.  Perhaps I'm being dense and having _perused_ TFM,
but here's what I've tried:

a. Installed font file "maru14.bdf" in /usr/lib/X11/fonts/local.
b. Ran "dxfc" on "maru14.bdf" to make "maru14.pcf"
c. Ran "dxmkfontdir /usr/lib/X11/fonts/local" to build "fonts.dir"
   with the new maru14.pcf in it; it seemed to work.
d. Verified that /usr/lib/X11/fonts/local is in the font path, by querying
   with "xset -q".
e. Set the font path, just in case the "fonts.dir" files are read only
   once, when the path is first set.
f. Queried again to be sure I didn't trip over something.

However, "xlsfonts" doesn't seem to find the fonts.

What am I doing wrong?

Thanks for any help. 
(Please reply via email unless you think your answer will benefit the
entire net).

Alan Stebbens <aks@hub.ucsb.edu>
--

Alan Stebbens <aks@hub.ucsb.edu>


From ucla-cs!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!uc!shamash!caffeine!dtj Fri Jul 13 11:02:06 PDT 1990
Article: 24996 of comp.windows.x
Path: ucla-cs!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!uc!shamash!caffeine!dtj
From: dtj@caffeine.cray.com (Dean Johnson)
Newsgroups: comp.windows.x
Subject: Re: What is Saber C?
Keywords: X11r4,sun.cf,SaberC
Message-ID: <7364@caffeine.cray.com>
Date: 13 Jul 90 04:47:07 GMT
References: <660@attila.esa.oz> <11271@hydra.gatech.EDU>
Organization: Cray Research Inc. - Mendota Heights, Minnesota
Lines: 40
Status: O

#include <std/disclaimers.h>

In article <11271@hydra.gatech.EDU> rhoward@msd.gatech.edu (Robert L. Howard) writes:
>I just built X11 r4 (successfully) but have a question about the
>variable HasSaberC in the file ./mit/config/sun.cf.  There is a 
>line that reads:
>
>#define HasSaberC	YES	/* for machines that have it */
>
>Well, what is Saber C and do I have it?  (Sun SparcStation 1, SunOS 4.1)

I quote from a Saber-C pamphlet,

	"Saber-C is a powerful C programming environment with an integrated
	set of tools for programming, debugging, testing and maintaining
	code..."

It includes,

	1. State and run-time error detection.
	2. Incremental linker/loader
	3. Graphical browsers
	4. Extensible source-level debugger
	5. Interactive workspace
	6. Integrated editing

>Do I want to get it?  I left the answer at yes, but was that correct and
>will that cause me any trouble later?

You don't need it, but it seems to be quite desirable to have around. You
can get info on Saber-C at,

	Saber Software Inc.
	185 Alewife Brook Parkway
	Cambridge, MN 02138
	(617) 876-7636

I shouldn't cause you any problems in your builds.

	-Dean


From ucla-cs!usc!ucsd!ucbvax!ucbvax.berkeley.edu!thewalt Sun Jul 15 17:12:40 PDT 1990
Article: 25095 of comp.windows.x
Path: ucla-cs!usc!ucsd!ucbvax!ucbvax.berkeley.edu!thewalt
From: thewalt@skylark.berkeley.edu (C. Thewalt)
Newsgroups: comp.windows.x
Subject: Re: seeking R4 help with DECstation 5000/200PX and Ultrix 4.0
Message-ID: <THEWALT.90Jul15140848@skylark.berkeley.edu>
Date: 15 Jul 90 21:08:48 GMT
References: <1990Jul15.141006.24018@godot.RadOnc.UNC.EDU>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: Dept. of Civil Engineering, University of California, Berkeley
Lines: 32
In-reply-to: sherouse@godot.RadOnc.UNC.EDU's message of 15 Jul 90 14:10:06 GMT
Status: O

In article <1990Jul15.141006.24018@godot.RadOnc.UNC.EDU> sherouse@godot.RadOnc.UNC.EDU (George W. Sherouse) writes:
   We have encountered (only!) two problems installing R4 on the
   above-mentioned equipment, one expected and the other not.
   1) The mutant industrial R2ish DECwindows server, while impressively
   fast, does not fit well in our otherwise R4 shop.  Fonts in particular
   are a real problem.  Where can I go for an R4 server for this beast?

Why buy a PX and then not use the DEC server?  The font problem is
easily solved by filling /usr/lib/X11/fonts/MIT with the .pcf files
generated from using dxfc on the MIT .bdf files.  Then use dxmkfontdir
and add FILE_NAME_ALIASES to fonts.alias and you're all set (this
directory is on the servers font path).

   2) Xterm fails to build under Ultrix 4.0.  The compiler chokes on
   statements of the form
	   fileno(stderr) = something;
   claiming illegal lhs.  There is one such statement in each of main.c
   and misc.c.  I'm not real clear on what the author is up to here so am
   reluctant to just start twiddling it.  Any clues would be appreciated.

In the 4.0 UWS release notes (pg 1-6) DEC talks about MIT clients and
says that you have to change fileno(stderr) on the lhs of an
expression to stderr->_file.  This apparently comes about because of
POSIX requirements.

Chris

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Christopher Robin Thewalt               These opinions are not necessarily
thewalt@euler.berkeley.edu              shared by my employer...
University of California, Berkeley


From ucla-cs!usc!cs.utexas.edu!uunet!wang!wdr Tue Jul 17 14:52:36 PDT 1990
Article: 25176 of comp.windows.x
Path: ucla-cs!usc!cs.utexas.edu!uunet!wang!wdr
From: wdr@wang.com (William Ricker)
Newsgroups: comp.windows.x,comp.software-eng,comp.cog-eng
Subject: Re: User Interface Design
Message-ID: <apy0yv.gv7@wang.com>
Date: 17 Jul 90 18:35:15 GMT
References: <817@agcsun.UUCP>
Followup-To: comp.cog-eng
Organization: Wang Labs, Lowell MA, USA
Lines: 49
Xref: ucla-cs comp.windows.x:25176 comp.software-eng:4043 comp.cog-eng:1745
Status: O

marks%agcsun.UUCP@boulder.colorado.edu (Mark Shepherd) writes:

>Where can I find out how to design a user interface
>What are some good books to read?
Don Norman, /Design of Everday Things/ (Paberback) or /Psychology of
    Everyday Things/ (hardback), 1988-1990.
Edward Tufte, /Envisioning Information/ 1990 ($48 ppd from Graphic
    Press, PO Box 430, Cheshire Conn. 06410), and if into statistical
    graphics, his earlier cult classic, /Visual Display of Quantitative 
    Information/, 1983? ($36 ppd Graphic Press).
More directly prescriptive is IBM's SAA/CUA user interface standard
    for OS/2 and Windows  applications, which has replaced the
    Microsoft windows style guide in new shipments of Windows SDK and
    (presumably) OS/2 SDKs (if they still exist).  If you need some
    simple advice on what users expect and such, this is a practical
    place to start -- but also get the above two too, to see the "why"s 
    and also to learn how to make exceptions to the IBM rules, since
    they're not general case fool proof by any means, and take some 
    experience or taste to interpret.
Any good book on color theory (eg, Albers, Yale, 1975; Itten, VNR,
    1961).
Smith et al at MITRE produced a checklist for human-factors for
    interface design in the 80's.  If you have access to the Nat'l
    Tech. Info. Service, you can order a copy or microfiche
    (cheaper). I can look up the # at home on request. (I should
    bring it in to the office soon anyway!)
    ?? What do people thing of this document, and has it been
    improved upon elsewhere??
    
>Are there courses I can go to?
Industrial Design classes are taught at some universities.  I hope
    there are courses on Human Factors at schools now, but I don't know
    where.  
The ACM SIGCHI (Special Interest Group: Computer and Human Interaction) 
    has an annual conference, last was April '90.  Your local ACM 
    chapter could tell you if there is a local SIGCHI chapter which 
    might host local presentations.  You should be able to order
    back-issues of previous proceedings from ACM HQ in NY.


>Are there UseNet newsgroups I should subscribe to?
comp.cog-eng [COGnitive ENGineering, an almost synonym for CHI and
HumFac for this field of research/consulting] is occasionally interesting,
but frequently needs to be stired up, so I'm cross posting this
there, and redirecting followups.
-- 
/bill ricker/
wdr@wang.com a/k/a wricker@northeastern.edu
*** Warning: This account not authorized to express opinions ***


From ucla-cs!william@oahu.cs.ucla.edu Thu Jul 19 15:15:08 PDT 1990
Article: 25287 of comp.windows.x
Path: ucla-cs!william@oahu.cs.ucla.edu
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: Tgif-1.10 (Xlib based 2-D drawing tool) is available on expo ...
Keywords: draw, tool, postscript, latex, hierarchical, x11, xlib, wysiwyg
Message-ID: <37128@shemp.CS.UCLA.EDU>
Date: 19 Jul 90 21:07:12 GMT
Sender: news@CS.UCLA.EDU
Followup-To: william@cs.ucla.edu
Organization: UCLA Computer Science Department
Lines: 3021
Status: RO

I've just put tgif-1.10 in the following places for anonymous ftp:

	expo.lcs.mit.edu	contrib/tgif-1.10.tar.Z
	rye.cs.ucla.edu		pub/tgif-1.10.tar.Z

Here's a short list of added features/bug fixes.

1) Fix bugs reported by Michael Webb regarding reading very long polygline.
2) Disallow stretching of zero width or zero height objects.
3) Add feature:  Add points and delete points to poly and splines.
4) In case of emergency, save working file in EmergencySave.obj or
   EmergencySave.sym.  (Thanks to Stephen Doyle and Christos Zoulas.)
5) Add XDefault "Tgif*Synchronize" call XSynchronize ().
6) Add -p command line option to prtgif to print encapsulated PostScript
   file.  (Thanks to Stephen Doyle.)

The following patch file takes tgif from version 1.9 to 1.10.
---------------------------------> cut here <---------------------------------
--

-- Bill Cheng // UCLA Computer Science Department // (213) 206-7135
   3277 Boelter Hall // Los Angeles, California 90024 // USA
   william@CS.UCLA.EDU      ...!{uunet|ucbvax}!cs.ucla.edu!william


From ucla-cs!usc!sdd.hp.com!ucsd!ucbvax!bloom-beacon!EXPO.LCS.MIT.EDU!swick Thu Jul 19 23:34:25 PDT 1990
Article: 25291 of comp.windows.x
Path: ucla-cs!usc!sdd.hp.com!ucsd!ucbvax!bloom-beacon!EXPO.LCS.MIT.EDU!swick
From: swick@EXPO.LCS.MIT.EDU (Ralph R. Swick)
Newsgroups: comp.windows.x
Subject: X11R4 public fixes #13 and #14 now available on expo [get both]
Message-ID: <9007191535.AA00995@expo.lcs.mit.edu>
Date: 19 Jul 90 15:35:38 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 41
Status: O

Patches for a variety of problems in Xt are now available via anonymous ftp
or the xstuff mail archive server on expo.lcs.mit.edu (18.30.0.212).  This is
a 2 volume set: make sure that you apply both fix 13 and 14 before rebuilding.

These patches fix the following problems:

    Make accelerator resources shareable
    Re-register key and button grabs when translation tables are modified
    Allow translation tables to include new-lines in action parameters
    Make XtAugmentTranslations really augment after fix #12
    Allow an input callback to be registered for more than one condition
    Allow both DebugLibXt and ProfileLibXt to be YES in site.def
    Include DESTDIR in the default for XFILESEARCHPATH
    Small reductions in memory usage
    Performance improvements in resource conversion cache lookup
    Configure windows and change XSetWMSizeHints in correct order for old wm's
    Keep geometry hints in WM_SIZE_HINTS updated for old wm's
    Fix some portability problems

Fixes are available via anonymous ftp to expo.lcs.mit.edu (18.30.0.212), in
the directory /pub/R4/fixes/, in files with prefix "fix-".  The latest fixes
are "fix-13" and "fix-14".  Fixes get put on expo in batches at intervals only.
Fixes usually propagate to other distribution sites as well, so it may pay
to check at a nearer site first.

For those without ftp access, individual fixes can be obtained by mail by
sending a message to xstuff@expo.lcs.mit.edu.  In the usual case, the
message should have a subject line and no body, or a single-line body and
no subject, in either case the line looking like:
	send fixes 13
(e.g. to get fix 13).  To get a summary of fixes, make the line:
	index fixes
If you need help, make the line:
	help
Some mailers produce mail headers that are unusable for extracting return
addresses.  If you use such a mailer, you won't get any response.  If you
happen to know an explicit path, you can include a line like
	path foo%bar.bitnet@mitvma.mit.edu
or
	path zot!gzork!me@uunet.uu.net
in the body of your message, and the daemon will use it.


From ucla-cs!usc!apple!snorkelwacker!bloom-beacon!tekcrl.labs.tek.COM!toddb Thu Jul 19 23:35:25 PDT 1990
Article: 25295 of comp.windows.x
Path: ucla-cs!usc!apple!snorkelwacker!bloom-beacon!tekcrl.labs.tek.COM!toddb
From: toddb@tekcrl.labs.tek.COM
Newsgroups: comp.windows.x
Subject: Re: VEX ?
Message-ID: <9007191610.AA13057@zit.WV.TEK.COM>
Date: 19 Jul 90 16:10:43 GMT
References: <9007181416.AA02959@brokaw.LCS.MIT.EDU>
Sender: toddb%zit.wv.tek.com@relay.cs.net
Reply-To: toddb%tekcrl.labs.tek.com@relay.cs.net
Organization: The Internet
Lines: 30
Status: O

> Where can I find some documentation about VEX, the Video Extension to X ?

VEX was released to six alpha sites earlier this summer.  Currently,
we are working on the beta release which we expect to send out in August.
There are a few documents that are available now via anonymous ftp
from expo.lcs.mit.edu (18.30.0.212):

	VEX Your Hardware (a description of VEX)
	VEX Protocol and Encoding, version 5.8
	VEX Library, version 1.7
	Pleasing the Eye (an article in Unix Review)
	Windows and Video: Now They're Talking (an article in Computer
						Technology Review)

They are all in postscript format, contained in the file

	public/vex-papers.tar.Z

If you don't have ftp access to expo, I can send you the papers via
electronic mail.  If you are interested in the beta release, you should
also join the xvideo mailing list so that you will be aware when the
beta release and other papers are made available.  You can do this by
sending a mail message to xvideo-request@expo.lcs.mit.edu asking to
become a member of the list.
---------------
Usenet:       {ucbvax,decvax,allegra,uw-beaver,hplabs}!tektronix!crl!toddb
{CS,ARPA}net: toddb@tekcrl.labs.tek.com                              c--Q Q
US:           Todd Brunhoff; Visual Systems Lab; Tektronix, Inc.         `
              Box 500  MS 50-321, Beaverton OR 97077                     -
Phone:        (503) 627-1121


From ucla-cs!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!bacchus.pa.dec.com!shlump.nac.dec.com!shodha.dec.com!gsrc.dec.com!west Wed Jul 25 11:27:53 PDT 1990
Article: 25551 of comp.windows.x
Path: ucla-cs!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!bacchus.pa.dec.com!shlump.nac.dec.com!shodha.dec.com!gsrc.dec.com!west
From: west@gsrc.dec.com (Jim West (Stealth Contractor))
Newsgroups: comp.windows.x
Subject: Re: How to copy from depth 1 to depth n
Message-ID: <1472@shodha.dec.com>
Date: 25 Jul 90 15:26:22 GMT
Sender: news@shodha.dec.com
Organization: Digital Equipment Corporation
Lines: 60
Status: O


In article <114409@linus.mitre.org>, dsr@luke.mitre.org (Douglas S. Rand) writes...
>I'm a little stuck.  I can create a pixmap from a bitmap file
>with XReadBitmapData.  Great.  Now what do I do to create
>a pixmap with the same depth as my display but with the same
>bitmap data?  What I don't want to do (and the only alternative I 
>see) is to do a XGetImage and XGetPixel along with a separate
>XCreatePixmap (right depth).  Will someone please tell me
>I'm wrong (but be right about it OK? :) .
> 
>Douglas S. Rand 
>Internet:   <dsrand@mitre.org>
>Snail:	    MITRE, Burlington Road, Bedford, MA 
>Disclaimer: MITRE might agree with me - then again...
>Amateur Radio: KC1KJ

  The following code bits are in Ada but I think you'll get the idea.


  x.read_bitmap_file (
    status		=> status,
    display		=> display,
    drawable_id		=> root,
    file_name		=> file_name (1 .. file_name_len),
    width_return	=> width,
    height_return	=> height,
    bitmap_id_return	=> bitmap_id,
    x_hot_coord_return	=> hot_x,
    y_hot_coord_return	=> hot_y);

  x.create_pixmap (
    result	=> pixmap_id,
    display	=> display,
    drawable_id	=> root,
    width	=> width,
    height	=> height,
    depth	=> depth); -- default depth of screen

  x.copy_plane (
    display	    => display,
    src_drawable_id => bitmap_id,
    dst_drawable_id => pixmap_id,
    gc_id	    => gc,
    src_x_coord	    => 0,
    src_y_coord	    => 0,
    width	    => width,
    height	    => height,
    dst_x_coord	    => 0,
    dst_y_coord	    => 0,
    plane	    => 1); -- Here is where the magic is


----------------------------------------------------------------------
 Jim West                      |  The Schainker Converse
 west@gsrc.dec.com             |  to Hoare's Law :
                               |
 These are my opinions.        |   Inside every small problem
 Digital has no idea           |     is a larger problem struggling
 what I'm  saying.             |       to get out.
----------------------------------------------------------------------


From ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!uc!cs.umn.edu!dmshq!com50!pai!erc Fri Jul 27 23:36:24 PDT 1990
Article: 25637 of comp.windows.x
Path: ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!uc!cs.umn.edu!dmshq!com50!pai!erc
From: erc@pai.UUCP (Eric Johnson)
Newsgroups: comp.windows.x
Subject: Re: How to copy from depth 1 to depth n
Summary: XCopyPlane()
Keywords: bitmaps, pixmaps, images
Message-ID: <1369@pai.UUCP>
Date: 26 Jul 90 14:36:50 GMT
References: <114409@linus.mitre.org>
Organization: Boulware Technologies, Inc., Burnsville, MN
Lines: 53
Status: O

In article <114409@linus.mitre.org>, dsr@luke.mitre.org (Douglas S. Rand)writes:
> I'm a little stuck.  I can create a pixmap from a bitmap file
> with XReadBitmapData.  Great.  Now what do I do to create
> a pixmap with the same depth as my display but with the same
> bitmap data?  What I don't want to do (and the only alternative I 
> see) is to do a XGetImage and XGetPixel along with a separate
> XCreatePixmap (right depth). 
> 
> Douglas S. Rand 
> Internet:   <dsrand@mitre.org>
> Snail:	    MITRE, Burlington Road, Bedford, MA 
> Disclaimer: MITRE might agree with me - then again...

Here's a suggestion:

1) Create a pixmap of the proper size, but the same depth as the
drawable you want to display it on (e.g., the window you want to
show this image in). Create a Graphics Context (GC) for this pixmap.
DefaultDepth( display, screen ) can often give an acceptable value for
this depth.

2) Create your bitmap from data. What you'll get is a single-plane
depth pixmap.

3) Use XCopyPlane() to copy one plane from the single-plane
pixmap (your bitmap in #2) to the potentially multi-plane pixmap (created
in #1). Use the GC also created in #1:
	
        XCopyPlane( display,            /* display connection */
                single_plane_bitmap,    /* source drawable */
                multi_plane_pixmap,     /* destination drawable */
                gc,                     /* created in #1 */
                0, 0,                   /* source X, Y */
                width, height,          /* size of bitmap AND pixmap */
                0, 0,                   /* destination X, Y */
                0x01 );                 /* which plane to copy */

Note that your bitmap (really a Pixmap type) only has one plane. Your
destination pixmap may have many more planes (or one if on a monochrome
system).  So, you want to copy the one plane from the bitmap to the
pixmap.

For more information, you can check out Advanced X Window Applications
Programming, coming soon from MIS: Press (phone in USA: 1-800-MANUALS).

Hope this helps,
-Eric

-- 
Eric F. Johnson               phone: +1 612 894 0313    BTI: Industrial
Boulware Technologies, Inc.   fax:   +1 612 894 0316    automation systems
415 W. Travelers Trail        email: erc@pai.mn.org     and services
Burnsville, MN 55337 USA


From ucla-cs!william@oahu.cs.ucla.edu Mon Jul 30 19:13:52 PDT 1990
Article: 25764 of comp.windows.x
Path: ucla-cs!william@oahu.cs.ucla.edu
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: Tgif-1.11 (Xlib based 2-D drawing tool) is available on expo ...
Keywords: draw, tool, postscript, latex, hierarchical, x11, xlib, wysiwyg
Message-ID: <37505@shemp.CS.UCLA.EDU>
Date: 31 Jul 90 02:13:14 GMT
Sender: news@CS.UCLA.EDU
Followup-To: william@cs.ucla.edu
Organization: UCLA Computer Science Department
Lines: 2424
Status: RO

I've just put tgif-1.11 in the following places for anonymous ftp:

	expo.lcs.mit.edu	contrib/tgif-1.11.tar.Z
	rye.cs.ucla.edu		pub/tgif-1.11.tar.Z

Here's a short list of added features/bug fixes.

1) Fix bugs reported by Christos Zoulas regarding prtgif bounding box.
   Text objects was generating wrong boudning boxes.
2) When text objects are saved, its bounding boxes are also saved now.
   This fixes the problem in 1).  File version is bumped to 7!
3) Fix bugs in select.c (change calls to DelObj () to FreeObj ()).
   This caused segmentation faults when tgif is dbx-ed, it caused
   XError when not dbx-ed.
4) Prtgif is cleaned up to share functions with the tgif code.  (Turned
   out to be a lot of changes.)
5) Add double-clicking in selecting file names.  New Xdefaults
   Tgif*DoubleClickInterval (in milli-seconds) is added.

The following is the patch to take tgif from version 1.10 to 1.11.
---------------------------------> cut here <---------------------------------
--
Bill Cheng // UCLA Computer Science Department // (213) 206-7135
3277 Boelter Hall // Los Angeles, California 90024 // USA
william@CS.UCLA.EDU      ...!{uunet|ucbvax}!cs.ucla.edu!william


From ucla-cs!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!denali.wv.tek.COM!paulsh Tue Jul 31 19:10:28 PDT 1990
Article: 25815 of comp.windows.x
Path: ucla-cs!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!denali.wv.tek.COM!paulsh
From: paulsh@denali.wv.tek.COM (Paul Shearer)
Newsgroups: comp.windows.x
Subject: Re: Bug with imake (I think)
Message-ID: <9007311753.AA01310@denali.WV.TEK.COM>
Date: 31 Jul 90 17:53:50 GMT
References: <1244@sirius.ucs.adelaide.edu.au>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 119
Status: O


This is NOT an imake bug.

The mistake made below is a common one.  The user should remember the 
general rule that Make macros are all capitals and the cpp macros have
only the first letter capitalized.  Thus the convention is:

ALL_CAPITALS		this is a Makefile macro
FirstLetterCapital	this is a cpp macro to be set in configuration files

Remember that the Makefile is built from Imake.tmpl which expands the
following files in this order:

machine.cf
site.def
Project.tmpl
Imake.rules
Imakefile

The file that contains the defalut cpp macro "DefaultUserPath" is Project.tmpl.

The correct fix is to set the cpp macro in either your machine.cf file if
you want to change it only on your platform, or in site.def if you want to
change it in all platforms you are building at your site.

Thus see the fix below:

> In my continuous quest to make X happily live in /usr/local/... (and
> to install the various fixes) I have run into what looks like a bug.
> 
> In mit/clients/xdm/Imakefile there is a section of "code"
> 
> /**/#
> /**/# Special definitions for compiling default resources; these parameters
> /**/# should be set in util/imake.includes/site.def or the appropriate .macros
> /**/# file in that directory.  The lack of initial spaces is to prevent imake
> /**/# from accidently turning the lines into rules by putting a leading tab.
> /**/#
> /**/# Do NOT change these lines!
> /**/#
> DEF_SERVER = $(BINDIR)/X
> DEF_USER_PATH = DefaultUserPath         /* no leading spaces or imake will */
> DEF_SYSTEM_PATH = DefaultSystemPath     /* indent as rule */
> BOURNE_SHELL = DefaultSystemShell
> CPP_PROGRAM = CppCmd
> 
> When you try adding #define's to site.def to set these values, such as
> 
> #ifndef DEF_USER_PATH
> #define DEF_USER_PATH ":/usr/bin:/usr/local/bin/X11:/usr/ucb:/usr/local/bin"
> #endif
> #ifndef DEF_SYSTEM_PATH
> #define DEF_SYSTEM_PATH "/etc:/usr/bin:/usr/local/bin/X11:/usr/ucb:/usr/local/bin"
> #endif
> 

No, the correct fix is to define the cpp macro, not the Makefile macro.
If you do this in site.def it will override the MIT defaults provided in
the file Project.tmpl which is expanded after site.def.  If someone on a 
platform at your site defines them differently in their machine.cf file
they will get their definitions, since machine.cf is expanded before
site.def.

#ifndef DefaultUserPath
#define DefaultUserPath ":/usr/bin:/usr/local/bin/X11:/usr/ucb:/usr/local/bin"
#endif
#ifndef DefaultSystemPath
#define DefaultSystemPath "/etc:/usr/bin:/usr/local/bin/X11:/usr/ucb:/usr/local/bin"
#endif


The Makefile below gave the following results because the real default 
cpp macros on the right of the = were defined in Project.tmpl and you
incorrectly defined the Makefile Macro on the left of the = in your
site.def.

> The resulting Makefile (after make World) gives
> 
> #
> # Special definitions for compiling default resources; these parameters
> # should be set in util/imake.includes/site.def or the appropriate .macros
> # file in that directory.  The lack of initial spaces is to prevent imake
> # from accidently turning the lines into rules by putting a leading tab.
> #
> # Do NOT change these lines!
> #
> DEF_SERVER = $(BINDIR)/X
> ":/usr/bin:/usr/local/bin/X11:/usr/ucb:/usr/local/bin" =
> :/bin:/usr/bin:$(BINDIR):/usr/ucb
> "/etc:/usr/bin:/usr/local/bin/X11:/usr/ucb:/usr/local/bin" =
> /etc:/bin:/usr/bin:$(BINDIR):/usr/ucb
> BOURNE_SHELL = /bin/sh
> CPP_PROGRAM = /lib/cpp
> 
> Which doesn't work (strangely enough). Since DEF_*_PATH are only used in
> resource.c (in that directory) I removed the definitions from site.def,
> but it means that I can't modify the default paths this way which is a pain.
> 
> Any suggestions?
> 
> Also if anyone has a list of places I should have modified to make X work
> Mark Prior                              Phone : +61 8 228 5680
> University Computing Services           Telex : UNIVAD AA89141
> University of Adelaide                  Fax   : +61 8 223 6245
> GPO Box 498 Adelaide S.AUSTRALIA 5001   E-mail: mrp@ucs.adelaide.edu.au



Paul Shearer
M.S. 61-049
Tektronix, Inc.
P.O. Box 1000
Wilsonville, OR
	 97070-1000

W (503) 685-2137
FAX (503) 682-1500
paulsh@orca.wv.tek.com
tektronix!orca!paulsh


From ucla-cs!usc!sdd.hp.com!elroy.jpl.nasa.gov!jpl-devvax!david Wed Aug  1 15:06:26 PDT 1990
Article: 25838 of comp.windows.x
Path: ucla-cs!usc!sdd.hp.com!elroy.jpl.nasa.gov!jpl-devvax!david
From: david@jpl-devvax.JPL.NASA.GOV (David E. Smyth)
Newsgroups: comp.windows.x
Subject: Re: Prototyping Tools for X11R4
Message-ID: <8950@jpl-devvax.JPL.NASA.GOV>
Date: 1 Aug 90 14:52:49 GMT
References: <78493@aerospace.AERO.ORG>
Reply-To: david@jpl-devvax.JPL.NASA.GOV (David E. Smyth)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 24
Status: O

In article <78493@aerospace.AERO.ORG> hancock@aeroaero.org (Melody F. Hancock) writes:
>
>I am developing a user interface using X11R4 and the Athena Widget
>set and I need a prototyping tool.  What academic or commercial
>products are available?  

Try the Widget Creation Library.  It builds an Athean resource interpeter.
Available via anonymous ftp from:

	expo.lcs.mit.edu	contrib/Wc1_02.tar.Z (current version)
				contrib/Wc1_03.tar.Z (in a day or two)
	devvax.jpl.nasa.gov	pub/Wc1_02.tar.Z (current version)
				pub/Wc1_03.tar.Z (in a day or two)

-------------------------------------------------------------------------
David Smyth				david@jpl-devvax.jpl.nasa.gov
Senior Software Engineer,		seismo!cit-vax!jpl-devvax!david
X and Object Guru.			(818)393-0983
Jet Propulsion Lab, M/S 230-103, 4800 Oak Grove Drive, Pasadena, CA 91109
--------------------------- Quote of the Day: ---------------------------
   "A Guru is not one who simply knows all the answers.  Rather, a
    Guru is like one who walks among the mountains, and by wandering
    around abit, can see the horizon through long narrow canyons."
-------------------------------------------------------------------------


From ucla-cs!usc!sdd.hp.com!decwrl!bacchus.pa.dec.com!wsl.dec.com!klee Wed Aug  1 15:22:25 PDT 1990
Article: 25843 of comp.windows.x
Path: ucla-cs!usc!sdd.hp.com!decwrl!bacchus.pa.dec.com!wsl.dec.com!klee
From: klee@wsl.dec.com (Ken Lee)
Newsgroups: comp.windows.x
Subject: Re: Signals and X--a problem
Message-ID: <1990Aug1.162845.23054@wrl.dec.com>
Date: 1 Aug 90 16:28:45 GMT
References: <1028@meaddata.mead.UUCP>
Sender: news@wrl.dec.com (News)
Reply-To: klee@wsl.dec.com
Organization: DEC Western Software Laboratory
Lines: 23
Status: O


In article <1028@meaddata.mead.UUCP>, marko@mead.UUCP (Mark Osbourne) writes:
|> The problem we're having seems to be that the Xlib functions to create
|> the request for the server are being interrupted by another signal.
|> The errors we end up getting are mostly bad request, but others like
|> bad drawable occasionally show up.

A few things you might try:

1.  Xlib has LockDisplay macros around critical sections of code.  You
could try defining these to block signals.

2.  Don't do Xlib things in your signal handlers.  Instead, set a flag
and do you X stuff afterwards.

3.  Open 2 server connections.  Do your normal X stuff on 1 connection
and your signal handler stuff on the other.  This assumes, of course,
that you can prevent signals handlers from interrupting each other.

Ken Lee
DEC Western Software Laboratory, Palo Alto, Calif.
Internet: klee@wsl.dec.com
uucp: uunet!decwrl!klee


From ucla-cs!william@oahu.cs.ucla.edu Thu Aug  2 09:43:21 PDT 1990
Article: 25886 of comp.windows.x
Path: ucla-cs!william@oahu.cs.ucla.edu
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: Tgif-1.12 (Xlib based 2-D drawing tool) is available on expo ...
Keywords: draw, tool, postscript, latex, hierarchical, x11, xlib, wysiwyg
Message-ID: <37618@shemp.CS.UCLA.EDU>
Date: 2 Aug 90 16:42:02 GMT
Sender: news@CS.UCLA.EDU
Organization: UCLA Computer Science Department
Lines: 155
Status: RO

I've just put tgif-1.12 in the following places for anonymous ftp:

	expo.lcs.mit.edu	contrib/tgif-1.12.tar.Z
	rye.cs.ucla.edu		pub/tgif-1.12.tar.Z

Here's a short list of added features/bug fixes.

1) Fix bugs related to stretching boxes and ovals.  It used to complain
   that object width or height is ZERO while it's not.
2) Fix a minor bug related to a seg fault when exiting tgif.  This doesn't
   really cause problem before.

The following is the patch to take tgif from version 1.11 to 1.12.
---------------------------------> cut here <---------------------------------

From ucla-cs!usc!samsung!uakari.primate.wisc.edu!sdd.hp.com!decwrl!bacchus.pa.dec.com!shlump.nac.dec.com!shodha.dec.com!gsrc.enet.dec.com!west Thu Aug  2 18:33:48 PDT 1990
Article: 25892 of comp.windows.x
Path: ucla-cs!usc!samsung!uakari.primate.wisc.edu!sdd.hp.com!decwrl!bacchus.pa.dec.com!shlump.nac.dec.com!shodha.dec.com!gsrc.enet.dec.com!west
From: west@gsrc.enet.dec.com (Jim West (Stealth Contractor))
Newsgroups: comp.windows.x
Subject: Re: What is PEX?
Message-ID: <1520@shodha.dec.com>
Date: 2 Aug 90 14:18:31 GMT
Sender: news@shodha.dec.com
Organization: Digital Equipment Corporation
Lines: 31
Status: O


In article <9008011637.AA05543@expo.lcs.mit.edu>, KONRAD@UCBCMSA.BITNET writes...

>But, what *is* PEX?   What is PHiGS?   Where can one read more about it?

  PHIGS stands for Programmer's Hierarchical Interactive Graphics System.
It is essentially a library of functions that simplifies the creation and
manipulation of 3D graphics.

  If you are familiar with 3D graphic systems from the internal point of
view you realize all the math involved with rendering 3D objects, shading,
lighting, etc.

  Normally all this work is done with software on most vendor platforms.  There
exist however, hardware platforms that can do the computations necessary for
3D graphics.  If these platforms are used via an X11 server then standard X
does not make use of these hardware features.  Thus PEX, PHIGS extension to
X.

  This server extension allows the client (PHIGS in this case) to take
advantage of the specialized hardware for 3D graphics.


----------------------------------------------------------------------
 Jim West                      |  The Schainker Converse
 west@gsrc.enet.dec.com        |  to Hoare's Law :
                               |
 These are my opinions.        |   Inside every small problem
 Digital has no idea           |     is a larger problem struggling
 what I'm  saying.             |       to get out.
----------------------------------------------------------------------


From ucla-cs!usc!sdd.hp.com!samsung!uunet!zephyr.ens.tek.com!orca.wv.tek.com!jeffg Mon Aug  6 08:47:41 PDT 1990
Article: 26011 of comp.windows.x
Path: ucla-cs!usc!sdd.hp.com!samsung!uunet!zephyr.ens.tek.com!orca.wv.tek.com!jeffg
From: jeffg@orca.wv.tek.com (Jeff C. Glover)
Newsgroups: comp.windows.x
Subject: Video Extension to X (VEX) papers available
Message-ID: <7935@orca.wv.tek.com>
Date: 5 Aug 90 00:28:26 GMT
Organization: Tektronix Inc., Beaverton, Or.
Lines: 30
Status: O

(reposted and paraphrased from the xvideo mailing list)

The Video Extension to X (VEX) is approaching a beta release in late
August.  In preparation for that event, a collection of papers has been
made available on expo.lcs.mit.edu for anonymous ftp.

	VEX Protocol and Encoding, version 5.9		(previous was 5.8)
	VEX Library, version 1.10			(previous was 1.7)
	VEX Devices and Controls, version 1.3		(new)
	VEX Your Hardware (a description of VEX)	(same as before)
	Pleasing the Eye (Unix Review)			(same as before)
	Windows and Video: Now They're Talking		(same as before)
	    (Computer Technology Review)

They are all in postscript format, contained in the ~268k file

	contrib/vex-papers.tar.Z

If you don't have ftp access to expo, you can receive the papers via
electronic mail by sending e-mail to vex-papers-request@amarok.wv.tek.com.
This mail address gets parsed by hand, so please be patient.

You should join the xvideo mailing list so that you will be aware when
the beta release and other papers are made available.  You can do this
by sending a mail message to xvideo-request@expo.lcs.mit.edu asking to
become a member of the list.
--
Jeff C. Glover, Tektronix                  @relay.cs.net: jeffg@orca.wv.tek.com
PO Box 1000, MS 61-049, Wilsonville, OR 97070      Graphics & Video Workstation
(503) 685-2207          Visualization Technologies, Visualization Systems Group


From ucla-cs!usc!snorkelwacker!bloom-beacon!CCSN01.CC.VANDERBILT.EDU!omar Thu Aug  9 00:20:59 PDT 1990
Article: 26148 of comp.windows.x
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!CCSN01.CC.VANDERBILT.EDU!omar
From: omar@CCSN01.CC.VANDERBILT.EDU (Omar Patino-Siliceo)
Newsgroups: comp.windows.x
Subject: RE: ioctl errors (xterm)
Message-ID: <9008081646.AA05926@ccsn01.cc.vanderbilt.edu>
Date: 8 Aug 90 16:46:28 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 19
Status: O


>>	xterm: Error 15, errno 25: Inappropriate ioctl for device

It seems that you are trying to build X11 using GNU CC. You need to
run  "fixincludes" from the GNU CC distribution before building X11.
fixincludes relocates some misplaced files and does other changes to
header files. This should take care of your problem. For more info,
you may check the ERRATA file in the X distribution tape.


<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
     ____   ____
    /    \  |   \     Omar Patino-Siliceo       Academic Computing Support
   |      | |    |    Box 1375, Station B       Computer Center
   |      | |__ /     Nashville, TN 37235       Vanderbilt University
    \    /  |  \
   __\  /__ |   \     Tel: (615) 343 1631       omar@ccsn01.cc.vanderbilt.edu     

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


From ucla-cs!usc!wuarchive!decwrl!ucbvax!bloom-beacon!eng.sun.COM!rogern Fri Aug 10 08:48:24 PDT 1990
Article: 26204 of comp.windows.x
Path: ucla-cs!usc!wuarchive!decwrl!ucbvax!bloom-beacon!eng.sun.COM!rogern
From: rogern@eng.sun.COM (Roger Nolan)
Newsgroups: comp.windows.x
Subject: Announcing OpenWindows Version 2
Message-ID: <9008091852.AA02779@bsox.Eng.Sun.COM>
Date: 9 Aug 90 18:52:46 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 255
Status: O


 

		ANNOUNCING OPENWINDOWS VERSION 2
		---------------------------------

On July 25, 1990, Sun Microsystems announced the immediate 
availability of OpenWindows Version 2.  This release represents a 
significant advancement in Sun's OPEN LOOK, networked window environment.
OpenWindows Version 2 is a major step forward in demonstrating
Sun's commitment to OPEN LOOK and to ease of use.

Open Windows Version 2 features an enhanced 3-D version of the
OPEN LOOK user interface, an enhanced and improved set of Deskset
Tools and greatly improved performance and quality.

Also, with this announcement, Sun is announcing that OpenWindows
Version 2 will be bundled with every SPARCstation IPC that ships
with a hard disk.

A Catalyst catalog focusing on over 100 OPEN LOOK applications is
also now available.


		Worldwide Product Announcement Information

 - Product Highlights: Enhancements to OpenWindows Version 2
	New features since OpenWindows 1.0

	o OpenWindows window performance is over 500% faster.  
	o X11R4 Compliance.  The X11/NeWS windows server has
	  been enhanced to be fully X11R4-compliant.
	o Improved Deskset Tools.  Deskset now includes 14 tools.
	  Additions include Calendar Manager, Print Tool, Tape Tool.
	o Optional 3-D Look & Feel for color systems.  The XView
	  toolkit now supports 3-D.  The Deskset Tools can also
	  now run with a 3-D look & feel.
	o Support for OPEN LOOK Intrinsics Toolkit (OLIT) which provides
	  intrisics support (based on XT+)
	o DECnet support.  OpenWindows can now run across
	  DECnet.
	o Dual Headed Server Support.  One instance of the X11/NeWS
	  Window Server can now display on two monitors.
	o Bundled XGL Runtime Libraries.  OpenWindows can run
	  advanced software applications utilizing XGL's 2-D and
	  3-D graphics libraries.
	o Support for SunVision.  Volumetric imaging applications
	  based on SunVision are supported in OpenWindows Version 2.
	o Improved overall quality and consistency.
	o Open Windows 2.0 will be bundled with all Sparcstations
	  beginning with the IPC.

   - Additional highlights related to the OPEN LOOK program:

	o New catalog with over 100 OPEN LOOK applications is available
	o Over 500 applications are in the process of being ported
	o OPEN LOOK will be available for IBM, HP, DEC, Mac, DOS, VAX
	o 35 system vendors have comitted to support and ship OPEN LOOK 
	o An ISV testimonial video tape is now available


 - Announcement Brief: Positioning

	o OPEN LOOK is UNIX and Networking made easy.

	o OpenWindows has serious application support
	  (See the Catalyst OPEN LOOK catalog of 100 applications)

	o OPEN LOOK is available on all the major platforms and is
       	  being ported to 35 non-Sun platforms.

	o OpenWindows Version 2 provides highly competitive performance

	o OpenWindows is a comprhensive development environment
	  substantially better than the competition.

OpenWindows is the window environment of the future for Sun.  Sun
is totally committed to SPARC/UNIX/ONC/OPEN LOOK. 

 - Features and Benefits: Contents Of OpenWindows Version 2

   The OPEN LOOK Graphical User interface. 
	OPEN LOOK is a generation ahead in graphical user
	interface design.  No other GUI makes the power of
	UNIX and networking accessable to non-technical end users 
	the way OPEN LOOK does.  The result is increased user
	productivity.

   The OpenWindows Deskset
	Deskset has been enhanced to include the following tools:

	File Manager		Calendar Manager
	Mail Tool		Print Tool
	Clock			Command Tool
	Performance Meters	UNIX C Shell Tool
	Text Editor		Binder Tool
	Snapshot Tool		Icon Editor
	Wastebasket		Calculator

	These tools support the OPEN LOOK drag & drop specification.
	This inter-application integration significantly leverages
	the personal productivity of the end user.

	Several of these tools are examples of how OPEN LOOK makes
	the network accessable to non-technical end users.  For 
	example, File Manager shows all the files on the network across
	multiple servers--not just your local file system.

   XView Toolkit
	o XView was designed to make migration from the kernal-based
	  SunView environment to the network-based XView environment
	  as easy as possible for developers.
	o XView now supports the 3-D look & feel.

   OPEN LOOK Intrinsics Toolkit (OLIT)
	o OLIT offers an industry-standard, intrinsics-based application
	  programmers interface for developers who want to develop applications
	  based on the emerging intrinsics API standard as defined by the MIT
	  X Consortium.
	o This is specifically usefull to developers who are standards-
	  conscious such as the federal government.

   tNT Toolkit (the NeWS toolkit)
	o tNt provides a way to create PostScript-based applications for
	  for the NeWS windows system
	o tNT provides the same consistent look and feel as the other
	  toolkits

   X11/NeWS Window Server
	o Now enhanced to be X11R4 compliant.
	o NeWS provides value-added with an integrated PostScript imaging
	  model.
	o Greatly improved performance.
	o Now supports dual monitors from a single instance of the server.
	o Network support now includes DECnet.

   OpenFonts Font Technology
	o OpenFonts provides the ability to generate fonts from a
	  hinted outline font definition.  The result is higher-quality
	  fonts with greater performance.
	o 57 fonts are bundled with Version 2 at no charge.
	o Over 700 fonts in this format are now available from major
	  third party font vendors.

   Graphics Integration
	OpenWindows now provides support for the following imaging models:

	o Xlib
	o NeWS (PostScript)
	o XGL.  High performance 2-D and 3-D graphics for technical 
	  applications.  XGL runtime libraries are bundled with Version 2.
	o SunVision.  Sun's environment for visualization applications.


 - OpenWindows Version 2 Performance

One of the major design goals of Version 2 was to dramatically improve
performance.  OpenWindows performance is now as fast as the kernal-based
SunView window system.
The following is a summary of advances over OpenWindows 1.0:

	o Window operations are over 500% faster on unaccelerated
	  frame buffers.
	o Window and graphics performance unaccelerated is competitive
	  with MIT X11R4 and with DECWindows running on a DEC 3100.
	o Graphics are faster with GX.  Using a GX, graphics performance
	  on Version 2 is twice as fast as DECWindows on a DEC 3100.
	o Applications run faster in less memory.  The server working
	  set has been reduced 45%.

- Software Applications Support

The software applications momentum for OPEN LOOK is clearly building:

	o There is now an OPEN LOOK Catalyst catalog that lists
	  100 applications that are committed to OPEN LOOK.
	o There are currently 50 OPEN LOOK applications shipping.
	o There are over 500 OPEN LOOK applications in development.
	o The August 1990 issue of Personal Workstation Magazine
	  lists the number of applications currently shipping for
	  some of the top workstation environments.  The results
	  are as follows:
		OPEN LOOK		50
		NeXTStep		23
		OS/2 PM			20
		Unix/Motif		16


	
- OPEN LOOK is Being Ported to 35 Platforms

   Announced availability of XView on non-Sun platforms

		DECstation port		Q2 FY'91 (Sun price listed)
		HP 9000/300 port	Q2 Fy'91 (Sun price listed)
		IBM RIOS port		Q2 FY'91 (Sun price listed)
		VMS (From TGV)		Q2 FY'91 (Not Sun price listed)

In addition, OPEN LOOK is being ported to MacIntosh, DOS and many other
platforms by third party software companies.
	
BENEFIT: Your can assure developers that applications they develop
for the XView Toolkit will run unaltered on these platforms.

Pricing/Ordering information for OPEN LOOK on non-Sun platforms
will be sent out in Q1 FY'91.



 - Contacts:

		LOU DELZOMPO	PLM OpenWindows
		SMITA DESHPANDE	Toolkits & Development Environment
		ROGER NOLAN	Windows Markting Programs



 - U.S. List Pricing

OpenWindows Version 2 order numbers and USA List Prices are as follows. Note
that pricing will vary by country throughout the world.

OpenWindows Version 2, Media & Manuals
	For SPARCsystem
		1/4" with NTSC Video	OWN-1.1-4-4-N5	$295
		1/4" with SECAM Video	OWN-1.1-4-4-S5	$295	
		1/4" with PAL Video	OWN-1.1-4-4-P5	$295

	For Sun-3
		1/4" with NTSC Video	OWN-1.1-4-3-N5	$295
		1/4" with SECAM Video	OWN-1.1-4-3-S5	$295
		1/4" with PAL Video	OWN-1.1-4-3-P5	$295

OpenWindows Version 2, Manuals Only
	Full Developer Set		OWN-1.1-X-X-9	$195
	End User Manuals		OWN-1.1-X-X-9U	$ 75

Note that NTSC, SECAM and PAL refer to video tape formats.  Each copy of
OpenWindows Version 2 comes with a video tape that shows how to install
the software.  Proper video formats are required for international use.  In
the USA please order NTSC.

NB: OpenWindows requires Graphics System Software when running on a GX graphics 
workstation. For operation under SunOS 4.1, order GFX-4.1-01 at no charge.  For 
operation under SunOS 4.0.3 order GFX-4.0.3-01 at no charge.

OpenWindows Version 2 is bundled with every diskfull SPARCstation IPC.  Note
that this is an end user version of OpenWindows, not the full development
environment.


 - Availability

OpenWindows Version 2 is shipping in volume now.
 


From ucla-cs!usc!elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!fedeva!premise!brian Mon Aug 13 17:37:03 PDT 1990
Article: 26288 of comp.windows.x
Path: ucla-cs!usc!elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!fedeva!premise!brian
From: brian@premise.ZONE1.COM (Brian Moran)
Newsgroups: comp.windows.x
Subject: X11 app for SPARC/DECstation FTPable
Keywords: DesignView, X11, CAE
Message-ID: <341@premise.ZONE1.COM>
Date: 10 Aug 90 18:15:36 GMT
Distribution: na
Organization: Premise, Inc., Cambridge, MA
Lines: 67
Status: O

SUBJECT: X11/Motif SPARC/DECstation application available for FTP
(This software is currently available on MIT's ATHENA as part of the mechanical
 engineering curriculum)

DesignView/UNIX is available for anonymous FTP from EDDIE.MIT.EDU
(18.62.0,6).  The files are located in the DesignView directory. The
file dv-SPARC.tar contains the SPARC executables and X11r4 for the
Sun SPARCstation, while dv-examples.tar.Z contains some sample files
for both versions.  The file dv-DECstation.tar contains the
DECstation 3100 files.

This version of DesignView is fully functional for at least 30 days
from the date of installation on your system.  During the
installation of DesignView on your machine, you will be given a
server code, which you must supply to Premise via our 800 number. You
will be given back an authorization key that will activate the
software on your machine and machines on your network.  If you are
installing on a network, please tell us that when you call so that we
can give you a code to activate multiple copies of DV.

If you have any questions/comments, you can contact Premise via email:

email:

	dv-unix@premise.zone1.com
	{..,mirror,mit-eddie}!premise!dv-unix


or more conventional means:

	Premise, Inc.
	Three Cambridge Center
	Cambridge, MA  02142
	(617) 225-0422
	(800) 888-7736

A brief description of DesignView follows:

{ this is file README.1st in the dv-SPARC.tar or dv-DECstation.tar archive }

	DesignView UNIX University/Industry Trial 

DesignView can best be described as an engineering sketchpad.  It is a
tool for students, engineers, and designers to use to draw
geometry, add constraints and equations describing interactions and
behaviors, thereby constructing models of physical and mechanical
reality.  These models can be analyzed, changed, and optimized by
moving geometry or changing equations.  It is a true "what-if" tool
for engineering. 

One of DesignView's strengths is its usability. DesignView uses X11 as its 
graphical user interface foundation; some users never even open our
award-winning manual.  Engineers have learned DesignView in one day, and
have solved previously unsolvable problems the next.  DesignView is 
also available for Microsoft Windows (under DOS) with a nearly identical 
user interface.


{ the file continues... }



-- 
Brian K. Moran    N9ADG   { ...harvard!mit-eddie,...!mirror}!premise!brian
Premise, Inc.             brian@premise.zone1.com 
3 Cambridge Center	  
Cambridge, MA 02142       (617) 225-0422          


From ucla-cs!usc!wuarchive!mit-eddie!bloom-beacon!eng.sun.COM!hvr Tue Aug 14 09:45:01 PDT 1990
Article: 26347 of comp.windows.x
Path: ucla-cs!usc!wuarchive!mit-eddie!bloom-beacon!eng.sun.COM!hvr
From: hvr@eng.sun.COM (Heather Rose)
Newsgroups: comp.windows.x
Subject: Announcment:  XView 2.0 source availability
Message-ID: <9008140209.AA23408@kimba.Eng.Sun.COM>
Date: 14 Aug 90 02:09:12 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 162
Status: O

The XView source donation, for those who may not already know, includes
the complete source for the XView toolkit, the OLWM window manager,
a number sample XView applications, and a collection of commercial-quality
Lucida bitmap fonts from Bigelow & Holmes.

What Is XView:
-------------
XView is an X toolkit based on the OPEN LOOK (tm) Graphical User
Interface (GUI).  XView's application programmer's interface (API) is very
similar to the API of the SunView toolkit; in practice, most SunView
applications can be converted to XView in a few days, although some
will take longer.  Since there are more than 2000 SunView applications,
we expect that releasing XView will immediately create a large base of
X11 applications.  To futher assist in converting SunView applications,
the R4 donation includes improved automated conversion tools and
documentation.  Additionally, XView provides both 2D and 3D-look 
OPEN LOOK graphical interfaces through the usage of a new OPEN 
LOOK graphics library (OLGX).

Changes to XView for Release 2:
------------------------------
For more complete list see the <XVIEW>/doc/relnotes.text and 
<XVIEW>/doc/rtf.text files.

	- new 3D-style OPEN LOOK appearance using OLGX library
	- multi-screen support
	- multi-server support
	- C++ and ANSI-C language bindings
	- additional OPEN LOOK features
	- documentation on creating new XView packages
	- changes and enhancements to the XView API
	- bug fixes  
	- simplified build environment for source

What is OLWM:
------------
OLWM is an ICCCM-compliant window manager, also based on the OPEN LOOK
GUI.  OLWM is a "stand-alone" window manager, not dependent on any
toolkit code.  We hope that OLWM will become the standard example of
an ICCCM-compliant window manager in X11 R4.  Additionally, OLWM 
provides both 2D and 3D-look OPEN LOOK graphical interfaces through
the usage of a new OPEN LOOK graphics library (OLGX).  OLGX is
written to the Xlib interface and does not use any toolkit.

What Libraries are Included:
---------------------------
	- XView			(XView user interface toolkit)
	- XVPS 			(NeWS/PostScript canvas package)
	- OLGX 			(OPEN LOOK Graphics for X)

What XView Applications are Included:
------------------------------------
	- clock
	- textedit		(graphical file editor)
	- cmdtool/shelltool 	(a terminal emulator)
	- props 		(root properties program)
	- xvbench 		(useful for testing ports of XView)  

In addition, we are including a script that helps convert SunView 
programs to XView by flagging the application code that needs to be 
changed and another tool which helps convert SunView ".defaults" 
files into ".Xdefaults" resource files.

What Contributed Clients are Included:
-------------------------------------
The examples from the XView Programmer's Manual from O'Reilly.
This includes over 70 simple example programs to show features in
each of the XView packages and three examples of new XView subclasses.

A perfdemo example which monitors performance on multiple hosts.  This
includes an example of creating a new XView panel item and how to use
XView with Sun's Light Weight process (LWP) library.

Examples using the new XView PostScript (XVPS) library extension to do
NeWS/PostScript imaging in an XView canvas.

What Fonts are Included:
-----------------------
The Bigelow & Holmes Lucida bitmap fonts are a collection of different
type styles and point sizes in the Lucida typeface.  In addition, XView
uses "glyph fonts" to accelerate the painting of some OPEN LOOK GUI
graphical elements, and these fonts are also being made available.
These glyph fonts are used extensively by OLGX to provide high
performance when rendering 2D and 3D-look OPEN LOOK graphics.  However,
only OLWM will be able to provide the 3D-look in this update. 
Note that these glyph fonts *MUST* be added to your X11 R3 server in
order to run XView applications.  These fonts are standard with all
R4 servers.

XView Source:
------------
With licensed source products from Sun, source is usually not released
until several months after a binary version of the product has
shipped.  The extra time is used to "clean up" the source for external
consumption.  In contrast, we are releasing XView and OLWM now, soon
after the binary version of XView (XView 2.0) has shipped.  We will
continue to fix bugs and portability problems as we find them, and
these changes will be made available periodically (this is just the
first).  

We are releasing this FCS version of the source at this time 
to accellerate the number of ports of XView, and to encourage the 
notion that X toolkit source should be free.  We will update this 
free source to track changes that Sun makes in XView, including 
bug fixes, performance improvements, and new features.  Sun has 
selected the MIT X11 distribution as our XView source distribution 
channel.  If you port XView to a new platform or make fixes to the
library, please send your code diffs for inclusion in a future
release to the bugs alias.

As ports of XView become available for other platforms, we will 
incorporate this work and include it in future source donations.  
As the Kanji version of XView becomes available, we will also 
integrate this work and donate the sources as well.   This initial 
release is to facilitate porting of XView to other platforms.  
Current ports in progress include the following platforms available
from the listed vendors:  

Platform			Vendor
------------------------------------------------
DEC Station			Sun Microsystems
HP 9000/300			Sun Microsystems
IBM RIOS			Sun Microsystems
DOS				Quarterdeck
AUX				ICS
VMS				TGV

Some vendors will sell XView on a particular hardware or OS 
base; others will donate their changes back to Sun for inclusion
with the publically available source.  We encourage both uses of 
this source donation.

XView Requirements:
------------------
XView requires the use of an ICCCM-compliant window
manager. One such window manager is olwm, which supports the OPEN
LOOK (TM) user interface.  Further, XView requires full ICCCM
support in Xlib. This is the standard in the X Window System
Version 11, Release 4. In order to run under Release 3, you must
define the PRE_R4_ICCCM compile-time flag (see config/XView.cf)
and the set resource, xview.icccmcompliant, to False in the
.Xdefaults file (see the xview man page).

Building the Release:
--------------------
To build XView, you only need the XView source release and installed
X11 header files and libraries.  All needed X11R4 configuration files
are included in the XView source.

More Information:
----------------
There is a second message which discusses how to report bugs, get
more help and what documentation is available.

Please direct comments or questions about this source donation to
xpert@expo.lcs.mit.edu (or comp.windows.x).


And thank you for your support,

		The XView Development Team
		Sun Microsystems, Inc.


From ucla-cs!usc!apple!bionet!snorkelwacker!spdcc!ima!haddock!padouk.ima.isc.com!brian Wed Aug 15 17:24:55 PDT 1990
Article: 26425 of comp.windows.x
Path: ucla-cs!usc!apple!bionet!snorkelwacker!spdcc!ima!haddock!padouk.ima.isc.com!brian
From: brian@padouk.ima.isc.com (Brian R. Holt)
Newsgroups: comp.windows.x,comp.windows.x.motif,alt.hypertext
Subject: Re: wanted: hypertext (X11, Motif)
Message-ID: <17414@haddock.ima.isc.com>
Date: 15 Aug 90 15:58:43 GMT
References: <3203@gmdzi.UUCP>
Sender: news@haddock.ima.isc.com
Reply-To: brian@ima.isc.com
Organization: Interactive Systems Corporation - Cambridge, MA
Lines: 19
Xref: ucla-cs comp.windows.x:26425 comp.windows.x.motif:571 alt.hypertext:534
Status: O

In article <3203@gmdzi.UUCP>, freitag@gmdzi.UUCP (Regine Freitag) writes:
|> Hi,
|> 
|> we are looking for a hypertext system running under UNIX (SUN3/4),
|> X11R4 and possibly Motif. If anyone knows of such a product or public
|> domain software, would you please mail me some more information about it
|> (including price if possible).

The Text Management Library (TMLib) is available free on
expo.lcs.mit.edu, if you have FTP access. If not, you might try
laporta@apollo.com. It is a complete extensible hypertext system 
(written in C++) for X. I believe it is look and feel independent.

		=brian

Email	brian@ima.isc.com	
Phone	617-661-7474 x206	
Fax	617-661-2070
near the last bend in the Charles River


From ucla-cs!usc!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!shelby!med!hanauma!rick Wed Aug 15 17:26:48 PDT 1990
Article: 26448 of comp.windows.x
Path: ucla-cs!usc!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!shelby!med!hanauma!rick
From: rick@hanauma.stanford.edu (Richard Ottolini)
Newsgroups: comp.windows.x,comp.windows.x.motif,alt.hypertext
Subject: Re: wanted: hypertext (X11, Motif)
Message-ID: <1969@med.Stanford.EDU>
Date: 15 Aug 90 22:09:17 GMT
References: <3203@gmdzi.UUCP> <17414@haddock.ima.isc.com>
Sender: news@med (USENET News System)
Followup-To: comp.windows.x
Organization: Stanford University, Department of Geophysics
Lines: 13
Xref: ucla-cs comp.windows.x:26448 comp.windows.x.motif:585 alt.hypertext:537
Status: O

In article <17414@haddock.ima.isc.com> brian@ima.isc.com writes:
>|> 
>|> we are looking for a hypertext system running under UNIX (SUN3/4),
>|> X11R4 and possibly Motif. If anyone knows of such a product or public
>|> domain software, would you please mail me some more information about it
>|> (including price if possible).

xTeX in the contrib section of XWindows has some hypertex features,
particularly interactivity, internal links, and procedural attachment.
Our group is using for "electronic books" where one can experiment with
the programs used to generate scientific figures.  xTeX is backwards
compatible with our large body of TeX documents, makes excellent hardcopy,
and the source is freely available.


From ucla-cs!usc!snorkelwacker!bloom-beacon!eng.sun.COM!hvr Thu Aug 16 10:03:43 PDT 1990
Article: 26481 of comp.windows.x
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!eng.sun.COM!hvr
From: hvr@eng.sun.COM (Heather Rose)
Newsgroups: comp.windows.x
Subject: New XView Release Now Available
Message-ID: <9008151532.AA27314@kimba.Eng.Sun.COM>
Date: 15 Aug 90 15:32:51 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 78
Status: O

Sorry for the confusion and inconvenience folks.  I placed new copies of
the XView 2.0 release in the previous places with the problem fixed.  
Here are the new ftp stats.

Regards,

Heather
--------------------------------------------------------------
Note:  this version does not have the previous problem with rm 
--------------------------------------------------------------

XView version 2.0 source release

	xview2-announce		announcement of XView sources
	xview2-more		follow up information for announcement
	xview2-ftp		this file
	xview2.tar.Z.a[a-i]	split compressed tar file pieces
	

FTP sites for XView source:

Location	Machine Name		ftp login	ftp directory
---------------------------------------------------------------------
west coast	xview.ucdavis.edu	ftp		pub/XView2.0/*
east coast	expo.lcs.mit.edu	ftp		pub/contrib/xview2*

When transfering a tar file via ftp, be sure to set binary mode first.
Files must be transfered in image mode (use the ftp "binary" and "mget" 
commands).  If you are doing an "mget" you'll probably want to use 
ftp with the "-i" option to prevent it from asking you about every file.
If you are already in ftp, can use the "prompt" command in ftp to turn off
interactive prompting.

Here are the sizes of those pieces:

      13139968  xview2.tar		tar file
       4132499  xview2.tar.Z		compressed tar file
        458986  xview2.tar.Z.aa
        591253  xview2.tar.Z.ab
        462536  xview2.tar.Z.ac
        445906  xview2.tar.Z.ad
        421463  xview2.tar.Z.ae
        401380  xview2.tar.Z.af
        515694  xview2.tar.Z.ag
        470038  xview2.tar.Z.ah
        365243  xview2.tar.Z.ai

BSD style checksums:
11240   449 xview2.tar.Z.aa
46425   578 xview2.tar.Z.ab
03598   452 xview2.tar.Z.ac
26340   436 xview2.tar.Z.ad
35148   412 xview2.tar.Z.ae
35248   392 xview2.tar.Z.af
10242   504 xview2.tar.Z.ag
42879   460 xview2.tar.Z.ah
02598   357 xview2.tar.Z.ai

System 5 style checksums:
4011 897 xview2.tar.Z.aa
29243 1155 xview2.tar.Z.ab
3557 904 xview2.tar.Z.ac
60406 871 xview2.tar.Z.ad
47957 824 xview2.tar.Z.ae
13752 784 xview2.tar.Z.af
5240 1008 xview2.tar.Z.ag
57041 919 xview2.tar.Z.ah
55245 714 xview2.tar.Z.ai

To recreate the compressed tar file, can do the following:

	% cat *.tar.Z.?? | uncompress | (cd /usr/local/src/xview; tar xvf - )

which create a directory called "xview2" in the directory /usr/local/src/xview.  
Can rename this to anything you like.  See the README file in that directory 
on how to begin building the XView source.

Unpacked XView source requires approximately 12.5+ MB of disk space.


From ucla-cs!usc!cs.utexas.edu!news-server.csri.toronto.edu!smoke.cs.toronto.edu!neat.cs.toronto.edu!moraes Thu Aug 16 10:04:47 PDT 1990
Article: 26486 of comp.windows.x
Path: ucla-cs!usc!cs.utexas.edu!news-server.csri.toronto.edu!smoke.cs.toronto.edu!neat.cs.toronto.edu!moraes
From: moraes@cs.toronto.edu (Mark Moraes)
Newsgroups: comp.windows.x
Subject: Re: HP widgets
Message-ID: <90Aug16.122344edt.635@smoke.cs.toronto.edu>
Date: 16 Aug 90 16:24:24 GMT
References: <6121@hub.ucsb.edu>
Distribution: comp
Organization: Department of Computer Science, University of Toronto
Lines: 4
Status: O

You can get a version of the HP widgets that works with R3/R4 from
contrib/toolkits/Xw in the R4 distribution, or as Xw.tar.Z from your
friendly neighbourhood X archive site.  (consult the Frequently Asked
Questions for a list of archive sites)


From ucla-cs!william@oahu.cs.ucla.edu Fri Aug 17 16:18:51 PDT 1990
Article: 26563 of comp.windows.x
Path: ucla-cs!william@oahu.cs.ucla.edu
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: Tgif-1.13 (Xlib based 2-D drawing tool) is available on expo ...
Keywords: draw, tool, postscript, latex, hierarchical, x11, xlib, wysiwyg
Message-ID: <38149@shemp.CS.UCLA.EDU>
Date: 17 Aug 90 21:20:35 GMT
Sender: news@CS.UCLA.EDU
Followup-To: william@cs.ucla.edu
Organization: UCLA Computer Science Department
Lines: 4694
Status: RO

I've just put tgif-1.13 in the following places for anonymous ftp:

	expo.lcs.mit.edu	contrib/tgif-1.13.tar.Z
	cs.ucla.edu		pub/tgif-1.13.tar.Z

Here's a short list of added features/bug fixes.

1) Fix a bug to set the font of the active cursor correctly when adding
   or deleting points.
2) Fix a bug for ``prtgif'' so that it works correctly when the page
   style is not portrait.
3) Every object can have attributes, and attribute's name field can be empty.
4) Add copy and paste operations.  Support copy and paste between multiple
   tgifs.  Thanks to Kouichi Matsuda@NEC in Japan for his contribution to
   the code.

The following is the patch to take tgif from version 1.12 to 1.13.
---------------------------------> cut here <---------------------------------

From ucla-cs!usc!wuarchive!mailrus!ncar!dinl!noren Wed Aug 22 08:39:51 PDT 1990
Article: 26652 of comp.windows.x
Path: ucla-cs!usc!wuarchive!mailrus!ncar!dinl!noren
From: noren@dinl.uucp (Charles Noren)
Newsgroups: comp.windows.x,comp.lang.c++
Subject: Re: C++ Browser
Message-ID: <1703@dinl.mmc.UUCP>
Date: 21 Aug 90 16:15:08 GMT
References: <1002@dcl-vitus.comp.lancs.ac.uk> <1504@kielo.uta.fi>
Reply-To: noren@dinl.UUCP (Charles Noren)
Organization: Martin Marietta I&CS, Denver CO.
Lines: 42
Xref: ucla-cs comp.windows.x:26652 comp.lang.c++:9338
Status: RO

In article <1504@kielo.uta.fi> av@uta.fi (Arto V. Viitanen) writes:
>In article <1002@dcl-vitus.comp.lancs.ac.uk>, graham@comp.lancs.ac.uk
>(Mr.G.Dean) writes:
>|> 
>|> 	Is there a C++ browser which runs with X11 ?? -
>|> I'd like to look at Inheritence graphs, object-relations
>|> etc. etc. - the one I've seen is "Objectworks" which runs
>|> under (I believe) Openlook for sun workstations. The problem
>|> is this comes complete with the AT&T compiler which I've
>|> already got. Any help/pointers would be useful - esp. PD stuff.
>|
>With InterViews comes iclass, class browser with list of classes in
>headerfiles of given directory and
>parents and sublclasses of selected class plus its definition from
>headerfile. iclass does not show any
>graphs.

The Brown University environment has a browser that is very nice.
It shows graphically the relationships between the classes.
Its available via ftp from Brown at [128.148.32.66].
Be sure the copy the files that have the instructions and restrictions
on copying their files, for you will have to get a password from
Brown to get their Field environment, which includes cbrowse, the
browser.

Brown has a very nice development environment.  While cbrowse is nice,
I like the Objective-C browser better.  The Objective-C browser is
a Smalltalk-like browser that allows you to browser CODE, not just
header files (like iclass) or recreated header information (like
cbrowse).  The Objective-C borwser, however, does not show graphical
relationships (not important to me, seeing the organization of the
classes textually is sufficient) or does not edit the code in the current
release of it (it also doesn't work on C++ code, which is either
good or bad depennding on your point of view ;-}).


-- 
Chuck Noren
NET:     dinl!noren@ncar.ucar.edu
US-MAIL: Martin Marietta I&CS, MS XL8058, P.O. Box 1260,
         Denver, CO 80201-1260
Phone:   (303) 971-7930


From ucla-cs!william@oahu.cs.ucla.edu Wed Aug 22 08:40:47 PDT 1990
Article: 26672 of comp.windows.x
Path: ucla-cs!william@oahu.cs.ucla.edu
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: Tgif-1.14 (Xlib based 2-D drawing tool) is available on expo ...
Keywords: draw, tool, postscript, latex, hierarchical, x11, xlib, wysiwyg
Message-ID: <38250@shemp.CS.UCLA.EDU>
Date: 22 Aug 90 04:59:02 GMT
Sender: news@CS.UCLA.EDU
Followup-To: william@cs.ucla.edu
Organization: UCLA Computer Science Department
Lines: 662
Status: RO

I've just put tgif-1.14 in the following places for anonymous ftp:

	expo.lcs.mit.edu	contrib/tgif-1.14.tar.Z
	cs.ucla.edu		pub/tgif-1.14.tar.Z

Here's a short list of added features/bug fixes.

1) Fix Imakefile so that it works better with the X11R4 installation.
   This includes commenting out BINDIR, CDEBUGFLAGS, and MANPATH.
   Thanks to David Eckelkamp@MCC and Carl Witty@Stanford for their
   recommentations, and specially David Eckelkamp@MCC for his improvements.

      NOTE:  With the current setup, those who wishes to install tgif
             in places outside of the X11R4 installation has to modify
             the Imakefile (uncomment the definition for CDEBUGFLAGS,
             BINDIR, MANPATH, and redefine TGIFDIR).  Sorry for the
             inconveniences.

2) Add support for 100dpi fonts.  (Actually, this was done in the previous
   release.  I forgot to mention it.)
3) Fix a small bug in display the current font (pixmap not cleared before).
4) Use XDrawPoint() instead of XDrawLine() in drawing grid points and
   rotated text.  Use the #ifdef construct to get around know server bugs.
5) Minor enhancement in cleaning up events in adding and deleting points.

The following is the patch to take tgif from version 1.13 to 1.14.
---------------------------------> cut here <---------------------------------

From ucla-cs!usc!samsung!uunet!kddlab!titcca!ccut!s.u-tokyo!hideki Wed Aug 22 08:41:42 PDT 1990
Article: 26685 of comp.windows.x
Path: ucla-cs!usc!samsung!uunet!kddlab!titcca!ccut!s.u-tokyo!hideki
From: hideki@is.s.u-tokyo.ac.jp (YOSHIDA Hideki)
Newsgroups: comp.lang.postscript,comp.windows.x
Subject: ralpage problem
Message-ID: <832@utsun.s.u-tokyo.ac.jp>
Date: 22 Aug 90 06:41:04 GMT
Sender: news@s.u-tokyo.ac.jp
Reply-To: hideki@is.s.u-tokyo.ac.jp
Followup-To: comp.lang.postscript
Distribution: comp
Organization: Dept. of Information Science, the Univ. of Tokyo, Japan.
Lines: 13
Xref: ucla-cs comp.lang.postscript:6235 comp.windows.x:26685
Status: O

I installed ralpage "version 1.5 with jgm/bzs mods v3" obtained from
sics.se on our Sun-4.  I find it fairly useful, but have a problem: PS
files produced by idraw with some text in it can not be processed by
ralpage --- it fails with "rangecheck in operator get".  Does somebody
know how to fix it?
---
					Yoshida Hideki

					Department of Information Science
					Faculty of Science
					The University of Tokyo

					hideki@is.s.u-tokyo.ac.jp


From ucla-cs!usc!cs.utexas.edu!sun-barr!newstop!sun!CS.UCLA.EDU Wed Aug 22 14:17:02 PDT 1990
Article: 770 of comp.sources.x
Path: ucla-cs!usc!cs.utexas.edu!sun-barr!newstop!sun!CS.UCLA.EDU
From: william@CS.UCLA.EDU (William Cheng)
Newsgroups: comp.sources.x
Subject: v08i094: tgif, Patch4, Part01/01
Message-ID: <141120@sun.Eng.Sun.COM>
Date: 22 Aug 90 07:03:23 GMT
Sender: news@sun.Eng.Sun.COM
Lines: 672
Approved: argv@sun.com
Status: O

Submitted-by: william@CS.UCLA.EDU (William Cheng)
Posting-number: Volume 8, Issue 94
Archive-name: tgif/patch4
Patch-To: Volume 7, Issue 56-76 (original: tgif-1.2)
Patch-To: Volume 8, Issue 46-48 (Patch1: tgif-1.2 => tgif-1.9)
Patch-To: Volume 8, Issue 58-60 (Patch2: tgif-1.9 => tgif-1.12)
Patch-To: Volume 8, Issue 87-89 (Patch3: tgif-1.12 => tgif-1.13)

Patch4 of tgif takes tgif-1.13 to tgif-1.14.  Below is a list of
added features/bug fixes, followed by the actual patch.

tgif-1.13 => tgif-1.14

1) Fix Imakefile so that it works better with the X11R4 installation.
   This includes commenting out BINDIR, CDEBUGFLAGS, and MANPATH.
   Thanks to David Eckelkamp@MCC and Carl Witty@Stanford for their
   recommentations, and specially David Eckelkamp@MCC for his improvements.

      NOTE:  With the current setup, those who wishes to install tgif
             in places outside of the X11R4 installation has to modify
             the Imakefile (uncomment the definition for CDEBUGFLAGS,
             BINDIR, MANPATH, and redefine TGIFDIR).  Sorry for the
             inconveniences.

2) Add support for 100dpi fonts.  (Actually, this was done in the previous
   release.  I forgot to mention it.)
3) Fix a small bug in display the current font (pixmap not cleared before).
4) Use XDrawPoint() instead of XDrawLine() in drawing grid points and
   rotated text.  Use the #ifdef construct to get around know server bugs.
5) Minor enhancement in cleaning up events in adding and deleting points.

---------------------------------> cut here <---------------------------------
*** choice.c.orig	Tue Aug 21 21:32:15 1990
--- choice.c	Tue Aug 21 21:32:16 1990
***************
*** 6,10 ****
  #ifndef lint
  static char RCSid[] =
!       "@(#)$Header: /n/kona/u/tangram/u/william/X11/TGIF/RCS/choice.c,v 1.6 90/08/15 16:01:40 william Exp $";
  #endif
  
--- 6,10 ----
  #ifndef lint
  static char RCSid[] =
!       "@(#)$Header: /n/kona/u/tangram/u/william/X11/TGIF/RCS/choice.c,v 1.8 90/08/21 15:55:15 william Exp $";
  #endif
  
***************
*** 104,108 ****
  {
     register int	i, j;
!    int		x, y, pixel, w, h, saved_x, saved_y;
     XRectangle	recs[1];
     XImage	* image;
--- 104,108 ----
  {
     register int	i, j;
!    int		x, y, w, h, saved_x, saved_y;
     XRectangle	recs[1];
     XImage	* image;
***************
*** 173,176 ****
--- 173,181 ----
     else
     {
+       XSetForeground (mainDisplay, choiceGC, 0);
+       XFillRectangle (mainDisplay, choiceBackingPixmap, choiceGC, 0, 0,
+          choiceWindowW, choiceWindowH);
+       XSetForeground (mainDisplay, choiceGC, 1);
+ 
        XDrawImageString (mainDisplay, choiceBackingPixmap, choiceGC, 0,
              canvasFontAsc, "W", 1);
***************
*** 195,201 ****
                    case ROTATE270: x = saved_x+j; y = saved_y-i; break;
                 }
! /*             XDrawPoint (mainDisplay, choiceWindow, defaultGC, x, y); */
! /*                Hack to run on RTs -- crash server on RTs             */
                 XDrawLine (mainDisplay,choiceWindow,defaultGC,x,y,x,y);
              }
  
--- 200,208 ----
                    case ROTATE270: x = saved_x+j; y = saved_y-i; break;
                 }
! #ifdef sun
!                XDrawPoint (mainDisplay, choiceWindow, defaultGC, x, y);
! #else
                 XDrawLine (mainDisplay,choiceWindow,defaultGC,x,y,x,y);
+ #endif
              }
  
*** edit.c.orig	Tue Aug 21 21:32:37 1990
--- edit.c	Tue Aug 21 21:32:38 1990
***************
*** 6,10 ****
  #ifndef lint
  static char RCSid[] =
!       "@(#)$Header: /n/kona/u/tangram/u/william/X11/TGIF/RCS/edit.c,v 1.9 90/08/16 09:35:06 william Exp $";
  #endif
  
--- 6,10 ----
  #ifndef lint
  static char RCSid[] =
!       "@(#)$Header: /n/kona/u/tangram/u/william/X11/TGIF/RCS/edit.c,v 1.13 90/08/21 16:03:43 william Exp $";
  #endif
  
***************
*** 32,35 ****
--- 32,39 ----
  #include "stretch.e"
  
+ #ifndef M_PI
+ #define M_PI 3.14159265358979323846
+ #endif
+ 
  #define OFFSET_X(x) (((x) - drawOrigX) >> zoomScale)
  #define OFFSET_Y(y) (((y) - drawOrigY) >> zoomScale)
***************
*** 73,77 ****
     unsigned int			status;
     Window			root_win, child_win;
!    XEvent			input;
  
     if (!(topSel != NULL && topSel == botSel &&
--- 77,81 ----
     unsigned int			status;
     Window			root_win, child_win;
!    XEvent			input, ev;
  
     if (!(topSel != NULL && topSel == botSel &&
***************
*** 201,204 ****
--- 205,209 ----
                 old_x+4, old_y+defaultFontAsc, "DEL", 3);
           MarkRulers (old_x, old_y);
+          while (XCheckMaskEvent (mainDisplay, PointerMotionMask, &ev)) ;
        }
     }
***************
*** 218,227 ****
     int		n = PolyPtr->n, already_moved=FALSE, done=FALSE, before;
     XPoint	* vs = PolyPtr->vlist, v[3];
!    int		prev_x, prev_y, x, y, next_x, next_y, new_x, new_y, dx, dy;
     int		orig_x, orig_y, grid_x, grid_y, new_mouse_x, new_mouse_y;
- /* int		prev_dist, next_dist, new_prev_dist, new_next_dist; */
     int		sel_ltx, sel_lty, sel_rbx, sel_rby, num, i;
     double	prev_angle, next_angle, new_angle, theta_1, theta_2;
!    XEvent	input;
  
     MARK(OFFSET_X(vs[Index].x), OFFSET_Y(vs[Index].y));
--- 223,231 ----
     int		n = PolyPtr->n, already_moved=FALSE, done=FALSE, before;
     XPoint	* vs = PolyPtr->vlist, v[3];
!    int		prev_x, prev_y, x, y, next_x, next_y, new_x, new_y;
     int		orig_x, orig_y, grid_x, grid_y, new_mouse_x, new_mouse_y;
     int		sel_ltx, sel_lty, sel_rbx, sel_rby, num, i;
     double	prev_angle, next_angle, new_angle, theta_1, theta_2;
!    XEvent	input, ev;
  
     MARK(OFFSET_X(vs[Index].x), OFFSET_Y(vs[Index].y));
***************
*** 237,241 ****
        next_x = vs[1].x;    next_y = vs[1].y;
        prev_x = 2*x-next_x; prev_y = 2*y-next_y;
- /*    prev_dist = next_dist = (x-prev_x)*(x-prev_x) + (y-prev_y)*(y-prev_y); */
     }
     else if (Index == n-1)
--- 241,244 ----
***************
*** 243,247 ****
        prev_x = vs[n-2].x;  prev_y = vs[n-2].y;
        next_x = 2*x-prev_x; next_y = 2*y-prev_y;
- /*    prev_dist = next_dist = (x-prev_x)*(x-prev_x) + (y-prev_y)*(y-prev_y); */
     }
     else
--- 246,249 ----
***************
*** 249,254 ****
        prev_x = vs[Index-1].x; prev_y = vs[Index-1].y;
        next_x = vs[Index+1].x; next_y = vs[Index+1].y;
- /*    prev_dist = (x-prev_x)*(x-prev_x) + (y-prev_y)*(y-prev_y); */
- /*    next_dist = (x-next_x)*(x-next_x) + (y-next_y)*(y-next_y); */
     }
     prev_angle = atan2 ((double)(prev_y-y), (double)(prev_x-x));
--- 251,254 ----
***************
*** 286,300 ****
              before = (theta_1 <= theta_2);
  
- /*          new_prev_dist = (new_x-prev_x)*(new_x-prev_x) + */
- /*                (new_y-prev_y)*(new_y-prev_y); */
- /*          new_next_dist = (new_x-next_x)*(new_x-next_x) + */
- /*                (new_y-next_y)*(new_y-next_y); */
- 
- /*          if ((new_prev_dist-prev_dist)*(new_next_dist-next_dist) < 0) */
- /*             before = (new_prev_dist < prev_dist); */
- /*          else */
- /*             before = (abs (new_prev_dist-prev_dist) < */
- /*                   abs (new_next_dist-next_dist)); */
- 
              if (before)
              {  /* Add a point between the current and the previous point */
--- 286,289 ----
***************
*** 339,342 ****
--- 328,332 ----
              MarkRulers (grid_x, grid_y);
           }
+          while (XCheckMaskEvent (mainDisplay, PointerMotionMask, &ev)) ;
        }
        else if (input.type == ButtonRelease)
***************
*** 411,420 ****
     int		n = PolygonPtr->n, already_moved=FALSE, done=FALSE, before;
     XPoint	* vs = PolygonPtr->vlist, v[3];
!    int		prev_x, prev_y, x, y, next_x, next_y, new_x, new_y, dx, dy;
     int		orig_x, orig_y, grid_x, grid_y, new_mouse_x, new_mouse_y;
- /* int		prev_dist, next_dist, new_prev_dist, new_next_dist; */
     int		sel_ltx, sel_lty, sel_rbx, sel_rby, i;
     double	prev_angle, next_angle, new_angle, theta_1, theta_2;
!    XEvent	input;
  
     MARK(OFFSET_X(vs[Index].x), OFFSET_Y(vs[Index].y));
--- 401,409 ----
     int		n = PolygonPtr->n, already_moved=FALSE, done=FALSE, before;
     XPoint	* vs = PolygonPtr->vlist, v[3];
!    int		prev_x, prev_y, x, y, next_x, next_y, new_x, new_y;
     int		orig_x, orig_y, grid_x, grid_y, new_mouse_x, new_mouse_y;
     int		sel_ltx, sel_lty, sel_rbx, sel_rby, i;
     double	prev_angle, next_angle, new_angle, theta_1, theta_2;
!    XEvent	input, ev;
  
     MARK(OFFSET_X(vs[Index].x), OFFSET_Y(vs[Index].y));
***************
*** 439,445 ****
     next_angle = atan2 ((double)(next_y-y), (double)(next_x-x));
  
- /* prev_dist = (x-prev_x)*(x-prev_x) + (y-prev_y)*(y-prev_y); */
- /* next_dist = (x-next_x)*(x-next_x) + (y-next_y)*(y-next_y); */
- 
     GridXY (MouseX, MouseY, &orig_x, &orig_y);
     new_mouse_x = MouseX; new_mouse_y = MouseY;
--- 428,431 ----
***************
*** 473,487 ****
              before = (theta_1 <= theta_2);
  
- /*          new_prev_dist = (new_x-prev_x)*(new_x-prev_x) + */
- /*                (new_y-prev_y)*(new_y-prev_y); */
- /*          new_next_dist = (new_x-next_x)*(new_x-next_x) + */
- /*                (new_y-next_y)*(new_y-next_y); */
- 
- /*          if ((new_prev_dist-prev_dist)*(new_next_dist-next_dist) < 0) */
- /*             before = (new_prev_dist < prev_dist); */
- /*          else */
- /*             before = (abs (new_prev_dist-prev_dist) < */
- /*                   abs (new_next_dist-next_dist)); */
- 
              if (before)
              {  /* Add a point between the current and the previous point */
--- 459,462 ----
***************
*** 506,509 ****
--- 481,485 ----
              MarkRulers (grid_x, grid_y);
           }
+          while (XCheckMaskEvent (mainDisplay, PointerMotionMask, &ev)) ;
        }
        else if (input.type == ButtonRelease)
***************
*** 588,600 ****
  void AddPoint ()
  {
-    register int			i;
     register struct ObjRec	* obj_ptr;
     struct PolyRec		* poly_ptr;
     struct PolygonRec		* polygon_ptr;
!    int				index, n, point_deleted, adding = TRUE;
     int				root_x, root_y, old_x, old_y;
     unsigned int			status;
     Window			root_win, child_win;
!    XEvent			input;
  
     if (!(topSel != NULL && topSel == botSel &&
--- 564,575 ----
  void AddPoint ()
  {
     register struct ObjRec	* obj_ptr;
     struct PolyRec		* poly_ptr;
     struct PolygonRec		* polygon_ptr;
!    int				index, adding = TRUE;
     int				root_x, root_y, old_x, old_y;
     unsigned int			status;
     Window			root_win, child_win;
!    XEvent			input, ev;
  
     if (!(topSel != NULL && topSel == botSel &&
***************
*** 662,665 ****
--- 637,641 ----
                 old_x+4, old_y+defaultFontAsc, "ADD", 3);
           MarkRulers (old_x, old_y);
+          while (XCheckMaskEvent (mainDisplay, PointerMotionMask, &ev)) ;
        }
     }
*** grid.c.orig	Tue Aug 21 21:32:44 1990
--- grid.c	Tue Aug 21 21:32:45 1990
***************
*** 6,10 ****
  #ifndef lint
  static char RCSid[] =
!       "@(#)$Header: /n/kona/u/tangram/u/william/X11/TGIF/RCS/grid.c,v 1.6 90/07/16 10:18:38 william Exp $";
  #endif
  
--- 6,10 ----
  #ifndef lint
  static char RCSid[] =
!       "@(#)$Header: /n/kona/u/tangram/u/william/X11/TGIF/RCS/grid.c,v 1.7 90/08/20 13:56:57 william Exp $";
  #endif
  
***************
*** 42,48 ****
  
     for (x = XStart; x < XEnd; x += 8)
! /*    XDrawPoint (mainDisplay, Win, defaultGC, x, Y); */
! /*       Hack to run on RTs -- crash server on RTs    */
        XDrawLine (mainDisplay, Win, defaultGC, x, Y, x, Y);
  }
  
--- 42,50 ----
  
     for (x = XStart; x < XEnd; x += 8)
! #ifdef sun
!       XDrawPoint (mainDisplay, Win, defaultGC, x, Y);
! #else
        XDrawLine (mainDisplay, Win, defaultGC, x, Y, x, Y);
+ #endif
  }
  
***************
*** 54,60 ****
  
     for (y = YStart; y < YEnd; y += 8)
! /*    XDrawPoint (mainDisplay, Win, defaultGC, X, y); */
! /*       Hack to run on RTs -- crash server on RTs    */
        XDrawLine (mainDisplay, Win, defaultGC, X, y, X, y);
  }
  
--- 56,64 ----
  
     for (y = YStart; y < YEnd; y += 8)
! #ifdef sun
!       XDrawPoint (mainDisplay, Win, defaultGC, X, y);
! #else
        XDrawLine (mainDisplay, Win, defaultGC, X, y, X, y);
+ #endif
  }
  
*** text.c.orig	Tue Aug 21 21:33:23 1990
--- text.c	Tue Aug 21 21:33:25 1990
***************
*** 6,10 ****
  #ifndef lint
  static char RCSid[] =
!       "@(#)$Header: /n/kona/u/tangram/u/william/X11/TGIF/RCS/text.c,v 1.16 90/08/16 15:44:38 william Exp $";
  #endif
  
--- 6,10 ----
  #ifndef lint
  static char RCSid[] =
!       "@(#)$Header: /n/kona/u/tangram/u/william/X11/TGIF/RCS/text.c,v 1.18 90/08/21 16:24:22 william Exp $";
  #endif
  
***************
*** 148,152 ****
     register int		i, j;
     register XImage	* from_image;
!    int			w, h, amount, left, right, len;
     XGCValues		values;
  
--- 148,152 ----
     register int		i, j;
     register XImage	* from_image;
!    int			w, h, left, right, len;
     XGCValues		values;
  
***************
*** 290,297 ****
                    for (j = 0; j < h; j++)
                       if (XGetPixel (from_image, i, j) == 1)
! /*                      XDrawPoint (mainDisplay, Win, gc, XOff-j, YOff+i); */
! /*                         Hack to run on RTs -- crash server on RTs       */
                          XDrawLine (mainDisplay, Win, gc, XOff-j, YOff+i,
                                XOff-j, YOff+i);
                 break;
              case ROTATE180:
--- 290,299 ----
                    for (j = 0; j < h; j++)
                       if (XGetPixel (from_image, i, j) == 1)
! #ifdef sun
!                         XDrawPoint (mainDisplay, Win, gc, XOff-j, YOff+i);
! #else
                          XDrawLine (mainDisplay, Win, gc, XOff-j, YOff+i,
                                XOff-j, YOff+i);
+ #endif
                 break;
              case ROTATE180:
***************
*** 299,306 ****
                    for (j = 0; j < h; j++)
                       if (XGetPixel (from_image, i, j) == 1)
! /*                      XDrawPoint (mainDisplay, Win, gc, XOff-i, YOff-j); */
! /*                         Hack to run on RTs -- crash server on RTs       */
                          XDrawLine (mainDisplay, Win, gc, XOff-i, YOff-j,
                                XOff-i, YOff-j);
                 break;
              case ROTATE270:
--- 301,310 ----
                    for (j = 0; j < h; j++)
                       if (XGetPixel (from_image, i, j) == 1)
! #ifdef sun
!                         XDrawPoint (mainDisplay, Win, gc, XOff-i, YOff-j);
! #else
                          XDrawLine (mainDisplay, Win, gc, XOff-i, YOff-j,
                                XOff-i, YOff-j);
+ #endif
                 break;
              case ROTATE270:
***************
*** 308,315 ****
                    for (j = 0; j < h; j++)
                       if (XGetPixel (from_image, i, j) == 1)
! /*                      XDrawPoint (mainDisplay, Win, gc, XOff+j, YOff-i); */
! /*                         Hack to run on RTs -- crash server on RTs       */
                          XDrawLine (mainDisplay, Win, gc, XOff+j, YOff-i,
                                XOff+j, YOff-i);
                 break;
           }
--- 312,321 ----
                    for (j = 0; j < h; j++)
                       if (XGetPixel (from_image, i, j) == 1)
! #ifdef sun
!                         XDrawPoint (mainDisplay, Win, gc, XOff+j, YOff-i);
! #else
                          XDrawLine (mainDisplay, Win, gc, XOff+j, YOff-i,
                                XOff+j, YOff-i);
+ #endif
                 break;
           }
***************
*** 388,392 ****
     int			Just, W, H, Rotate;
  {
!    int	ltx, lty, rbx, rby, mw2, pw2;
  
     switch (Just)
--- 394,398 ----
     int			Just, W, H, Rotate;
  {
!    register int	mw2, pw2;
  
     switch (Just)
***************
*** 476,480 ****
     register int		num_lines;
     struct StrRec	* s_ptr = ObjPtr->detail.t->first;
!    int			max_len = 0, len, w;
  
     SaveCurFont ();
--- 482,486 ----
     register int		num_lines;
     struct StrRec	* s_ptr = ObjPtr->detail.t->first;
!    int			max_len = 0, w;
  
     SaveCurFont ();
***************
*** 510,521 ****
  }
  
- static
- int FindEqual (S)
-    register char *S;
- {
-    while (*S != '=' && *S != '\0') S++;
-    return (*S == '=');
- }
- 
  int CreateTextObj ()
     /* returns TRUE if something got created */
--- 516,519 ----
***************
*** 525,530 ****
     struct StrRec	* s_ptr;
     struct AttrRec	* attr_ptr;
!    struct ObjRec	* obj_ptr;
!    int			max_len = 0, len, w, ltx, lty, rbx, rby;
     int			scr_ltx, scr_lty;
  
--- 523,527 ----
     struct StrRec	* s_ptr;
     struct AttrRec	* attr_ptr;
!    int			max_len = 0, w, ltx, lty, rbx, rby;
     int			scr_ltx, scr_lty;
  
***************
*** 1314,1319 ****
     XEvent	* input;
  {
-    int			len, x, y;
-    Window		sub_win_id;
     char			s[80];
     XKeyEvent		* key_ev;
--- 1311,1314 ----
*** tgif.c.orig	Tue Aug 21 21:33:32 1990
--- tgif.c	Tue Aug 21 21:33:33 1990
***************
*** 6,10 ****
  #ifndef lint
  static char RCSid[] =
!       "@(#)$Header: /n/kona/u/tangram/u/william/X11/TGIF/RCS/tgif.c,v 1.7 90/08/15 15:05:17 william Exp $";
  #endif
  
--- 6,10 ----
  #ifndef lint
  static char RCSid[] =
!       "@(#)$Header: /n/kona/u/tangram/u/william/X11/TGIF/RCS/tgif.c,v 1.8 90/08/21 15:52:54 william Exp $";
  #endif
  
***************
*** 54,59 ****
     int	i;
     char	op_name[80], file_name[80], s[80], color_name[80], val_name[80];
!    char	* sp[6], * func_strp, attr_name[80], speed_name[80], type_name[80];
!    char	* c_ptr, id_name[80];
  
     file_name[0] = '\0';
--- 54,59 ----
     int	i;
     char	op_name[80], file_name[80], s[80], color_name[80], val_name[80];
!    char	* sp[6], * func_strp, attr_name[80], speed_name[80];
!    char	id_name[80];
  
     file_name[0] = '\0';
*** version.c.orig	Tue Aug 21 21:33:36 1990
--- version.c	Tue Aug 21 21:33:37 1990
***************
*** 6,11 ****
  #ifndef lint
  static char RCSid[] =
!       "@(#)$Header: /n/kona/u/tangram/u/william/X11/TGIF/RCS/version.c,v 1.16 90/08/16 09:41:02 william Exp $";
  #endif
  
! char	* version_string = "1.13";
--- 6,11 ----
  #ifndef lint
  static char RCSid[] =
!       "@(#)$Header: /n/kona/u/tangram/u/william/X11/TGIF/RCS/version.c,v 1.17 90/08/21 21:30:03 william Exp $";
  #endif
  
! char	* version_string = "1.14";
*** Makefile.noimake.orig	Tue Aug 21 21:33:42 1990
--- Makefile.noimake	Tue Aug 21 21:33:43 1990
***************
*** 4,8 ****
  # Copyright (C) 1990, William Cheng.
  #
! # @(#)$Header: /n/kona/u/tangram/u/william/X11/TGIF/RCS/Makefile.noimake,v 1.22 90/08/16 13:21:47 william Exp $
  #
  
--- 4,8 ----
  # Copyright (C) 1990, William Cheng.
  #
! # @(#)$Header: /n/kona/u/tangram/u/william/X11/TGIF/RCS/Makefile.noimake,v 1.23 90/08/21 16:09:05 william Exp $
  #
  
***************
*** 13,18 ****
  
  CC = cc
! CFLAGS = -g -DTGIF_PATH=\"/u/tangram/u/william/X11/TGIF\" -DPSFILE_MOD=\"664\" \
! 		-I/usr/local/include
  LFLAGS = -lX11 -lm
  
--- 13,18 ----
  
  CC = cc
! TGIFDIR = /u/tangram/lib/tgif
! CFLAGS = -g -DTGIF_PATH=\"$(TGIFDIR)\" -DPSFILE_MOD=\"664\" -I/usr/local/include
  LFLAGS = -lX11 -lm
  
***************
*** 194,198 ****
  	ld -o frontend11.o -r $(OBJ1)
  
! install: $(INSTALLDIR)/tgif $(INSTALLDIR)/tgif2ps
  	@echo Making install ...
  
--- 194,199 ----
  	ld -o frontend11.o -r $(OBJ1)
  
! install: $(INSTALLDIR)/tgif $(INSTALLDIR)/tgif2ps \
! 		$(TGIFDIR)/.psmac $(TGIFDIR)/tgificon.obj
  	@echo Making install ...
  
***************
*** 202,205 ****
--- 203,212 ----
  $(INSTALLDIR)/tgif2ps: tgif2ps
  	install -c tgif2ps $(INSTALLDIR)/tgif2ps
+ 
+ $(TGIFDIR)/.psmac: .psmac
+ 	install -c .psmac $(TGIFDIR)/.psmac
+ 
+ $(TGIFDIR)/tgificon.obj: tgificon.obj
+ 	install -c tgificon.obj $(TGIFDIR)/tgificon.obj
  
  OBJDEMO = an-sr-flip-flop.obj fonts.obj slide-demo.obj spice/*.obj
*** Imakefile.orig	Tue Aug 21 21:33:48 1990
--- Imakefile	Tue Aug 21 21:33:48 1990
***************
*** 4,17 ****
  /**/# Copyright (C) 1990, William Cheng.
  /**/#
! /**/# @(#)$Header: /n/kona/u/tangram/u/william/X11/TGIF/RCS/Imakefile,v 1.23 90/08/17 09:48:59 william Exp $
  /**/#
  
! TGIFVERSION	= 1.13
  PROGRAMS	= tgif prtgif tgif2ps frontend11.o
! CDEBUGFLAGS	= -g
! BINDIR		= /u/tangram/bin
! MANPATH		= /u/tangram/man
! DEFINES		= -DTGIF_PATH=\"/u/tangram/u/william/X11/TGIF\" \
! 		  -DPSFILE_MOD=\"664\"
  LOCAL_LIBRARIES	= $(XLIB)
  DEPLIBS		= $(DEPXLIB)
--- 4,18 ----
  /**/# Copyright (C) 1990, William Cheng.
  /**/#
! /**/# @(#)$Header: /n/kona/u/tangram/u/william/X11/TGIF/RCS/Imakefile,v 1.25 90/08/21 21:30:40 william Exp $
  /**/#
  
! TGIFVERSION	= 1.14
  PROGRAMS	= tgif prtgif tgif2ps frontend11.o
! /**/#CDEBUGFLAGS= -g
! /**/#BINDIR	= /u/tangram/bin
! /**/#MANPATH	= /u/tangram/man
! /**/#TGIFDIR	= /u/tangram/lib/tgif
! TGIFDIR	= $(LIBDIR)/tgif
! DEFINES		= -DTGIF_PATH=\"$(TGIFDIR)\" -DPSFILE_MOD=\"664\"
  LOCAL_LIBRARIES	= $(XLIB)
  DEPLIBS		= $(DEPXLIB)
***************
*** 47,50 ****
--- 48,55 ----
  
  NormalRelocatableTarget(frontend11,$(OBJ1))
+ 
+ MakeDirectories(install,$(TGIFDIR))
+ InstallNonExec(.psmac,$(TGIFDIR))
+ InstallNonExec(tgificon.obj,$(TGIFDIR))
  
  .SUFFIXES: .l .man
---------------------------------> cut here <---------------------------------
--
Bill Cheng // UCLA Computer Science Department // (213) 206-7135
3277 Boelter Hall // Los Angeles, California 90024 // USA
william@CS.UCLA.EDU      ...!{uunet|ucbvax}!cs.ucla.edu!william

dan
----------------------------------------------------
O'Reilly && Associates   argv@sun.com / argv@ora.com
Opinions expressed reflect those of the author only.


From ucla-cs!usc!apple!voder!zok!mark Fri Aug 24 10:03:00 PDT 1990
Article: 26760 of comp.windows.x
Path: ucla-cs!usc!apple!voder!zok!mark
From: mark@zok.UUCP (Mark W. Snitily)
Newsgroups: comp.windows.x,ba.windows.x
Subject: West Coast UUCP X11 Archive Update
Message-ID: <487@zok.UUCP>
Date: 24 Aug 90 04:50:14 GMT
Followup-To: comp.windows.x
Organization: The distant planet Zok
Lines: 73
Xref: ucla-cs comp.windows.x:26760
Status: O


#########################################################################
#################          W e s t   C o a s t          #################
#################   U U C P    X 1 1    A r c h i v e   #################
#################              U p d a t e              #################
#########################################################################

23-Aug-90

For those of you without access to the internet, the West Coast UUCP X11
archive on zok provides UUCP users access to everything found on
expo.lcs.mit.edu (18.30.0.212).  All comp.sources.x articles (from day zero)
are also available.

The archive is typically updated about once a week.  I'm running System V
so filenames have to be condensed to a maximum of 14 characters.  The dates
of the files are kept in correspondence with those on expo.lcs.mit.edu.
A current directory listing of what's on expo.lcs.mit.edu (containing the
original long filenames) is always located in "zok!/usrX/expo/expo.ls-lR".

The recent posting of xview2 posed a problem -- not enough space on the
filesystem used for the archive.  So, ... the XTEST source code has been
temporarily removed until I repartition the disk and increase the size of
the filesystem.  (If anyone needs the XTEST source in the mean while, email
me a note.)

Here's information from the "Frequently Asked Questions about X with Answers"
on how to connect to zok:

	A new west-coast UUCP X11 Archive is administered by Mark Snitily 
(mark@zok.uucp) and contains the full X11R4 distribution, the XTEST
distribution, an entire archive of comp.sources.x and other goodies.
	The machine zok has a TB+ modem which will connect to 19.2K, 2400, 
1200 baud (in that order).  The anonymous UUCP account is UXarch with password 
Xgoodies.  The modem's phone number is 408-996-8285.
	A sample Systems (or L.sys) entry might be:
   		zok Any ACU 19200 4089968285 in:--in: UXarch word: Xgoodies
	To get a current listing of the files that are available, download
the file "/usrX/ls-lR.Z".
	A full subject index of the comp.sources.x files is available in the
file "/usrX/comp.sources.x/INDEX".
	The machine has just the one modem, so please do not fetch large 
amounts of data at one sitting.
[courtesy Mark Snitily, 2/90]


By "large amounts of data", what I meant was please don't connect for more
than an hour or two at a time.  The amount of data, of course, will vary
with your baud rate.

Here are a few example uucp downloads, ("\" are csh escapes, ignore them
if you're using sh or ksh):

   uucp zok\!/usrX/ls-lR.Z \!~
   uucp zok\!/usrX/expo/expo.ls-lR \!~

   uucp zok\!/usrX/pub/R4/fixes/fix-14 \!~
   uucp zok\!/usrX/pub/R4/tape-1/tape-1.01 \!~

   uucp zok\!/usrX/contrib/xview2.tar.Zaa \!~
   uucp zok\!/usrX/contrib/xldim106.tar.Z \!~
   uucp zok\!/usrX/contrib/R4fixes/andrew/patch.06a.Z \!~

   uucp zok\!/usrX/comp.sources.x/INDEX \!~
   uucp zok\!/usrX/comp.sources.x/v00/v00INF1.Z \!~
   uucp zok\!/usrX/comp.sources.x/v08/v08i094.Z \!~

-- Mark

Mark W. Snitily                 Consulting Services:
894 Brookgrove Lane             Graphics, Operating Systems, Compilers
Cupertino, CA 95014             (408) 252-0456
mark@zok.uucp                   West Coast UUCP X11 archive site


From ucla-cs!elroy.jpl.nasa.gov!sdd.hp.com!cs.utexas.edu!milano!espresso!cheung Fri Aug 24 10:03:55 PDT 1990
Article: 26762 of comp.windows.x
Path: ucla-cs!elroy.jpl.nasa.gov!sdd.hp.com!cs.utexas.edu!milano!espresso!cheung
From: cheung@espresso.sw.mcc.com (Po Cheung)
Newsgroups: comp.windows.x
Subject: xdbx 2.1 patchlevel 2 available now
Message-ID: <4133@espresso.sw.mcc.com>
Date: 24 Aug 90 08:23:45 GMT
Organization: MCC, Austin, TX
Lines: 39
Status: O

I have updated the version of xdbx 2.1 on expo.lcs.mit.edu to patch level 2.

-rw-rw-rw-  1 ftp        114359 Aug 24 03:34 xdbx2.1.tar.Z

If you do not want to ftp the entire distribution, the patch is also
available for ftp on expo.lcs.mit.edu, provided you have the 
version of xdbx2.1 at patch level 1.

-rw-rw-rw-  1 ftp          7916 Aug 24 03:34 xdbx.patch2.Z

For those without ftp access, I am sending the source to comp.sources.x
at the same time.  So, it should show up sometime later.

This patch addresses mainly bugs reported by a number of users on the net.
In particular, the patch includes
  - fixes in calldbx.c to use termios instead of sgtty structure
  - fixes to allow xdbx to compile with gcc
  - fixes to allow xdbx to compile with Xaw library without XAW_BC defined
  - fixes to make dialogue window behave correctly for all commands issued
  - fixes for the use command

My thanks to the following people for providing bug fixes to xdbx:

  Dana Chee (dana@thumper.bellcore.com)
  Dave Gagne (daveg@fs1.ee.ubc.ca)
  Arturo Perez (aperez@cvbnet.prime.com)
  Manavendra Thakur (thakur@zerkalo.harvard.edu)
  Phil Karlton (karlton@sgi.com)
  Mike Iglesias (iglesias@orion.oac.uci.edu)
  David Elliott (dce@smsc.sony.com)


Enjoy,

  Po Cheung
  cheung@sw.mcc.com

P.S. I do not have access to a DECstation 3100 any more.  So I will not be
     able to diagnose any problems with xdbx running on the DECstation 3100.


From ucla-cs!william@oahu.cs.ucla.edu Mon Aug 27 12:06:28 PDT 1990
Article: 26864 of comp.windows.x
Path: ucla-cs!william@oahu.cs.ucla.edu
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: Tgif-1.15 (Xlib based 2-D drawing tool) is available on expo ...
Keywords: draw, tool, postscript, latex, hierarchical, x11, xlib, wysiwyg
Message-ID: <38381@shemp.CS.UCLA.EDU>
Date: 27 Aug 90 18:49:17 GMT
Sender: news@CS.UCLA.EDU
Followup-To: william@cs.ucla.edu
Organization: UCLA Computer Science Department
Lines: 587
Status: RO

I've just put tgif-1.15 in the following places for anonymous ftp:

	expo.lcs.mit.edu	contrib/tgif-1.15.tar.Z
	cs.ucla.edu		pub/tgif-1.15.tar.Z

Here's a short list of added features/bug fixes.

1) Fix bugs related to rewind() that it should not return any status.
   Thanks to Carl Witty@Stanford for the patch.
2) Upgrade 'tgif.pl' (Prolog hints) to handle file version 8.

The following is the patch to take tgif from version 1.14 to 1.15.
---------------------------------> cut here <---------------------------------

From ucla-cs!usc!cs.utexas.edu!sun-barr!newstop!sun!CS.UCLA.EDU Tue Aug 28 08:23:52 PDT 1990
Article: 772 of comp.sources.x
Path: ucla-cs!usc!cs.utexas.edu!sun-barr!newstop!sun!CS.UCLA.EDU
From: william@CS.UCLA.EDU (William Cheng)
Newsgroups: comp.sources.x
Subject: v08i095: tgif, (tgif-1.14 => tgif-1.15), Patch5, Part01/01
Message-ID: <141428@sun.Eng.Sun.COM>
Date: 28 Aug 90 07:45:02 GMT
Sender: news@sun.Eng.Sun.COM
Lines: 598
Approved: argv@sun.com
Status: RO

Submitted-by: william@CS.UCLA.EDU (William Cheng)
Posting-number: Volume 8, Issue 95
Archive-name: tgif/patch5
Patch-To: tgif: Volume 7, Issue 56-76 (original: tgif-1.2)
Patch-To: tgif: Volume 8, Issue 46-48 (Patch1: tgif-1.2 => tgif-1.9)
Patch-To: tgif: Volume 8, Issue 58-60 (Patch2: tgif-1.9 => tgif-1.12)
Patch-To: tgif: Volume 8, Issue 87-89 (Patch3: tgif-1.12 => tgif-1.13)
Patch-To: tgif: Volume 8, Issue 94 (Patch4: tgif-1.13 => tgif-1.14)

Patch5 of tgif takes tgif-1.14 to tgif-1.15.  Below is a list of
added features/bug fixes, followed by the actual patch.

tgif-1.14 => tgif-1.15

1) Fix bugs related to rewind() that it should not return any status.
   Thanks to Carl Witty@Stanford for the patch.
2) Upgrade 'tgif.pl' (Prolog hints) to handle file version 8.

---------------------------------> cut here <---------------------------------

From ucla-cs!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!ucbvax!bloom-beacon!SABER.COM!jimf Tue Aug 28 17:32:31 PDT 1990
Article: 26921 of comp.windows.x
Path: ucla-cs!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!ucbvax!bloom-beacon!SABER.COM!jimf
From: jimf@SABER.COM
Newsgroups: comp.windows.x
Subject: Re: FAX (Group 3) viewer for X
Message-ID: <9008281905.AA05332@armory>
Date: 28 Aug 90 19:05:02 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 15
Status: O

|Does anyone have a program for viewing group 3 FAX files under
|X ?  We only have the basic X core (Xlib, Xt), and none of the
|extended widgets so I would prefer one based on Xt alone.

Xloadimage does this however it is not Xt based.  The code to load the
image and send it to a pixmap is generic enough so that you should be
able to build an Xt-based viewer with it with a minimum of work.

Xloadimage is available by anonymous ftp from expo.lcs.mit.edu in
/contrib/xloadimage.1.06.tar.Z.  It is updated periodically and
updates are announced in this group.

jim frost
saber software
jimf@saber.com


From ucla-cs!usc!wuarchive!cs.utexas.edu!news-server.csri.toronto.edu!smoke.cs.toronto.edu!neat.cs.toronto.edu!moraes Wed Aug 29 12:43:54 PDT 1990
Article: 26955 of comp.windows.x
Path: ucla-cs!usc!wuarchive!cs.utexas.edu!news-server.csri.toronto.edu!smoke.cs.toronto.edu!neat.cs.toronto.edu!moraes
From: moraes@cs.toronto.edu (Mark Moraes)
Newsgroups: comp.windows.x
Subject: Re: Postscript Previewer for DS3100
Keywords: postscript
Message-ID: <90Aug29.151708edt.559@smoke.cs.toronto.edu>
Date: 29 Aug 90 19:18:10 GMT
References: <1990Aug29.182004.22416@caen.engin.umich.edu>
Organization: Department of Computer Science, University of Toronto
Lines: 9
Status: O

grue@caen.engin.umich.edu (Paul Howell) writes:
>However, there is an include file missing, fontstruct.h.  Does anybody
>know where I can get a copy?

In the X.V11R[34] source, see server/include/fontstruct.h.  This
should be found automatically if you set the Makefile (or environment)
variable X11 to the topdir of the X11 src tree.

	Mark.


From ucla-cs!usc!snorkelwacker!paperboy!osf.org!dbrooks Wed Aug 29 17:01:40 PDT 1990
Article: 26960 of comp.windows.x
Path: ucla-cs!usc!snorkelwacker!paperboy!osf.org!dbrooks
From: dbrooks@osf.org (David Brooks)
Newsgroups: comp.windows.x,comp.windows.x.motif
Subject: Motif 1.1 shipping (please read this too)
Keywords: Motif 1.1 OSF
Message-ID: <1990Aug29.155636@osf.org>
Date: 29 Aug 90 19:56:36 GMT
Sender: news@OSF.ORG
Reply-To: dbrooks@osf.org (David Brooks)
Organization: Open Software Foundation
Lines: 27
Xref: ucla-cs comp.windows.x:26960 comp.windows.x.motif:794
Status: O

Once more with feeling.  Lots and lots of feeling:

A few days ago I announced release 1.1 of OSF/Motif.  From email I've
had, it is apparent I must repeat the following litany.

- No, OSF/Motif source is NOT available by FTP from anywhere.  It is a
  licensed software offering.  If you do find it available for free,
  please call McGruff the crime dog (our lawyers will do).

- There is ONE point of contact: "OSF Direct".  You can contact OSF
  Direct at +1(617)621-7300; if you simply want to request documents,
  including order forms and the like, you can email direct@osf.org
  (uunet!osf.org!direct).

- Existing licensees must execute a new license supplement, available
  from OSF Direct.

In particular, please do not email me with requests.  From this point
on, any such email I receive will be cheerfully and thoroughly ignored.

My posting also pointed to a fuller description on comp.newprod.  Now,
comp.newprod is a moderated group, and the posting hasn't appeared yet
(at least at this site) -- please be patient.
-- 
David Brooks				dbrooks@osf.org
Systems Engineering, OSF		uunet!osf.org!dbrooks
Experience Hackvergnuegen!


From ucla-cs!usc!wuarchive!cs.utexas.edu!sun-barr!newstop!sun!marvin.Solbourne.COM Thu Aug 30 10:19:08 PDT 1990
Article: 795 of comp.sources.x
Path: ucla-cs!usc!wuarchive!cs.utexas.edu!sun-barr!newstop!sun!marvin.Solbourne.COM
From: toml@marvin.Solbourne.COM (Tom LaStrange)
Newsgroups: comp.sources.x
Subject: v09i002: TWM with a virtual root window, Part01/09
Message-ID: <141529@sun.Eng.Sun.COM>
Date: 29 Aug 90 19:32:50 GMT
Sender: news@sun.Eng.Sun.COM
Lines: 2176
Approved: argv@sun.com
Status: O

Submitted-by: toml@marvin.Solbourne.COM (Tom LaStrange)
Posting-number: Volume 9, Issue 2
Archive-name: tvtwm/part01

This is yet another, different implementation of the Virtual Desktop
concept for twm.  I call this version tvtwm (Tom's Virtual twm).  It is
based on the R4 version of twm with up to fix-14 installed.  This
implementation is modeled after swm (Solbourne Window Manager) and
includes the very nice ability to move windows into and out of the
panner.  It should be noted that none of this code came from the vtwm
implementation.  If you have problems and/or patches you can email me
at the address at:
    toml@marvin.Solbourne.COM (Tom LaStrange)

#! /bin/sh
# This is a shell archive, meaning:
# 1.  Remove everything above the #! /bin/sh line.
# 2.  Save the resulting test in a file
# 3.  Execute the file with /bin/sh (not csh) to create the files:
#
#CHANGES
#Imakefile
#README
#README.tvtwm
#add_window.c
#add_window.h
#cursor.c
#patchlevel.h
#siconify.bm
#
# Created by toml () on Wed Aug 29 08:43:23 MDT 1990
#
if test -f 'CHANGES'
then
    echo shar: will not over-write existing file "CHANGES"
else
echo extracting "CHANGES"
sed 's/^X//' >CHANGES <<'SHAR_EOF'
XThis directory is new since R3.
SHAR_EOF
if test 32 -ne "`wc -c < CHANGES`"
then
    echo shar: error transmitting "CHANGES" '(should have been 32 characters)'
fi
fi
if test -f 'Imakefile'
then
    echo shar: will not over-write existing file "Imakefile"
else
echo extracting "Imakefile"
sed 's/^X//' >Imakefile <<'SHAR_EOF'
X/**/#
X/**/#Here is an Imakefile for twm.  It depends on having TWMDIR defined
X/**/#in Imake.tmpl.  I like to use Imakefiles for everything, and I am sure
X/**/#other people do also, so perhaps you could do us all a favor and
X/**/#distribute this one.
X/**/#
X
X         YFLAGS = -d
X        DEPLIBS = $(DEPXMULIB) $(DEPEXTENSIONLIB) $(DEPXLIB)
XLOCAL_LIBRARIES = $(XMULIB) $(EXTENSIONLIB) $(XLIB)
X       LINTLIBS = $(LINTXMU) $(LINTEXTENSIONLIB) $(LINTXLIB)
X        DEFINES = ExtensionDefines $(SIGNAL_DEFINES)
X
X           SRCS = gram.c lex.c deftwmrc.c add_window.c gc.c list.c twm.c \
X		parse.c menus.c events.c resize.c util.c version.c iconmgr.c \
X		cursor.c icons.c vdt.c move.c
X
X           OBJS = gram.o lex.o deftwmrc.o add_window.o gc.o list.o twm.o \
X		parse.o menus.o events.o resize.o util.o version.o iconmgr.o \
X		cursor.o icons.o vdt.o move.o
X
XAllTarget(tvtwm)
X
XSpecialObjectRule(parse.o, ,'-DSYSTEM_INIT_FILE="'$(TWMDIR)'/system.twmrc"')
X#if !HasPutenv
XSpecialObjectRule(util.o, ,-DNOPUTENV)
X#endif
X
Xdepend:: lex.c gram.c deftwmrc.c 
X
XComplexProgramTarget(tvtwm)
XMakeDirectories(install,$(TWMDIR))
XInstallNonExec(system.twmrc, $(TWMDIR))
X
Xgram.h gram.c: gram.y
X	yacc $(YFLAGS) gram.y
X	$(MV) y.tab.c gram.c
X	$(MV) y.tab.h gram.h
X
Xclean::
X	$(RM) y.tab.h y.tab.c lex.yy.c gram.h gram.c lex.c deftwmrc.c 
X
Xdeftwmrc.c:  system.twmrc
X	$(RM) $@
X	echo '/* ' >>$@
X	echo ' * This file is generated automatically from the default' >>$@
X	echo ' * twm bindings file system.twmrc by the twm Imakefile.' >>$@
X	echo ' */' >>$@
X	echo '' >>$@
X	echo 'char *defTwmrc[] = {' >>$@
X	sed -e '/^#/d' -e 's/"/\\"/g' -e 's/^/    "/' -e 's/$$/",/' \
X		system.twmrc >>$@
X	echo '    (char *) 0 };' >>$@
X
SHAR_EOF
if test 1683 -ne "`wc -c < Imakefile`"
then
    echo shar: error transmitting "Imakefile" '(should have been 1683 characters)'
fi
fi
if test -f 'README'
then
    echo shar: will not over-write existing file "README"
else
echo extracting "README"
sed 's/^X//' >README <<'SHAR_EOF'
XTo save Tom LaStrange from being blaimed for any of the massive numbers of
Xchanges that have been done to twm since gave up control of it, the name "twm"
Xnow stands for "Tab Window Manager" (try the SqueezeTitle option to see why). 
X
X
SHAR_EOF
if test 235 -ne "`wc -c < README`"
then
    echo shar: error transmitting "README" '(should have been 235 characters)'
fi
fi
if test -f 'README.tvtwm'
then
    echo shar: will not over-write existing file "README.tvtwm"
else
echo extracting "README.tvtwm"
sed 's/^X//' >README.tvtwm <<'SHAR_EOF'
XFor those of you like me who want to try software before reading
Xthe instructions, all you have to do to get started is add a single
Xline to your .twmrc file.  Something like this:
X
X  VirtualDesktop "3000x2000"
X
XNow for the verbose description:
X
XThis is yet another, different implementation of the Virtual Desktop
Xconcept for twm.  I call this version tvtwm (Tom's Virtual twm).  It is
Xbased on the R4 version of twm with up to fix-14 installed.  This
Ximplementation is modeled after swm (Solbourne Window Manager) and
Xincludes the very nice ability to move windows into and out of the
Xpanner.  It should be noted that none of this code came from the vtwm
Ximplementation.  If you have problems and/or patches you can email me
Xat the address at the end of this file.
X
XIf we look at different implementations of the Virtual Desktop, I think
Xwe can relate them to soft drinks:
X
Xswm   - Classic Coke  "The Real Thing"
Xtvtwm - Diet Coke     "Same as Coke but not as sweet"
Xvtwm  - Diet Pepsi    "Not as sweet as Coke, some people may
X		       prefer it to any flavor of Coke"
X
XThere are pros and cons to the vtwm and swm/tvtwm implementations.  Most
Xrevolve around whether or not to use an additional window for the
Xscrolling desktop or to simply move windows around on the actual
Xroot window.
X
Xvtwm moves windows on the actual root window, swm/tvtwm use an
Xadditional window to perform the scrolling.
X
XPros:
X  vtwm    Simple to implement.
X          Programs like xsetroot continue to work.
X
X  tvtwm   Half the network traffic when the desktop scrolls,
X	    only a ConfigureNotify event has to be sent.
X	  Faster scrolling of the desktop.
X	  Desktop background image will actually scroll.
X	  Opens the door for possible multiple Virtual Desktop
X	    windows.
XCons:
X  vtwm	  Twice as much network traffic when the desktop scrolls,
X	    each window has to be moved and then a ConfigureNotify
X	    event must be sent.
X	  Slower scrolling of the desktop.
X	  Desktop background image does not scroll.
X
X  tvtwm	  Programs like xsetroot no longer work, additional work
X	    needs to be done to find the Virtual Desktop window.
X	  Programs that attempt to find the size of the window
X	    manager decoration may fail if the traverse the window
X	    tree until they run into the actual root window.
X
XThe ICCCM states that more work needs to be done in the area of
Xvirtual root windows, so there isn't any clear answer on the right
Xway to implement this feature.  Having said that, let me describe
Xhow I've butchered the code, what currently doesn't work, what would
Xbe nice if it worked, etc.
X
X1. First a description of how the panner works.  Basically,
X   mouse button 1 allows you to change your position in the
X   desktop.  Mouse button 2 allows you to drag any of the
X   small "virtual" windows.  During a window move operation
X   you can move the pointer into and out of the panner.
X   Resizing the panner will of course resize the desktop.
X
X2. I completely re-wrote the window move code.  In menus.c I 
X   simply commented out the window move code that is there and
X   didn't touch any code related to window moves in events.c.
X   The new window move code is in a new file called move.c.
X
X3. Because of the new window move code, I have not looked at 
X   or implemented the MoveOpaque feature.  With the Virtual Desktop
X   enabled, users typically won't want to use MoveOpaque anyway 
X   because it's not as clean to move into and out of the panner.
X   The constrained move and DontMoveOff functionality is also
X   missing.
X
X4. Rather than the f.nail and "NailedDown" features of vtwm, tvtwm
X   uses the same terminology as swm.  In tvtwm, windows that do
X   not move when the desktop is panned are called "sticky" windows.
X   There is a command called f.stick and a "Sticky" list of windows
X   that will be sticky when started.  Also, a side effect/feature
X   of the way sticky windows are impemented means that sticky
X   windows will always be on top of non-sticky windows.  The sticky-ness
X   of a window is remembered during an f.restart if RestartPreviousState
X   is set.
X
X5. USPosition vs. PPosition - When a window has USPosition hints
X   set, the window will be positioned at that exact pixel location.
X   When PPosition hints are set, the window will be positioned at 
X   the pixel location plus the current offset of the Virtual Desktop.
X   For example, if the desktop has been panned to +200+500 and 
X   a window is mapped with PPosition +100+100, the window will be
X   positioned at +300+600 on the desktop.
X
X6. How does the icon gravity stuff work in relation to different areas
X   of the Virtual Desktop?  I don't know, and I don't really have the
X   time to look into the problem.  It might be nice to have seperate icon
X   regions in different quadrants of the Virtual Desktop.  If you use
X   icon managers and make them sticky then you don't have any problems.
X
X7. The small "virtual" windows in the panner will have the same color
X   as their corresponding window titlebars and icons have.
X
X8. The initialization files .tvtwmrc.<screen number> and .tvtwmrc will
X   be attempted before .twmrc.<screen number> .twmrc.
X
X
XNew Variables:
X
XVirtualDesktop "WIDTHxHEIGHT"
X  This variable simply specified the initial size of the Virtual Desktop.
X  Specifying this variable enables the Virtual Desktop feature.
X  Why didn't I use the same syntax as vtwm and also specify the panner
X  scale and geometry?  I don't know, lazy I guess.
X
XVirtualDesktopBackgroundPixmap "filename"
X  The pixmap image to display as the background of the Virtual Desktop window.
X
XVirtualDesktopBackground "color"
X  The background color of the VirtualDesktop window.  If
X  VirtualDesktopBackgroundPixmap is not set, the VirtualDesktop will have a
X  solid background of this color.
X
XVirtualDesktopForeground "color"
X  This color is only used if VirtualDesktopBackgroundPixmap is set.
X
XPannerGeometry "+-X+-Y"
X  Specifies the geometry at which the panner is to be placed.  The
X  default is "-0-0".
X
XPannerState "state"
X  This specifies the initial state of the panner.  Possible values
X  include "withdrawn", "iconic", and "normal".  The default state
X  is "normal".
X
XPannerScale scale
X  This specifies the scale of the panner.  The default number is 20.
X
XPannerBackgroundPixmap "filename"
X  The pixmap image to display as the background of the panner window.
X
XPannerBackground "color"
X  The background color of the panner window.  If PannerBackgroundPixmap
X  is not set, the panner will have a solid background of this color.
X
XPannerForeground "color"
X  This color is only used if PannerBackgroundPixmap is set.
X
XSticky { window list }
X  A list of windows that will come up in a sticky state.
X
XNew Commands:
X
Xf.panner	- toggle making the panner visible
Xf.scrollhome	- scroll the desktop to 0,0
Xf.scrollup	- scroll the desktop up one screenful
Xf.scrolldown	- scroll the desktop down one screenful
Xf.scrollleft	- scroll the desktop left on screenful
Xf.scrollright	- scroll the desktop right on screenful
Xf.panup		- same as f.scrollup
Xf.pandown	- same as f.scrolldown
Xf.panleft	- same as f.scrollleft
Xf.panright	- same as f.scrollright
Xf.stick		- toggle making a window sticky or not
X
X
XA version of xsetroot, called ssetroot has been included as an
Xexample of how to find the Virtual Desktop window.
X
X--
XTom LaStrange
X
XSolbourne Computer Inc.    ARPA: toml@Solbourne.COM
X1900 Pike Rd.              UUCP: ...!{boulder,sun}!stan!toml
XLongmont, CO  80501
SHAR_EOF
if test 7424 -ne "`wc -c < README.tvtwm`"
then
    echo shar: error transmitting "README.tvtwm" '(should have been 7424 characters)'
fi
fi
if test -f 'add_window.c'
then
    echo shar: will not over-write existing file "add_window.c"
else
echo extracting "add_window.c"
sed 's/^X//' >add_window.c <<'SHAR_EOF'
X/*****************************************************************************/
X/**       Copyright 1988 by Evans & Sutherland Computer Corporation,        **/
X/**                          Salt Lake City, Utah                           **/
X/**  Portions Copyright 1989 by the Massachusetts Institute of Technology   **/
X/**                        Cambridge, Massachusetts                         **/
X/**                                                                         **/
X/**                           All Rights Reserved                           **/
X/**                                                                         **/
X/**    Permission to use, copy, modify, and distribute this software and    **/
X/**    its documentation  for  any  purpose  and  without  fee is hereby    **/
X/**    granted, provided that the above copyright notice appear  in  all    **/
X/**    copies and that both  that  copyright  notice  and  this  permis-    **/
X/**    sion  notice appear in supporting  documentation,  and  that  the    **/
X/**    names of Evans & Sutherland and M.I.T. not be used in advertising    **/
X/**    in publicity pertaining to distribution of the  software  without    **/
X/**    specific, written prior permission.                                  **/
X/**                                                                         **/
X/**    EVANS & SUTHERLAND AND M.I.T. DISCLAIM ALL WARRANTIES WITH REGARD    **/
X/**    TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES  OF  MERCHANT-    **/
X/**    ABILITY  AND  FITNESS,  IN  NO  EVENT SHALL EVANS & SUTHERLAND OR    **/
X/**    M.I.T. BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL  DAM-    **/
X/**    AGES OR  ANY DAMAGES WHATSOEVER  RESULTING FROM LOSS OF USE, DATA    **/
X/**    OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER    **/
X/**    TORTIOUS ACTION, ARISING OUT OF OR IN  CONNECTION  WITH  THE  USE    **/
X/**    OR PERFORMANCE OF THIS SOFTWARE.                                     **/
X/*****************************************************************************/
X
X
X/**********************************************************************
X *
X * $XConsortium: add_window.c,v 1.140 90/03/23 11:42:33 jim Exp $
X *
X * Add a new window, put the titlbar and other stuff around
X * the window
X *
X * 31-Mar-88 Tom LaStrange        Initial Version.
X *
X **********************************************************************/
X
X#if !defined(lint) && !defined(SABER)
Xstatic char RCSinfo[]=
X"$XConsortium: add_window.c,v 1.140 90/03/23 11:42:33 jim Exp $";
X#endif
X
X#include <stdio.h>
X#include "twm.h"
X#include <X11/Xatom.h>
X#include "add_window.h"
X#include "util.h"
X#include "resize.h"
X#include "parse.h"
X#include "list.h"
X#include "events.h"
X#include "menus.h"
X#include "screen.h"
X#include "iconmgr.h"
X#include "move.h"
X
X#define gray_width 2
X#define gray_height 2
Xstatic char gray_bits[] = {
X   0x02, 0x01};
X
Xextern int FromVirtualDesktop;
X
Xint AddingX;
Xint AddingY;
Xint AddingW;
Xint AddingH;
X
Xstatic int PlaceX = 50;
Xstatic int PlaceY = 50;
Xstatic void CreateWindowTitlebarButtons();
Xstatic void getTWM_FLAGS();
X
Xchar NoName[] = "Untitled"; /* name if no name is specified */
X
X
X/************************************************************************
X *
X *  Procedure:
X *	GetGravityOffsets - map gravity to (x,y) offset signs for adding
X *		to x and y when window is mapped to get proper placement.
X * 
X ************************************************************************
X */
X
XGetGravityOffsets (tmp, xp, yp)
X    TwmWindow *tmp;			/* window from which to get gravity */
X    int *xp, *yp;			/* return values */
X{
X    static struct _gravity_offset {
X	int x, y;
X    } gravity_offsets[11] = {
X	{  0,  0 },			/* ForgetGravity */
X	{ -1, -1 },			/* NorthWestGravity */
X	{  0, -1 },			/* NorthGravity */
X	{  1, -1 },			/* NorthEastGravity */
X	{ -1,  0 },			/* WestGravity */
X	{  0,  0 },			/* CenterGravity */
X	{  1,  0 },			/* EastGravity */
X	{ -1,  1 },			/* SouthWestGravity */
X	{  0,  1 },			/* SouthGravity */
X	{  1,  1 },			/* SouthEastGravity */
X	{  0,  0 },			/* StaticGravity */
X    };
X    register int g = ((tmp->hints.flags & PWinGravity) 
X		      ? tmp->hints.win_gravity : NorthWestGravity);
X
X    if (g < ForgetGravity || g > StaticGravity) {
X	*xp = *yp = 0;
X    } else {
X	*xp = gravity_offsets[g].x;
X	*yp = gravity_offsets[g].y;
X    }
X}
X
X
X
X
X/***********************************************************************
X *
X *  Procedure:
X *	AddWindow - add a new window to the twm list
X *
X *  Returned Value:
X *	(TwmWindow *) - pointer to the TwmWindow structure
X *
X *  Inputs:
X *	w	- the window id of the window to add
X *	iconm	- flag to tell if this is an icon manager window
X *	iconp	- pointer to icon manager struct
X *
X ***********************************************************************
X */
X
XTwmWindow *
XAddWindow(w, iconm, iconp)
XWindow w;
Xint iconm;
XIconMgr *iconp;
X{
X    TwmWindow *tmp_win;			/* new twm window structure */
X    int stat;
X    XEvent event;
X    unsigned long valuemask;		/* mask for create windows */
X    XSetWindowAttributes attributes;	/* attributes for create windows */
X    int width, height;			/* tmp variable */
X    Atom actual_type;
X    int actual_format;
X    unsigned long nitems, bytesafter;
X    int ask_user;		/* don't know where to put the window */
X    long supplied = 0;
X    int gravx, gravy;			/* gravity signs for positioning */
X    int namelen;
X    int bw2;
X    int cancel;				/* cancel flag for window move */
X    int tmpX;				/* temp variable */
X    int saveDelta;			/* save the Scr->MoveDelta */
X
X#ifdef DEBUG
X    fprintf(stderr, "AddWindow: w = 0x%x\n", w);
X#endif
X
X    /* allocate space for the twm window */
X    tmp_win = (TwmWindow *)calloc(1, sizeof(TwmWindow));
X    tmp_win->w = w;
X    tmp_win->zoomed = ZOOM_NONE;
X    tmp_win->iconmgr = iconm;
X    tmp_win->iconmgrp = iconp;
X    tmp_win->cmaps.number_cwins = 0;
X
X    XSelectInput(dpy, tmp_win->w, PropertyChangeMask);
X    XGetWindowAttributes(dpy, tmp_win->w, &tmp_win->attr);
X    XFetchName(dpy, tmp_win->w, &tmp_win->name);
X    tmp_win->class = NoClass;
X    XGetClassHint(dpy, tmp_win->w, &tmp_win->class);
X    FetchWmProtocols (tmp_win);
X    FetchWmColormapWindows (tmp_win);
X
X    /*
X     * do initial clip; should look at window gravity
X     */
X    if (tmp_win->attr.width > Scr->MaxWindowWidth)
X      tmp_win->attr.width = Scr->MaxWindowWidth;
X    if (tmp_win->attr.height > Scr->MaxWindowHeight)
X      tmp_win->attr.height = Scr->MaxWindowHeight;
X
X    tmp_win->wmhints = XGetWMHints(dpy, tmp_win->w);
X    if (tmp_win->wmhints && (tmp_win->wmhints->flags & WindowGroupHint))
X	tmp_win->group = tmp_win->wmhints->window_group;
X    else
X	tmp_win->group = NULL;
X
X    if (!XGetWMNormalHints (dpy, tmp_win->w, &tmp_win->hints, &supplied))
X      tmp_win->hints.flags = 0;
X
X    /*
X     * The July 27, 1988 draft of the ICCCM ignores the size and position
X     * fields in the WM_NORMAL_HINTS property.
X     */
X
X    tmp_win->transient = Transient(tmp_win->w);
X    /*
X     * Don't bother user if:
X     * 
X     *     o  the window is a transient, or
X     * 
X     *     o  a USPosition was requested, or
X     * 
X     *     o  a PPosition was requested and UsePPosition is ON or
X     *        NON_ZERO if the window is at other than (0,0)
X     */
X    ask_user = TRUE;
X    if (tmp_win->transient || 
X	(tmp_win->hints.flags & USPosition) ||
X        ((tmp_win->hints.flags & PPosition) && Scr->UsePPosition &&
X	 (Scr->UsePPosition == PPOS_ON || 
X	  tmp_win->attr.x != 0 || tmp_win->attr.y != 0)))
X      ask_user = FALSE;
X
X    if (tmp_win->name == NULL)
X	tmp_win->name = NoName;
X    if (tmp_win->class.res_name == NULL)
X    	tmp_win->class.res_name = NoName;
X    if (tmp_win->class.res_class == NULL)
X    	tmp_win->class.res_class = NoName;
X
X    tmp_win->full_name = tmp_win->name;
X    namelen = strlen (tmp_win->name);
X
X    if (RestartPreviousState)
X	getTWM_FLAGS(tmp_win->w, &tmp_win->flags);
X
X    if (Scr->VirtualDesktop) {
X	tmp_win->sticky = 
X	    (short)LookInList(Scr->StickyL, tmp_win->full_name, &tmp_win->class);
X	if (tmp_win->w == Scr->Panner)
X	    tmp_win->sticky = True;
X
X	if (RestartPreviousState) {
X	    if (tmp_win->flags & TWM_FLAGS_STICKY)
X		tmp_win->sticky = True;
X	}
X    }
X
X    /* set flags for twm restart */
X    SetTWM_FLAGS(tmp_win);
X
X    tmp_win->highlight = Scr->Highlight && 
X	(!(short)LookInList(Scr->NoHighlight, tmp_win->full_name, 
X	    &tmp_win->class));
X
X    tmp_win->stackmode = Scr->StackMode &&
X	(!(short)LookInList(Scr->NoStackModeL, tmp_win->full_name, 
X	    &tmp_win->class));
X
X    tmp_win->titlehighlight = Scr->TitleHighlight && 
X	(!(short)LookInList(Scr->NoTitleHighlight, tmp_win->full_name, 
X	    &tmp_win->class));
X
X    tmp_win->auto_raise = (short)LookInList(Scr->AutoRaise, tmp_win->full_name,
X					    &tmp_win->class);
X    if (tmp_win->auto_raise) Scr->NumAutoRaises++;
X    tmp_win->iconify_by_unmapping = Scr->IconifyByUnmapping;
X    if (Scr->IconifyByUnmapping)
X    {
X	tmp_win->iconify_by_unmapping = iconm ? FALSE :
X	    !(short)LookInList(Scr->DontIconify, tmp_win->full_name,
X		&tmp_win->class);
X    }
X    tmp_win->iconify_by_unmapping |= 
X	(short)LookInList(Scr->IconifyByUn, tmp_win->full_name,
X	    &tmp_win->class);
X
X    if (LookInList(Scr->WindowRingL, tmp_win->full_name, &tmp_win->class)) {
X	if (Scr->Ring) {
X	    tmp_win->ring.next = Scr->Ring->ring.next;
X	    if (Scr->Ring->ring.next->ring.prev)
X	      Scr->Ring->ring.next->ring.prev = tmp_win;
X	    Scr->Ring->ring.next = tmp_win;
X	    tmp_win->ring.prev = Scr->Ring;
X	} else {
X	    tmp_win->ring.next = tmp_win->ring.prev = Scr->Ring = tmp_win;
X	}
X    } else
X      tmp_win->ring.next = tmp_win->ring.prev = NULL;
X    tmp_win->ring.cursor_valid = False;
X
X    tmp_win->squeeze_info = NULL;
X#ifdef SHAPE
X    /*
X     * get the squeeze information; note that this does not have to be freed
X     * since it is coming from the screen list
X     */
X    if (HasShape) {
X	if (!LookInList (Scr->DontSqueezeTitleL, tmp_win->full_name, 
X			 &tmp_win->class)) {
X	    tmp_win->squeeze_info = (SqueezeInfo *)
X	      LookInList (Scr->SqueezeTitleL, tmp_win->full_name,
X			  &tmp_win->class);
X	    if (!tmp_win->squeeze_info) {
X		static SqueezeInfo default_squeeze = { J_LEFT, 0, 0 };
X		if (Scr->SqueezeTitle)
X		  tmp_win->squeeze_info = &default_squeeze;
X	    }
X	}
X      }
X#endif
X
X    tmp_win->old_bw = tmp_win->attr.border_width;
X
X    if (Scr->ClientBorderWidth) {
X    	tmp_win->frame_bw = tmp_win->old_bw;
X    } else {
X    	tmp_win->frame_bw = Scr->BorderWidth;
X    }
X    bw2 = tmp_win->frame_bw * 2;
X
X    tmp_win->title_height = Scr->TitleHeight + tmp_win->frame_bw;
X    if (Scr->NoTitlebar)
X        tmp_win->title_height = 0;
X    if (LookInList(Scr->MakeTitle, tmp_win->full_name, &tmp_win->class))
X        tmp_win->title_height = Scr->TitleHeight + tmp_win->frame_bw;
X    if (LookInList(Scr->NoTitle, tmp_win->full_name, &tmp_win->class))
X        tmp_win->title_height = 0;
X
X    /* if it is a transient window, don't put a title on it */
X    if (tmp_win->transient && !Scr->DecorateTransients)
X	tmp_win->title_height = 0;
X
X    if (LookInList(Scr->StartIconified, tmp_win->full_name, &tmp_win->class))
X    {
X	if (!tmp_win->wmhints)
X	{
X	    tmp_win->wmhints = (XWMHints *)malloc(sizeof(XWMHints));
X	    tmp_win->wmhints->flags = 0;
X	}
X	tmp_win->wmhints->initial_state = IconicState;
X	tmp_win->wmhints->flags |= StateHint;
X    }
X
X    if (!(supplied & PWinGravity)) SimulateWinGravity (tmp_win);
X    GetGravityOffsets (tmp_win, &gravx, &gravy);
X
X
X#ifdef DEBUG
X	fprintf(stderr, "  position window  %d, %d  %dx%d\n", 
X	    tmp_win->attr.x,
X	    tmp_win->attr.y,
X	    tmp_win->attr.width,
X	    tmp_win->attr.height);
X#endif
X
X    if (!Scr->ClientBorderWidth) {	/* need to adjust for twm borders */
X	int delta = tmp_win->attr.border_width - tmp_win->frame_bw;
X	tmp_win->attr.x += gravx * delta;
X	tmp_win->attr.y += gravy * delta;
X    }
X
X    tmp_win->title_width = tmp_win->attr.width;
X
X    if (tmp_win->old_bw) XSetWindowBorderWidth (dpy, tmp_win->w, 0);
X
X    tmp_win->name_width = XTextWidth(Scr->TitleBarFont.font, tmp_win->name,
X				     namelen);
X
X    if (XGetWindowProperty (dpy, tmp_win->w, XA_WM_ICON_NAME, 0L, 200L, False,
X			    XA_STRING, &actual_type, &actual_format, &nitems,
X			    &bytesafter,(unsigned char **)&tmp_win->icon_name))
X	tmp_win->icon_name = tmp_win->name;
X
X    if (tmp_win->icon_name == NULL)
X	tmp_win->icon_name = tmp_win->name;
X
X    tmp_win->iconified = FALSE;
X    tmp_win->icon = FALSE;
X    tmp_win->icon_on = FALSE;
X
X    XGrabServer(dpy);
X
X    /*
X     * Make sure the client window still exists.  We don't want to leave an
X     * orphan frame window if it doesn't.  Since we now have the server 
X     * grabbed, the window can't disappear later without having been 
X     * reparented, so we'll get a DestroyNotify for it.  We won't have 
X     * gotten one for anything up to here, however.
X     */
X    if (XGetGeometry(dpy, tmp_win->w, &JunkRoot, &JunkX, &JunkY,
X		     &JunkWidth, &JunkHeight, &JunkBW, &JunkDepth) == 0)
X    {
X	free((char *)tmp_win);
X	XUngrabServer(dpy);
X	return(NULL);
X    }
X
X    /* add the window into the twm list */
X    tmp_win->next = Scr->TwmRoot.next;
X    if (Scr->TwmRoot.next != NULL)
X	Scr->TwmRoot.next->prev = tmp_win;
X    tmp_win->prev = &Scr->TwmRoot;
X    Scr->TwmRoot.next = tmp_win;
X
X    /* get all the colors for the window */
X
X    tmp_win->border = Scr->BorderColor;
X    tmp_win->icon_border = Scr->IconBorderColor;
X    tmp_win->border_tile.fore = Scr->BorderTileC.fore;
X    tmp_win->border_tile.back = Scr->BorderTileC.back;
X    tmp_win->title.fore = Scr->TitleC.fore;
X    tmp_win->title.back = Scr->TitleC.back;
X    tmp_win->iconc.fore = Scr->IconC.fore;
X    tmp_win->iconc.back = Scr->IconC.back;
X
X    GetColorFromList(Scr->BorderColorL, tmp_win->full_name, &tmp_win->class,
X	&tmp_win->border);
X    GetColorFromList(Scr->IconBorderColorL, tmp_win->full_name, &tmp_win->class,
X	&tmp_win->icon_border);
X    GetColorFromList(Scr->BorderTileForegroundL, tmp_win->full_name,
X	&tmp_win->class, &tmp_win->border_tile.fore);
X    GetColorFromList(Scr->BorderTileBackgroundL, tmp_win->full_name,
X	&tmp_win->class, &tmp_win->border_tile.back);
X    GetColorFromList(Scr->TitleForegroundL, tmp_win->full_name, &tmp_win->class,
X	&tmp_win->title.fore);
X    GetColorFromList(Scr->TitleBackgroundL, tmp_win->full_name, &tmp_win->class,
X	&tmp_win->title.back);
X    GetColorFromList(Scr->IconForegroundL, tmp_win->full_name, &tmp_win->class,
X	&tmp_win->iconc.fore);
X    GetColorFromList(Scr->IconBackgroundL, tmp_win->full_name, &tmp_win->class,
X	&tmp_win->iconc.back);
X
X
X    /* create windows */
X
X    tmp_win->frame_width = tmp_win->attr.width;
X    tmp_win->frame_height = tmp_win->attr.height + tmp_win->title_height;
X
X    valuemask = CWBackPixmap | CWBorderPixel | CWCursor | CWEventMask;
X    attributes.background_pixmap = None;
X    attributes.border_pixel = tmp_win->border;
X    attributes.cursor = Scr->FrameCursor;
X    attributes.event_mask = (SubstructureRedirectMask | 
X			     ButtonPressMask | ButtonReleaseMask |
X			     EnterWindowMask | LeaveWindowMask);
X    if (tmp_win->attr.save_under) {
X	attributes.save_under = True;
X	valuemask |= CWSaveUnder;
X    }
X
X    if (Scr->VirtualDesktop) {
X	if (tmp_win->sticky)
X	    tmp_win->root = Scr->Root;
X	else
X	    tmp_win->root = Scr->VirtualDesktop;
X
X	tmp_win->virtualWindow = MakeVirtual(tmp_win,
X	    tmp_win->frame_x, tmp_win->frame_y,
X	    tmp_win->frame_width, tmp_win->frame_height,
X	    tmp_win->title.back, tmp_win->border);
X    }
X    else
X	tmp_win->root = Scr->Root;
X
X    tmp_win->frame = XCreateWindow (dpy, tmp_win->root, 0, 0,
X				    (unsigned int) tmp_win->frame_width,
X				    (unsigned int) tmp_win->frame_height,
X				    (unsigned int) tmp_win->frame_bw,
X				    Scr->d_depth,
X				    (unsigned int) CopyFromParent,
X				    Scr->d_visual, valuemask, &attributes);
X    if (tmp_win->title_height)
X    {
X	valuemask = (CWEventMask | CWBorderPixel | CWBackPixel);
X	attributes.event_mask = (KeyPressMask | ButtonPressMask |
X				 ButtonReleaseMask | ExposureMask);
X	attributes.border_pixel = tmp_win->border;
X	attributes.background_pixel = tmp_win->title.back;
X	tmp_win->title_w = XCreateWindow (dpy, tmp_win->frame, 
X					  -tmp_win->frame_bw,
X					  -tmp_win->frame_bw,
X					  (unsigned int) tmp_win->attr.width, 
X					  (unsigned int) Scr->TitleHeight,
X					  (unsigned int) tmp_win->frame_bw,
X					  Scr->d_depth,
X					  (unsigned int) CopyFromParent,
X					  Scr->d_visual, valuemask,
X					  &attributes);
X    }
X    else {
X	tmp_win->title_w = 0;
X	tmp_win->squeeze_info = NULL;
X    }
X
X    if (tmp_win->highlight)
X    {
X	tmp_win->gray = XCreatePixmapFromBitmapData(dpy, Scr->Root, 
X	    gray_bits, gray_width, gray_height, 
X	    tmp_win->border_tile.fore, tmp_win->border_tile.back,
X	    Scr->d_depth);
X
X	SetBorder (tmp_win, False);
X    }
X    else
X	tmp_win->gray = None;
X
X	
X    if (tmp_win->title_w) {
X	CreateWindowTitlebarButtons (tmp_win);
X	ComputeTitleLocation (tmp_win);
X	XMoveWindow (dpy, tmp_win->title_w,
X		     tmp_win->title_x, tmp_win->title_y);
X	XDefineCursor(dpy, tmp_win->title_w, Scr->TitleCursor);
X    }
X
X    valuemask = (CWEventMask | CWDontPropagate);
X    attributes.event_mask = (StructureNotifyMask | PropertyChangeMask |
X			     ColormapChangeMask | VisibilityChangeMask |
X			     EnterWindowMask | LeaveWindowMask);
X    if (tmp_win->w == Scr->Panner)
X	attributes.event_mask |= ExposureMask;
X    attributes.do_not_propagate_mask = ButtonPressMask | ButtonReleaseMask;
X    XChangeWindowAttributes (dpy, tmp_win->w, valuemask, &attributes);
X
X#ifdef SHAPE
X    if (HasShape)
X	XShapeSelectInput (dpy, tmp_win->w, ShapeNotifyMask);
X#endif
X	
X    if (tmp_win->title_w) {
X	XMapWindow (dpy, tmp_win->title_w);
X    }
X
X#ifdef SHAPE
X    if (HasShape) {
X	int xws, yws, xbs, ybs;
X	unsigned wws, hws, wbs, hbs;
X	int boundingShaped, clipShaped;
X
X	XShapeSelectInput (dpy, tmp_win->w, ShapeNotifyMask);
X	XShapeQueryExtents (dpy, tmp_win->w,
X			    &boundingShaped, &xws, &yws, &wws, &hws,
X			    &clipShaped, &xbs, &ybs, &wbs, &hbs);
X	tmp_win->wShaped = boundingShaped;
X    }
X#endif
X
X    if (!tmp_win->iconmgr)
X	XAddToSaveSet(dpy, tmp_win->w);
X	
X    XReparentWindow(dpy, tmp_win->w, tmp_win->frame, 0, tmp_win->title_height);
X    /*
X     * Reparenting generates an UnmapNotify event, followed by a MapNotify.
X     * Set the map state to FALSE to prevent a transition back to
X     * WithdrawnState in HandleUnmapNotify.  Map state gets set correctly
X     * again in HandleMapNotify.
X     */
X    tmp_win->mapped = FALSE;
X
X    /*
X     * do any prompting for position
X     */
X    if (HandlingEvents && ask_user) {
X      if (Scr->RandomPlacement) {	/* just stick it somewhere */
X	if ((PlaceX + tmp_win->attr.width) > Scr->MyDisplayWidth)
X	    PlaceX = 50;
X	if ((PlaceY + tmp_win->attr.height) > Scr->MyDisplayHeight)
X	    PlaceY = 50;
X
X	tmp_win->attr.x = PlaceX;
X	tmp_win->attr.y = PlaceY;
X	PlaceX += 30;
X	PlaceY += 30;
X	if (tmp_win->root == Scr->VirtualDesktop) {
X	    tmp_win->attr.x += Scr->vdtPositionX;
X	    tmp_win->attr.y += Scr->vdtPositionY;
X	}
X      } else {				/* else prompt */
X	if (!(tmp_win->wmhints && tmp_win->wmhints->flags & StateHint &&
X	      tmp_win->wmhints->initial_state == IconicState))
X	{
X	    Bool firsttime = True;
X
X	    /* better wait until all the mouse buttons have been 
X	     * released.
X	     */
X	    while (TRUE)
X	    {
X		XUngrabServer(dpy);
X		XSync(dpy, 0);
X		XGrabServer(dpy);
X
X		JunkMask = 0;
X		if (!XQueryPointer (dpy, Scr->Root, &JunkRoot, 
X				    &JunkChild, &JunkX, &JunkY,
X				    &AddingX, &AddingY, &JunkMask))
X		  JunkMask = 0;
X
X		JunkMask &= (Button1Mask | Button2Mask | Button3Mask |
X			     Button4Mask | Button5Mask);
X
X		/*
X		 * watch out for changing screens
X		 */
X		if (firsttime) {
X		    if (JunkRoot != Scr->Root) {
X			register int scrnum;
X
X			for (scrnum = 0; scrnum < NumScreens; scrnum++) {
X			    if (JunkRoot == RootWindow (dpy, scrnum)) break;
X			}
X
X			if (scrnum != NumScreens) PreviousScreen = scrnum;
X		    }
X		    firsttime = False;
X		}
X
X		/*
X		 * wait for buttons to come up; yuck
X		 */
X		if (JunkMask != 0) continue;
X
X		/* 
X		 * this will cause a warp to the indicated root
X		 */
X		stat = XGrabPointer(dpy, Scr->Root, True,
X		    PointerMotionMask | ButtonPressMask | ButtonReleaseMask |
X		    EnterWindowMask | LeaveWindowMask,
X		    GrabModeAsync, GrabModeAsync,
X		    Scr->Root, UpperLeftCursor, CurrentTime);
X
X		if (stat == GrabSuccess)
X		    break;
X	    }
X
X	    width = (SIZE_HINDENT + XTextWidth (Scr->SizeFont.font,
X						tmp_win->name, namelen));
X	    height = Scr->SizeFont.height + SIZE_VINDENT * 2;
X	    
X	    XResizeWindow (dpy, Scr->SizeWindow, width + SIZE_HINDENT, height);
X	    XMapRaised(dpy, Scr->SizeWindow);
X	    InstallRootColormap();
X
X	    FBF(Scr->DefaultC.fore, Scr->DefaultC.back,
X		Scr->SizeFont.font->fid);
X	    XDrawImageString (dpy, Scr->SizeWindow, Scr->NormalGC,
X			      SIZE_HINDENT,
X			      SIZE_VINDENT + Scr->SizeFont.font->ascent,
X			      tmp_win->name, namelen);
X
X	    AddingW = tmp_win->attr.width + bw2;
X	    AddingH = tmp_win->attr.height + tmp_win->title_height + bw2;
X
X	    XQueryPointer(dpy, Scr->Root, &JunkRoot, &JunkChild,
X		&AddingX, &AddingY, &JunkX, &JunkY, &JunkMask);
X	    if (tmp_win->root == Scr->VirtualDesktop)
X		XMoveWindow(dpy, tmp_win->frame, AddingX+Scr->vdtPositionX,
X		    AddingY+Scr->vdtPositionY);
X	    else
X		XMoveWindow(dpy, tmp_win->frame, AddingX, AddingY);
X
X	    saveDelta = Scr->MoveDelta;
X	    Scr->MoveDelta = 0;
X	    StartMove(tmp_win, tmp_win->frame, tmp_win->title_height,
X		&AddingX, &AddingY, &cancel, OUT_PANNER, 1, 0, 0, True, False);
X	    Scr->MoveDelta = saveDelta;
X
X	    if (cancel == Button2) {
X		int lastx, lasty;
X
X		Scr->SizeStringOffset = width +
X		  XTextWidth(Scr->SizeFont.font, ": ", 2);
X		XResizeWindow (dpy, Scr->SizeWindow, Scr->SizeStringOffset +
X			       Scr->SizeStringWidth, height);
X		XDrawImageString (dpy, Scr->SizeWindow, Scr->NormalGC, width,
X				  SIZE_VINDENT + Scr->SizeFont.font->ascent,
X				  ": ", 2);
X		if (Scr->AutoRelativeResize) {
X		    int dx = (tmp_win->attr.width / 4);
X		    int dy = (tmp_win->attr.height / 4);
X		    
X#define HALF_AVE_CURSOR_SIZE 8		/* so that it is visible */
X		    if (dx < HALF_AVE_CURSOR_SIZE) dx = HALF_AVE_CURSOR_SIZE;
X		    if (dy < HALF_AVE_CURSOR_SIZE) dy = HALF_AVE_CURSOR_SIZE;
X#undef HALF_AVE_CURSOR_SIZE
X		    dx += (tmp_win->frame_bw + 1);
X		    dy += (bw2 + tmp_win->title_height + 1);
X		    if (AddingX + dx >= Scr->MyDisplayWidth)
X		      dx = Scr->MyDisplayWidth - AddingX - 1;
X		    if (AddingY + dy >= Scr->MyDisplayHeight)
X		      dy = Scr->MyDisplayHeight - AddingY - 1;
X		    if (dx > 0 && dy > 0)
X		      XWarpPointer (dpy, None, None, 0, 0, 0, 0, dx, dy);
X		} else {
X		    XWarpPointer (dpy, None, Scr->Root, 0, 0, 0, 0,
X				  AddingX + AddingW/2, AddingY + AddingH/2);
X		}
X		AddStartResize(tmp_win, AddingX, AddingY, AddingW, AddingH);
X
X		lastx = -10000;
X		lasty = -10000;
X		while (TRUE)
X		{
X		    /*
X		     * XXX - if we are going to do a loop, we ought to consider
X		     * using multiple GXxor lines so that we don't need to 
X		     * grab the server.
X		     */
X		    XQueryPointer(dpy, Scr->Root, &JunkRoot, &JunkChild,
X			&JunkX, &JunkY, &AddingX, &AddingY, &JunkMask);
X
X		    if (lastx != AddingX || lasty != AddingY)
X		    {
X			DoResize(AddingX, AddingY, tmp_win);
X
X			lastx = AddingX;
X			lasty = AddingY;
X		    }
X
X		    if (XCheckMaskEvent(dpy, ButtonReleaseMask, &event))
X		    {
X			AddEndResize(tmp_win);
X			break;
X		    }
X		}
X	    } 
X	    else if (cancel == Button3)
X	    {
X		int maxw = Scr->MyDisplayWidth - AddingX - bw2;
X		int maxh = Scr->MyDisplayHeight - AddingY - bw2;
X
X		/*
X		 * Make window go to bottom of screen, and clip to right edge.
X		 * This is useful when popping up large windows and fixed
X		 * column text windows.
X		 */
X		if (AddingW > maxw) AddingW = maxw;
X		AddingH = maxh;
X
X		ConstrainSize (tmp_win, &AddingW, &AddingH);  /* w/o borders */
X		AddingW += bw2;
X		AddingH += bw2;
X	    }
X	    else
X	    {
X		XMaskEvent(dpy, ButtonReleaseMask, &event);
X	    }
X
X	    MoveOutline(Scr->Root, 0, 0, 0, 0, 0, 0);
X	    XUnmapWindow(dpy, Scr->SizeWindow);
X	    UninstallRootColormap();
X	    XUngrabPointer(dpy, CurrentTime);
X
X	    tmp_win->attr.x = AddingX;
X	    tmp_win->attr.y = AddingY + tmp_win->title_height;
X	    tmp_win->attr.width = AddingW - bw2;
X	    tmp_win->attr.height = AddingH - tmp_win->title_height - bw2;
X
X	    XUngrabServer(dpy);
X	}
X      }
X    } else {				/* put it where asked, mod title bar */
X	/* if the gravity is towards the top, move it by the title height */
X	if (gravy < 0) tmp_win->attr.y -= gravy * tmp_win->title_height;
X    }
X
X    tmp_win->frame_x = tmp_win->attr.x + tmp_win->old_bw - tmp_win->frame_bw;
X    tmp_win->frame_y = tmp_win->attr.y - tmp_win->title_height +
X	tmp_win->old_bw - tmp_win->frame_bw;
X    tmp_win->frame_width = tmp_win->attr.width;
X    tmp_win->frame_height = tmp_win->attr.height + tmp_win->title_height;
X
X    /* Possibly adjust the position of the window if PPosition is
X     * being used.  In our case, if PPosition is set, we will translate
X     * the coordinates of the window into virtual desktop coordinates
X     */
X    if (tmp_win->root == Scr->VirtualDesktop &&
X	(!FromVirtualDesktop && tmp_win->transient) ||
X    	(ask_user == FALSE && (tmp_win->hints.flags & PPosition)))
X    {
X	tmp_win->frame_x += Scr->vdtPositionX;
X	tmp_win->frame_y += Scr->vdtPositionY;
X    }
X
X    /* tell the window what his root window id is */
X    /* this MUST com before SetupFrame so the synthetic ConfigureNotify
X     * event follows this property
X     */
X    SetSWM_ROOT(tmp_win);
X
X    tmpX = tmp_win->frame_x;
X    tmp_win->frame_x = -tmpX;	/* this will case a synthetice ConfigureNotify event */
X    SetupFrame (tmp_win, tmpX, tmp_win->frame_y,
X		tmp_win->frame_width, tmp_win->frame_height, -1, True);
X
X    /* wait until the window is iconified and the icon window is mapped
X     * before creating the icon window 
X     */
X    tmp_win->icon_w = NULL;
X
X    if (!tmp_win->iconmgr)
X    {
X	GrabButtons(tmp_win);
X	GrabKeys(tmp_win);
X    }
X
X    (void) AddIconManager(tmp_win);
X
X    XSaveContext(dpy, tmp_win->w, TwmContext, (caddr_t) tmp_win);
X    XSaveContext(dpy, tmp_win->w, ScreenContext, (caddr_t) Scr);
X    XSaveContext(dpy, tmp_win->frame, TwmContext, (caddr_t) tmp_win);
X    XSaveContext(dpy, tmp_win->frame, ScreenContext, (caddr_t) Scr);
X    if (tmp_win->title_height)
X    {
X	int i;
X	int nb = Scr->TBInfo.nleft + Scr->TBInfo.nright;
X
X	XSaveContext(dpy, tmp_win->title_w, TwmContext, (caddr_t) tmp_win);
X	XSaveContext(dpy, tmp_win->title_w, ScreenContext, (caddr_t) Scr);
X	for (i = 0; i < nb; i++) {
X	    XSaveContext(dpy, tmp_win->titlebuttons[i].window, TwmContext,
X			 (caddr_t) tmp_win);
X	    XSaveContext(dpy, tmp_win->titlebuttons[i].window, ScreenContext,
X			 (caddr_t) Scr);
X	}
X	if (tmp_win->hilite_w)
X	{
X	    XSaveContext(dpy, tmp_win->hilite_w, TwmContext, (caddr_t)tmp_win);
X	    XSaveContext(dpy, tmp_win->hilite_w, ScreenContext, (caddr_t)Scr);
X	}
X    }
X
X    XUngrabServer(dpy);
X
X    /* if we were in the middle of a menu activated function, regrab
X     * the pointer 
X     */
X    if (RootFunction)
X	ReGrab();
X
X    return (tmp_win);
X}
X
X
X/***********************************************************************
X *
X *  Procedure:
X *	MappedNotOverride - checks to see if we should really
X *		put a twm frame on the window
X *
X *  Returned Value:
X *	TRUE	- go ahead and frame the window
X *	FALSE	- don't frame the window
X *
X *  Inputs:
X *	w	- the window to check
X *
X ***********************************************************************
X */
X
Xint
XMappedNotOverride(w)
X    Window w;
X{
X    XWindowAttributes wa;
X
X    XGetWindowAttributes(dpy, w, &wa);
X    return ((wa.map_state != IsUnmapped) && (wa.override_redirect != True));
X}
X
X
X/***********************************************************************
X * 
X *  Procedure:
X *      AddDefaultBindings - attach default bindings so that naive users
X *      don't get messed up if they provide a minimal twmrc.
X */
Xstatic void do_add_binding (button, context, modifier, func)
X    int button, context, modifier;
X    int func;
X{
X    MouseButton *mb = &Scr->Mouse[button][context][modifier];
X
X    if (mb->func) return;		/* already defined */
X
X    mb->func = func;
X    mb->item = NULL;
X}
X
XAddDefaultBindings ()
X{
X    /*
X     * The bindings are stored in Scr->Mouse, indexed by
X     * Mouse[button_number][C_context][modifier].
X     */
X
X#define NoModifierMask 0
X
X    do_add_binding (Button1, C_TITLE, NoModifierMask, F_MOVE);
X    do_add_binding (Button1, C_ICON, NoModifierMask, F_ICONIFY);
X    do_add_binding (Button1, C_ICONMGR, NoModifierMask, F_ICONIFY);
X
X    do_add_binding (Button2, C_TITLE, NoModifierMask, F_RAISELOWER);
X    do_add_binding (Button2, C_ICON, NoModifierMask, F_ICONIFY);
X    do_add_binding (Button2, C_ICONMGR, NoModifierMask, F_ICONIFY);
X
X#undef NoModifierMask
X}
X
X
X
X
X/***********************************************************************
X *
X *  Procedure:
X *	GrabButtons - grab needed buttons for the window
X *
X *  Inputs:
X *	tmp_win - the twm window structure to use
X *
X ***********************************************************************
X */
X
Xvoid
XGrabButtons(tmp_win)
XTwmWindow *tmp_win;
X{
X    int i, j;
X
X    for (i = 0; i < MAX_BUTTONS+1; i++)
X    {
X	for (j = 0; j < MOD_SIZE; j++)
X	{
X	    if (Scr->Mouse[i][C_WINDOW][j].func != NULL)
X	    {
X		XGrabButton(dpy, i, j, tmp_win->w,
X		    True, ButtonPressMask | ButtonReleaseMask,
X		    GrabModeAsync, GrabModeAsync, None, Scr->FrameCursor);
X	    }
X	}
X    }
X}
X
X/***********************************************************************
X *
X *  Procedure:
X *	GrabKeys - grab needed keys for the window
X *
X *  Inputs:
X *	tmp_win - the twm window structure to use
X *
X ***********************************************************************
X */
X
Xvoid
XGrabKeys(tmp_win)
XTwmWindow *tmp_win;
X{
X    FuncKey *tmp;
X    IconMgr *p;
X
X    for (tmp = Scr->FuncKeyRoot.next; tmp != NULL; tmp = tmp->next)
X    {
X	switch (tmp->cont)
X	{
X	case C_WINDOW:
X	    XGrabKey(dpy, tmp->keycode, tmp->mods, tmp_win->w, True,
X		GrabModeAsync, GrabModeAsync);
X	    break;
X
X	case C_ICON:
X	    if (tmp_win->icon_w)
X		XGrabKey(dpy, tmp->keycode, tmp->mods, tmp_win->icon_w, True,
X		    GrabModeAsync, GrabModeAsync);
X
X	case C_TITLE:
X	    if (tmp_win->title_w)
X		XGrabKey(dpy, tmp->keycode, tmp->mods, tmp_win->title_w, True,
X		    GrabModeAsync, GrabModeAsync);
X	    break;
X
X	case C_NAME:
X	    XGrabKey(dpy, tmp->keycode, tmp->mods, tmp_win->w, True,
X		GrabModeAsync, GrabModeAsync);
X	    if (tmp_win->icon_w)
X		XGrabKey(dpy, tmp->keycode, tmp->mods, tmp_win->icon_w, True,
X		    GrabModeAsync, GrabModeAsync);
X	    if (tmp_win->title_w)
X		XGrabKey(dpy, tmp->keycode, tmp->mods, tmp_win->title_w, True,
X		    GrabModeAsync, GrabModeAsync);
X	    break;
X	/*
X	case C_ROOT:
X	    XGrabKey(dpy, tmp->keycode, tmp->mods, Scr->Root, True,
X		GrabModeAsync, GrabModeAsync);
X	    break;
X	*/
X	}
X    }
X    for (tmp = Scr->FuncKeyRoot.next; tmp != NULL; tmp = tmp->next)
X    {
X	if (tmp->cont == C_ICONMGR && !Scr->NoIconManagers)
X	{
X	    for (p = &Scr->iconmgr; p != NULL; p = p->next)
X	    {
X		XUngrabKey(dpy, tmp->keycode, tmp->mods, p->twm_win->w);
X	    }
X	}
X    }
X}
X
Xstatic Window CreateHighlightWindow (tmp_win)
X    TwmWindow *tmp_win;
X{
X    XSetWindowAttributes attributes;	/* attributes for create windows */
X    Pixmap pm = None;
X    GC gc;
X    XGCValues gcv;
X    unsigned long valuemask;
X    int h = (Scr->TitleHeight - 2 * Scr->FramePadding);
X    Window w;
X
X
X    /*
X     * If a special highlight pixmap was given, use that.  Otherwise,
X     * use a nice, even gray pattern.  The old horizontal lines look really
X     * awful on interlaced monitors (as well as resembling other looks a
X     * little bit too closely), but can be used by putting
X     *
X     *                 Pixmaps { TitleHighlight "hline2" }
X     *
X     * (or whatever the horizontal line bitmap is named) in the startup
X     * file.  If all else fails, use the foreground color to look like a 
X     * solid line.
X     */
X    if (!Scr->hilitePm) {
X	Scr->hilitePm = XCreateBitmapFromData (dpy, tmp_win->title_w, 
X					       gray_bits, gray_width, 
X					       gray_height);
X	Scr->hilite_pm_width = gray_width;
X	Scr->hilite_pm_height = gray_height;
X    }
X    if (Scr->hilitePm) {
X	pm = XCreatePixmap (dpy, tmp_win->title_w,
X			    Scr->hilite_pm_width, Scr->hilite_pm_height,
X			    Scr->d_depth);
X	gcv.foreground = tmp_win->title.fore;
X	gcv.background = tmp_win->title.back;
X	gcv.graphics_exposures = False;
X	gc = XCreateGC (dpy, pm,
X			(GCForeground|GCBackground|GCGraphicsExposures),
X			&gcv);
X	if (gc) {
X	    XCopyPlane (dpy, Scr->hilitePm, pm, gc, 0, 0, 
X			Scr->hilite_pm_width, Scr->hilite_pm_height,
X			0, 0, 1);
X	    XFreeGC (dpy, gc);
X	} else {
X	    XFreePixmap (dpy, pm);
X	    pm = None;
X	}
X    }
X    if (pm) {
X	valuemask = CWBackPixmap;
X	attributes.background_pixmap = pm;
X    } else {
X	valuemask = CWBackPixel;
X	attributes.background_pixel = tmp_win->title.fore;
X    }
X
X    w = XCreateWindow (dpy, tmp_win->title_w, 0, Scr->FramePadding,
X		       (unsigned int) Scr->TBInfo.width, (unsigned int) h,
X		       (unsigned int) 0,
X		       Scr->d_depth, (unsigned int) CopyFromParent,
X		       Scr->d_visual, valuemask, &attributes);
X    if (pm) XFreePixmap (dpy, pm);
X    return w;
X}
X
X
Xvoid ComputeCommonTitleOffsets ()
X{
X    int buttonwidth = (Scr->TBInfo.width + Scr->TBInfo.pad);
X
X    Scr->TBInfo.leftx = Scr->TBInfo.rightoff = Scr->FramePadding;
X    if (Scr->TBInfo.nleft > 0)
X      Scr->TBInfo.leftx += Scr->ButtonIndent;
X    Scr->TBInfo.titlex = (Scr->TBInfo.leftx +
X			  (Scr->TBInfo.nleft * buttonwidth) - Scr->TBInfo.pad +
X			  Scr->TitlePadding);
X    if (Scr->TBInfo.nright > 0)
X      Scr->TBInfo.rightoff += (Scr->ButtonIndent +
X			       ((Scr->TBInfo.nright * buttonwidth) -
X				Scr->TBInfo.pad));
X    return;
X}
X
Xvoid ComputeWindowTitleOffsets (tmp_win, width, squeeze)
X    TwmWindow *tmp_win;
X    Bool squeeze;
X{
X    tmp_win->highlightx = (Scr->TBInfo.titlex + tmp_win->name_width);
X    if (tmp_win->hilite_w || Scr->TBInfo.nright > 0) 
X      tmp_win->highlightx += Scr->TitlePadding;
X    tmp_win->rightx = width - Scr->TBInfo.rightoff;
X    if (squeeze && tmp_win->squeeze_info) {
X	int rx = (tmp_win->highlightx + 
X		  (tmp_win->hilite_w
X		    ? Scr->TBInfo.width * 2 : 0) +
X		  (Scr->TBInfo.nright > 0 ? Scr->TitlePadding : 0) +
X		  Scr->FramePadding);
X	if (rx < tmp_win->rightx) tmp_win->rightx = rx;
X    }
X    return;
X}
X
X
X/*
X * ComputeTitleLocation - calculate the position of the title window; we need
X * to take the frame_bw into account since we want (0,0) of the title window
X * to line up with (0,0) of the frame window.
X */
Xvoid ComputeTitleLocation (tmp)
X    register TwmWindow *tmp;
X{
X    tmp->title_x = -tmp->frame_bw;
X    tmp->title_y = -tmp->frame_bw;
X
X#ifdef SHAPE
X    if (tmp->squeeze_info) {
X	register SqueezeInfo *si = tmp->squeeze_info;
X	int basex;
X	int maxwidth = tmp->frame_width;
X	int tw = tmp->title_width;
X
X	/*
X	 * figure label base from squeeze info (justification fraction)
X	 */
X	if (si->denom == 0) {	/* num is pixel based */
X	    if ((basex = si->num) == 0) {  /* look for special cases */
X		switch (si->justify) {
X		  case J_RIGHT:
X		    basex = maxwidth;
X		    break;
X		  case J_CENTER:
X		    basex = maxwidth / 2;
X		break;
X		}
X	    }
X	} else {			/* num/denom is fraction */
X	    basex = ((si->num * maxwidth) / si->denom);
X	    if (si->num < 0) basex += maxwidth;
X	}
X
X	/*
X	 * adjust for left (nop), center, right justify and clip
X	 */
X	switch (si->justify) {
X	  case J_CENTER:
X	    basex -= tw / 2;
X	    break;
X	  case J_RIGHT:
X	    basex -= tw - 1;
X	    break;
X	}
X	if (basex > maxwidth - tw + 1)
X	  basex = maxwidth - tw + 1;
X	if (basex < 0) basex = 0;
X
X	tmp->title_x = basex - tmp->frame_bw;
X    }
X#endif
X}
X
X
Xstatic void CreateWindowTitlebarButtons (tmp_win)
X    TwmWindow *tmp_win;
X{
X    unsigned long valuemask;		/* mask for create windows */
X    XSetWindowAttributes attributes;	/* attributes for create windows */
X    int leftx, rightx, y;
X    TitleButton *tb;
X    int nb;
X
X    if (tmp_win->title_height == 0)
X    {
X	tmp_win->hilite_w = 0;
X	return;
X    }
X
X
X    /*
X     * create the title bar windows; let the event handler deal with painting
X     * so that we don't have to spend two pixmaps (or deal with hashing)
X     */
X    ComputeWindowTitleOffsets (tmp_win, tmp_win->attr.width, False);
X
X    leftx = y = Scr->TBInfo.leftx;
X    rightx = tmp_win->rightx;
X
X    attributes.win_gravity = NorthWestGravity;
X    attributes.background_pixel = tmp_win->title.back;
X    attributes.border_pixel = tmp_win->title.fore;
X    attributes.event_mask = (ButtonPressMask | ButtonReleaseMask |
X			     ExposureMask);
X    attributes.cursor = Scr->ButtonCursor;
X    valuemask = (CWWinGravity | CWBackPixel | CWBorderPixel | CWEventMask |
X		 CWCursor);
X
X    tmp_win->titlebuttons = NULL;
X    nb = Scr->TBInfo.nleft + Scr->TBInfo.nright;
X    if (nb > 0) {
X	tmp_win->titlebuttons = (TBWindow *) malloc (nb * sizeof(TBWindow));
X	if (!tmp_win->titlebuttons) {
X	    fprintf (stderr, "%s:  unable to allocate %d titlebuttons\n", 
X		     ProgramName, nb);
X	} else {
X	    TBWindow *tbw;
X	    int boxwidth = (Scr->TBInfo.width + Scr->TBInfo.pad);
X	    unsigned int h = (Scr->TBInfo.width - Scr->TBInfo.border * 2);
X
X	    for (tb = Scr->TBInfo.head, tbw = tmp_win->titlebuttons; tb;
X		 tb = tb->next, tbw++) {
X		int x;
X		if (tb->rightside) {
X		    x = rightx;
X		    rightx += boxwidth;
X		    attributes.win_gravity = NorthEastGravity;
X		} else {
X		    x = leftx;
X		    leftx += boxwidth;
X		    attributes.win_gravity = NorthWestGravity;
X		}
X		tbw->window = XCreateWindow (dpy, tmp_win->title_w, x, y, h, h,
X					     (unsigned int) Scr->TBInfo.border,
X					     0, (unsigned int) CopyFromParent,
X					     (Visual *) CopyFromParent,
X					     valuemask, &attributes);
X		tbw->info = tb;
X	    }
X	}
X    }
X
X    tmp_win->hilite_w = (tmp_win->titlehighlight 
X			 ? CreateHighlightWindow (tmp_win) : None);
X
X    XMapSubwindows(dpy, tmp_win->title_w);
X    if (tmp_win->hilite_w)
X      XUnmapWindow(dpy, tmp_win->hilite_w);
X    return;
X}
X
X
XSetHighlightPixmap (filename)
X    char *filename;
X{
X    Pixmap pm = GetBitmap (filename);
X
X    if (pm) {
X	if (Scr->hilitePm) {
X	    XFreePixmap (dpy, Scr->hilitePm);
X	}
X	Scr->hilitePm = pm;
X	Scr->hilite_pm_width = JunkWidth;
X	Scr->hilite_pm_height = JunkHeight;
X    }
X}
X
X
XFetchWmProtocols (tmp)
X    TwmWindow *tmp;
X{
X    unsigned long flags = 0L;
X    Atom *protocols = NULL;
X    int n;
X
X    if (XGetWMProtocols (dpy, tmp->w, &protocols, &n)) {
X	register int i;
X	register Atom *ap;
X
X	for (i = 0, ap = protocols; i < n; i++, ap++) {
X	    if (*ap == _XA_WM_TAKE_FOCUS) flags |= DoesWmTakeFocus;
X	    if (*ap == _XA_WM_SAVE_YOURSELF) flags |= DoesWmSaveYourself;
X	    if (*ap == _XA_WM_DELETE_WINDOW) flags |= DoesWmDeleteWindow;
X	}
X	if (protocols) XFree ((char *) protocols);
X    }
X    tmp->protocols = flags;
X}
X
XTwmColormap *
XCreateTwmColormap(c)
X    Colormap c;
X{
X    TwmColormap *cmap;
X    cmap = (TwmColormap *) malloc(sizeof(TwmColormap));
X    if (!cmap ||
X	XSaveContext(dpy, c, ColormapContext, (caddr_t) cmap)) {
X	if (cmap) free((char *) cmap);
X	return (NULL);
X    }
X    cmap->c = c;
X    cmap->state = 0;
X    cmap->install_req = 0;
X    cmap->w = None;
X    cmap->refcnt = 1;
X    return (cmap);
X}
X
XColormapWindow *
XCreateColormapWindow(w, creating_parent, property_window)
X    Window w;
X    Bool creating_parent;
X    Bool property_window;
X{
X    ColormapWindow *cwin;
X    TwmColormap *cmap;
X    XWindowAttributes attributes;
X
X    cwin = (ColormapWindow *) malloc(sizeof(ColormapWindow));
X    if (cwin) {
X	if (!XGetWindowAttributes(dpy, w, &attributes) ||
X	    XSaveContext(dpy, w, ColormapContext, (caddr_t) cwin)) {
X	    free((char *) cwin);
X	    return (NULL);
X	}
X
X	if (XFindContext(dpy, attributes.colormap,  ColormapContext,
X		(caddr_t *)&cwin->colormap) == XCNOENT) {
X	    cwin->colormap = cmap = CreateTwmColormap(attributes.colormap);
X	    if (!cmap) {
X		XDeleteContext(dpy, w, ColormapContext);
X		free((char *) cwin);
X		return (NULL);
X	    }
X	} else {
X	    cwin->colormap->refcnt++;
X	}
X
X	cwin->w = w;
X	/*
X	 * Assume that windows in colormap list are
X	 * obscured if we are creating the parent window.
X	 * Otherwise, we assume they are unobscured.
X	 */
X	cwin->visibility = creating_parent ?
X	    VisibilityFullyObscured : VisibilityUnobscured;
X	cwin->refcnt = 1;
X
X	/*
X	 * If this is a ColormapWindow property window and we
X	 * are not monitoring ColormapNotify or VisibilityNotify
X	 * events, we need to.
X	 */
X	if (property_window &&
X	    (attributes.your_event_mask &
X		(ColormapChangeMask|VisibilityChangeMask)) !=
X		    (ColormapChangeMask|VisibilityChangeMask)) {
X	    XSelectInput(dpy, w, attributes.your_event_mask |
X		(ColormapChangeMask|VisibilityChangeMask));
X	}
X    }
X
X    return (cwin);
X}
X		
XFetchWmColormapWindows (tmp)
X    TwmWindow *tmp;
X{
X    register int i, j;
X    Window *cmap_windows = NULL;
X    Bool can_free_cmap_windows = False;
X    int number_cmap_windows = 0;
X    ColormapWindow **cwins = NULL;
X    int previously_installed;
X    extern void free_cwins();
X
X    number_cmap_windows = 0;
X
X    if (previously_installed = (Scr->cmapInfo.cmaps == &tmp->cmaps &&
X				tmp->cmaps.number_cwins)) {
X	cwins = tmp->cmaps.cwins;
X	for (i = 0; i < tmp->cmaps.number_cwins; i++)
X	    cwins[i]->colormap->state = 0;
X    }
X
X    if (XGetWMColormapWindows (dpy, tmp->w, &cmap_windows, 
X			       &number_cmap_windows) &&
X	number_cmap_windows > 0) {
X
X	can_free_cmap_windows = False;
X	/*
X	 * check if the top level is in the list, add to front if not
X	 */
X	for (i = 0; i < number_cmap_windows; i++) {
X	    if (cmap_windows[i] == tmp->w) break;
X	}
X	if (i == number_cmap_windows) {	 /* not in list */
X	    Window *new_cmap_windows =
X	      (Window *) malloc (sizeof(Window) * (number_cmap_windows + 1));
X
X	    if (!new_cmap_windows) {
X		fprintf (stderr, 
X			 "%s:  unable to allocate %d element colormap window array\n",
X			ProgramName, number_cmap_windows+1);
X		goto done;
X	    }
X	    new_cmap_windows[0] = tmp->w;  /* add to front */
X	    for (i = 0; i < number_cmap_windows; i++) {	 /* append rest */
X		new_cmap_windows[i+1] = cmap_windows[i];
X	    }
X	    XFree ((char *) cmap_windows);
X	    can_free_cmap_windows = True;  /* do not use XFree any more */
X	    cmap_windows = new_cmap_windows;
X	    number_cmap_windows++;
X	}
X
X	cwins = (ColormapWindow **) malloc(sizeof(ColormapWindow *) *
X		number_cmap_windows);
X	if (cwins) {
X	    for (i = 0; i < number_cmap_windows; i++) {
X
X		/*
X		 * Copy any existing entries into new list.
X		 */
X		for (j = 0; j < tmp->cmaps.number_cwins; j++) {
X		    if (tmp->cmaps.cwins[j]->w == cmap_windows[i]) {
X			cwins[i] = tmp->cmaps.cwins[j];
X			cwins[i]->refcnt++;
X			break;
X		    }
X		}
X
X		/*
X		 * If the colormap window is not being pointed by
X		 * some other applications colormap window list,
X		 * create a new entry.
X		 */
X		if (j == tmp->cmaps.number_cwins) {
X		    if (XFindContext(dpy, cmap_windows[i], ColormapContext,
X				     (caddr_t *)&cwins[i]) == XCNOENT) {
X			if ((cwins[i] = CreateColormapWindow(cmap_windows[i],
X				    (Bool) tmp->cmaps.number_cwins == 0,
X				    True)) == NULL) {
X			    int k;
X			    for (k = i + 1; k < number_cmap_windows; k++)
X				cmap_windows[k-1] = cmap_windows[k];
X			    i--;
X			    number_cmap_windows--;
X			}
X		    } else
X			cwins[i]->refcnt++;
X		}
X	    }
X	}
X    }
X
X    /* No else here, in case we bailed out of clause above.
X     */
X    if (number_cmap_windows == 0) {
X
X	number_cmap_windows = 1;
X
X	cwins = (ColormapWindow **) malloc(sizeof(ColormapWindow *));
X	if (XFindContext(dpy, tmp->w, ColormapContext, (caddr_t *)&cwins[0]) ==
X		XCNOENT)
X	    cwins[0] = CreateColormapWindow(tmp->w,
X			    (Bool) tmp->cmaps.number_cwins == 0, False);
X	else
X	    cwins[0]->refcnt++;
X    }
X
X    if (tmp->cmaps.number_cwins)
X	free_cwins(tmp);
X
X    tmp->cmaps.cwins = cwins;
X    tmp->cmaps.number_cwins = number_cmap_windows;
X    if (number_cmap_windows > 1)
X	tmp->cmaps.scoreboard = 
X	  (char *) calloc(1, ColormapsScoreboardLength(&tmp->cmaps));
X		
X    if (previously_installed)
X	InstallWindowColormaps(PropertyNotify, (TwmWindow *) NULL);
X
X  done:
X    if (cmap_windows) {
X	if (can_free_cmap_windows)
X	  free ((char *) cmap_windows);
X	else
X	  XFree ((char *) cmap_windows);
X    }
X
X    return;
X}
X
X
XSimulateWinGravity (tmp)
X    TwmWindow *tmp;
X{
X    if (tmp->hints.flags & USPosition) {
X	static int gravs[] = { SouthEastGravity, SouthWestGravity,
X			       NorthEastGravity, NorthWestGravity };
X	int right =  tmp->attr.x + tmp->attr.width + 2 * tmp->old_bw;
X	int bottom = tmp->attr.y + tmp->attr.height + 2 * tmp->old_bw;
X	tmp->hints.win_gravity = 
X	  gravs[((Scr->MyDisplayHeight - bottom < tmp->title_height) ? 0 : 2) |
X		((Scr->MyDisplayWidth - right   < tmp->title_height) ? 0 : 1)];
X	tmp->hints.flags |= PWinGravity;
X    }
X}
X
Xstatic void
XgetTWM_FLAGS (w, flags)
X    Window w;
X    unsigned long *flags;
X{
X    Atom actual_type;
X    int actual_format;
X    unsigned long nitems, bytesafter;
X    unsigned long *datap = NULL;
X    Bool retval = False;
X
X    if (XGetWindowProperty (dpy, w, _XA_TWM_FLAGS, 0L, 1L, False, _XA_TWM_FLAGS,
X			    &actual_type, &actual_format, &nitems, &bytesafter,
X			    (unsigned char **) &datap) != Success || !datap)
X    {
X	*flags = 0;
X	return;
X    }
X    *flags = *datap;
X    XFree ((char *) datap);
X    return;
X}
X
Xvoid
XSetTWM_FLAGS(tmp_win)
XTwmWindow *tmp_win;
X{
X    unsigned long data;
X  
X    data = 0;
X
X    if (tmp_win->sticky)
X	data |= TWM_FLAGS_STICKY;
X
X
X    XChangeProperty (dpy, tmp_win->w, _XA_TWM_FLAGS, _XA_TWM_FLAGS, 32, 
X		 PropModeReplace, (unsigned char *) &data, 1);
X}
X
SHAR_EOF
if test 45413 -ne "`wc -c < add_window.c`"
then
    echo shar: error transmitting "add_window.c" '(should have been 45413 characters)'
fi
fi
if test -f 'add_window.h'
then
    echo shar: will not over-write existing file "add_window.h"
else
echo extracting "add_window.h"
sed 's/^X//' >add_window.h <<'SHAR_EOF'
X/*****************************************************************************/
X/**       Copyright 1988 by Evans & Sutherland Computer Corporation,        **/
X/**                          Salt Lake City, Utah                           **/
X/**  Portions Copyright 1989 by the Massachusetts Institute of Technology   **/
X/**                        Cambridge, Massachusetts                         **/
X/**                                                                         **/
X/**                           All Rights Reserved                           **/
X/**                                                                         **/
X/**    Permission to use, copy, modify, and distribute this software and    **/
X/**    its documentation  for  any  purpose  and  without  fee is hereby    **/
X/**    granted, provided that the above copyright notice appear  in  all    **/
X/**    copies and that both  that  copyright  notice  and  this  permis-    **/
X/**    sion  notice appear in supporting  documentation,  and  that  the    **/
X/**    names of Evans & Sutherland and M.I.T. not be used in advertising    **/
X/**    in publicity pertaining to distribution of the  software  without    **/
X/**    specific, written prior permission.                                  **/
X/**                                                                         **/
X/**    EVANS & SUTHERLAND AND M.I.T. DISCLAIM ALL WARRANTIES WITH REGARD    **/
X/**    TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES  OF  MERCHANT-    **/
X/**    ABILITY  AND  FITNESS,  IN  NO  EVENT SHALL EVANS & SUTHERLAND OR    **/
X/**    M.I.T. BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL  DAM-    **/
X/**    AGES OR  ANY DAMAGES WHATSOEVER  RESULTING FROM LOSS OF USE, DATA    **/
X/**    OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER    **/
X/**    TORTIOUS ACTION, ARISING OUT OF OR IN  CONNECTION  WITH  THE  USE    **/
X/**    OR PERFORMANCE OF THIS SOFTWARE.                                     **/
X/*****************************************************************************/
X
X
X/**********************************************************************
X *
X * $XConsortium: add_window.h,v 1.6 89/12/10 17:46:32 jim Exp $
X *
X * AddWindow include file
X *
X * 31-Mar-88 Tom LaStrange        Initial Version.
X *
X **********************************************************************/
X
X#ifndef _ADD_WINDOW_
X#define _ADD_WINDOW_
X
Xextern char NoName[];
X
Xextern TwmWindow *AddWindow();
Xextern int MappedNotOverride();
Xextern void GrabButtons();
Xextern void GrabKeys();
Xextern void UngrabButtons();
Xextern void UngrabKeys();
Xextern void SetTWM_FLAGS();
Xextern int AddingX;	
Xextern int AddingY;
Xextern int AddingW;
Xextern int AddingH;
X
X#endif /* _ADD_WINDOW_ */
X
SHAR_EOF
if test 2753 -ne "`wc -c < add_window.h`"
then
    echo shar: error transmitting "add_window.h" '(should have been 2753 characters)'
fi
fi
if test -f 'cursor.c'
then
    echo shar: will not over-write existing file "cursor.c"
else
echo extracting "cursor.c"
sed 's/^X//' >cursor.c <<'SHAR_EOF'
X/*
X * Copyright 1989 Massachusetts Institute of Technology
X *
X * Permission to use, copy, modify, and distribute this software and its
X * documentation for any purpose and without fee is hereby granted, provided
X * that the above copyright notice appear in all copies and that both that
X * copyright notice and this permission notice appear in supporting
X * documentation, and that the name of M.I.T. not be used in advertising
X * or publicity pertaining to distribution of the software without specific,
X * written prior permission.  M.I.T. makes no representations about the
X * suitability of this software for any purpose.  It is provided "as is"
X * without express or implied warranty.
X *
X * M.I.T. DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL
X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL M.I.T.
X * BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
X * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
X * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN 
X * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
X */
X
X/***********************************************************************
X *
X * $XConsortium: cursor.c,v 1.10 89/12/14 14:52:23 jim Exp $
X *
X * cursor creation code
X *
X * 05-Apr-89 Thomas E. LaStrange	File created
X *
X ***********************************************************************/
X
X#include <stdio.h>
X#include "twm.h"
X#include <X11/Xos.h>
X#include "screen.h"
X#include "util.h"
X
Xstatic struct _CursorName {
X    char		*name;
X    unsigned int	shape;
X    Cursor		cursor;
X} cursor_names[] = {
X
X{"X_cursor",		XC_X_cursor,		None},
X{"arrow",		XC_arrow,		None},
X{"based_arrow_down",	XC_based_arrow_down,    None},
X{"based_arrow_up",	XC_based_arrow_up,      None},
X{"boat",		XC_boat,		None},
X{"bogosity",		XC_bogosity,		None},
X{"bottom_left_corner",	XC_bottom_left_corner,  None},
X{"bottom_right_corner",	XC_bottom_right_corner, None},
X{"bottom_side",		XC_bottom_side,		None},
X{"bottom_tee",		XC_bottom_tee,		None},
X{"box_spiral",		XC_box_spiral,		None},
X{"center_ptr",		XC_center_ptr,		None},
X{"circle",		XC_circle,		None},
X{"clock",		XC_clock,		None},
X{"coffee_mug",		XC_coffee_mug,		None},
X{"cross",		XC_cross,		None},
X{"cross_reverse",	XC_cross_reverse,       None},
X{"crosshair",		XC_crosshair,		None},
X{"diamond_cross",	XC_diamond_cross,       None},
X{"dot",			XC_dot,			None},
X{"dotbox",		XC_dotbox,		None},
X{"double_arrow",	XC_double_arrow,	None},
X{"draft_large",		XC_draft_large,		None},
X{"draft_small",		XC_draft_small,		None},
X{"draped_box",		XC_draped_box,		None},
X{"exchange",		XC_exchange,		None},
X{"fleur",		XC_fleur,		None},
X{"gobbler",		XC_gobbler,		None},
X{"gumby",		XC_gumby,		None},
X{"hand1",		XC_hand1,		None},
X{"hand2",		XC_hand2,		None},
X{"heart",		XC_heart,		None},
X{"icon",		XC_icon,		None},
X{"iron_cross",		XC_iron_cross,		None},
X{"left_ptr",		XC_left_ptr,		None},
X{"left_side",		XC_left_side,		None},
X{"left_tee",		XC_left_tee,		None},
X{"leftbutton",		XC_leftbutton,		None},
X{"ll_angle",		XC_ll_angle,		None},
X{"lr_angle",		XC_lr_angle,		None},
X{"man",			XC_man,			None},
X{"middlebutton",	XC_middlebutton,	None},
X{"mouse",		XC_mouse,		None},
X{"pencil",		XC_pencil,		None},
X{"pirate",		XC_pirate,		None},
X{"plus",		XC_plus,		None},
X{"question_arrow",	XC_question_arrow,	None},
X{"right_ptr",		XC_right_ptr,		None},
X{"right_side",		XC_right_side,		None},
X{"right_tee",		XC_right_tee,		None},
X{"rightbutton",		XC_rightbutton,		None},
X{"rtl_logo",		XC_rtl_logo,		None},
X{"sailboat",		XC_sailboat,		None},
X{"sb_down_arrow",	XC_sb_down_arrow,       None},
X{"sb_h_double_arrow",	XC_sb_h_double_arrow,   None},
X{"sb_left_arrow",	XC_sb_left_arrow,       None},
X{"sb_right_arrow",	XC_sb_right_arrow,      None},
X{"sb_up_arrow",		XC_sb_up_arrow,		None},
X{"sb_v_double_arrow",	XC_sb_v_double_arrow,   None},
X{"shuttle",		XC_shuttle,		None},
X{"sizing",		XC_sizing,		None},
X{"spider",		XC_spider,		None},
X{"spraycan",		XC_spraycan,		None},
X{"star",		XC_star,		None},
X{"target",		XC_target,		None},
X{"tcross",		XC_tcross,		None},
X{"top_left_arrow",	XC_top_left_arrow,      None},
X{"top_left_corner",	XC_top_left_corner,	None},
X{"top_right_corner",	XC_top_right_corner,    None},
X{"top_side",		XC_top_side,		None},
X{"top_tee",		XC_top_tee,		None},
X{"trek",		XC_trek,		None},
X{"ul_angle",		XC_ul_angle,		None},
X{"umbrella",		XC_umbrella,		None},
X{"ur_angle",		XC_ur_angle,		None},
X{"watch",		XC_watch,		None},
X{"xterm",		XC_xterm,		None},
X};
X
Xvoid NewFontCursor (cp, str)
X    Cursor *cp;
X    char *str;
X{
X    int i;
X
X    for (i = 0; i < sizeof(cursor_names)/sizeof(struct _CursorName); i++)
X    {
X	if (strcmp(str, cursor_names[i].name) == 0)
X	{
X	    if (cursor_names[i].cursor == None)
X		cursor_names[i].cursor = XCreateFontCursor(dpy,
X			cursor_names[i].shape);
X	    *cp = cursor_names[i].cursor;
X	    return;
X	}
X    }
X    fprintf (stderr, "%s:  unable to find font cursor \"%s\"\n", 
X	     ProgramName, str);
X}
X
XNewBitmapCursor(cp, source, mask)
XCursor *cp;
Xchar *source, *mask;
X{
X    XColor fore, back;
X    int hotx, hoty;
X    int sx, sy, mx, my;
X    unsigned int sw, sh, mw, mh;
X    Pixmap spm, mpm;
X    Colormap cmap = Scr->TwmRoot.cmaps.cwins[0]->colormap->c;
X
X    fore.pixel = Scr->Black;
X    XQueryColor(dpy, cmap, &fore);
X    back.pixel = Scr->White;
X    XQueryColor(dpy, cmap, &back);
X
X    spm = GetBitmap(source);
X    if ((hotx = HotX) < 0) hotx = 0;
X    if ((hoty = HotY) < 0) hoty = 0;
X    mpm = GetBitmap(mask);
X
X    /* make sure they are the same size */
X
X    XGetGeometry(dpy, spm, &JunkRoot, &sx, &sy, &sw, &sh, &JunkBW,&JunkDepth);
X    XGetGeometry(dpy, mpm, &JunkRoot, &mx, &my, &mw, &mh, &JunkBW,&JunkDepth);
X    if (sw != mw || sh != mh)
X    {
X	fprintf (stderr, 
X		 "%s:  cursor bitmaps \"%s\" and \"%s\" not the same size\n",
X		 ProgramName, source, mask);
X	return;
X    }
X    *cp = XCreatePixmapCursor(dpy, spm, mpm, &fore, &back, hotx,hoty);
X}
SHAR_EOF
if test 5925 -ne "`wc -c < cursor.c`"
then
    echo shar: error transmitting "cursor.c" '(should have been 5925 characters)'
fi
fi
if test -f 'patchlevel.h'
then
    echo shar: will not over-write existing file "patchlevel.h"
else
echo extracting "patchlevel.h"
sed 's/^X//' >patchlevel.h <<'SHAR_EOF'
X#define PATCHLEVEL 0
SHAR_EOF
if test 21 -ne "`wc -c < patchlevel.h`"
then
    echo shar: error transmitting "patchlevel.h" '(should have been 21 characters)'
fi
fi
if test -f 'siconify.bm'
then
    echo shar: will not over-write existing file "siconify.bm"
else
echo extracting "siconify.bm"
sed 's/^X//' >siconify.bm <<'SHAR_EOF'
X#define siconify_width 11
X#define siconify_height 11
Xstatic char siconify_bits[] = {
X   0xff, 0x07, 0x01, 0x04, 0x0d, 0x05, 0x9d, 0x05, 0xb9, 0x04, 0x51, 0x04,
X   0xe9, 0x04, 0xcd, 0x05, 0x85, 0x05, 0x01, 0x04, 0xff, 0x07};
SHAR_EOF
if test 224 -ne "`wc -c < siconify.bm`"
then
    echo shar: error transmitting "siconify.bm" '(should have been 224 characters)'
fi
fi
# end of shell archive
exit 0

dan
----------------------------------------------------
O'Reilly && Associates   argv@sun.com / argv@ora.com
Opinions expressed reflect those of the author only.


From ucla-cs!elroy.jpl.nasa.gov!sdd.hp.com!samsung!rex!ukma!uflorida!travis!tom Thu Aug 30 17:57:48 PDT 1990
Article: 27008 of comp.windows.x
Path: ucla-cs!elroy.jpl.nasa.gov!sdd.hp.com!samsung!rex!ukma!uflorida!travis!tom
From: tom@ssd.csd.harris.com (Tom Horsley)
Newsgroups: comp.sources.bugs,comp.windows.x
Subject: unofficial patch to tvtwm window manager
Message-ID: <TOM.90Aug30131232@hcx2.ssd.csd.harris.com>
Date: 30 Aug 90 17:12:32 GMT
Sender: news@travis.csd.harris.com
Organization: Harris Computer Systems Division
Lines: 36
Xref: ucla-cs comp.sources.bugs:2652 comp.windows.x:27008
Status: O

The tvtwm window manager just appeared in comp.sources.x
(v09i002: TWM with a virtual root window)

I think I will learn to love tvtwm, but I had to make one change to get it
to work properly:

*** vdt.c.orig	Thu Aug 30 12:50:36 1990
--- vdt.c	Thu Aug 30 12:45:48 1990
***************
*** 576,582 ****
      XGrabButton(dpy, Button3, AnyModifier, Scr->Panner,
  	True, ButtonPressMask | ButtonReleaseMask | ButtonMotionMask,
  	GrabModeAsync, GrabModeAsync, Scr->Panner, None);
!     XSetWMProperties(dpy, Scr->Panner, wName, iName, NULL, 0,
  	sizeHints, wmHints, classHints);
  
      if (Scr->PannerState != WithdrawnState)
--- 576,582 ----
      XGrabButton(dpy, Button3, AnyModifier, Scr->Panner,
  	True, ButtonPressMask | ButtonReleaseMask | ButtonMotionMask,
  	GrabModeAsync, GrabModeAsync, Scr->Panner, None);
!     XSetWMProperties(dpy, Scr->Panner, &wName, &iName, NULL, 0,
  	sizeHints, wmHints, classHints);
  
      if (Scr->PannerState != WithdrawnState)

In our X11R4 source tree the args to XSetWMProperties are pointers, not
structs. I am fairly sure this is the same for everyone else as well...
--
======================================================================
domain: tahorsley@csd.harris.com       USMail: Tom Horsley
  uucp: ...!uunet!hcx1!tahorsley               511 Kingbird Circle
                                               Delray Beach, FL  33444
+==== Censorship is the only form of Obscenity ======================+
|     (Wait, I forgot government tobacco subsidies...)               |
+====================================================================+


From ucla-cs!usc!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse Sun Sep  2 11:15:46 PDT 1990
Article: 27110 of comp.windows.x
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU
Newsgroups: comp.windows.x
Subject: Re:  What is ICCCM ?
Message-ID: <9009020431.AA12867@Larry.McRCIM.McGill.EDU>
Date: 2 Sep 90 04:31:27 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 34
Status: O

> I am writing some X client applications that need to communicate with
> each other.  What is the best way ?

There is no single best way; it depends on many characteristics of the
data exchange.

> What is ICCCM and where can I learn about it ?

The ICCCM is the Inter-Client Communication Conventions Manual.  A copy
is included on the R4 release tape; a version that has been processed
to a plain-text file is available for ftp from 132.206.1.1
(X/ICCCM.doc).

What the best way to do this is depends on what you're trying to send
back and forth.  For example (the best case), if you send a few bytes
of data once in a while, with no particular urgency about delivery, you
can just stuff the data in a property of some window.  If (worst case)
you must send large quantities of data, fast and often, you probably
can't use the X mechanisms directly and will have to resort to
something like a shared memory segment or a direct connection.

For maximum portability, you must use window properties or selections.
This would allow interoperation even when the clients are using
incompatible transports (as a simple example, consider a server
speaking TCP to one client and DECnet to another).  You might instead
set up a TCP connection directly between your client processes; this
would gain speed at the expense of portability (not everyone speaks
TCP, and even if both ends do, they can't necessarily reach one another
directly, even though they can both reach the X server).

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu


From ucla-cs!usc!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse Tue Sep  4 09:25:24 PDT 1990
Article: 27137 of comp.windows.x
Path: ucla-cs!usc!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU
Newsgroups: comp.windows.x
Subject: Re:  help needed: quick exchange of window contents (animation)
Message-ID: <9009032240.AA19949@Larry.McRCIM.McGill.EDU>
Date: 3 Sep 90 22:40:36 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 43
Status: O

> I want to display complicated, slowly changing line drawings in an X
> window.  The problem is, that the screen starts flickering very much,
> if I

>   1) make a drawing    (1 long call to XDrawSegments)
>   2) flush the screen  (XFlush)
>   3) clear the window  (XClearWindow)
>   4) goto 1)

> Is there a possibility to build up the new drawing somewhere in the
> background while showing the old one and then switching to the new
> drawing with one (quick) command?

I know of three ways to do this.

(1) Use the Multi-Buffering extension.  This came out with R4; one
    hopes that most vendors have picked it up by now.  If available,
    this is probably the best bet.

(2) Use colormap and planemask tricks.  If you have a visual with a
    mutable colormap, and a sufficient depth (from your description, I
    would guess you need only one bit to display your picture, meaning
    a depth of two would suffice), you can set the colormap to display
    one picture and set the planemask to make that picture read-only,
    draw the next, and then display it fast by changing the colormap
    cells.  Then of course you change the planemask and draw the next
    picture, et cetera.

(3) Draw into a pixmap and copy it onto your window in one go.  You
    mention this but say

	> but I would like to avoid copying because of performance
	> reasons.

    Try it; you may find it doesn't hurt performance as much as you
    think it will.  This method is the most universally available, but
    costs server-side memory, which might be scarce (eg, an X
    terminal).

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu


From ucla-cs!usc!wuarchive!uunet!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse Tue Sep  4 09:41:38 PDT 1990
Article: 27142 of comp.windows.x
Path: ucla-cs!usc!wuarchive!uunet!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU
Newsgroups: comp.windows.x
Subject: Re:  Why do so many "great" people dislike X?
Message-ID: <9009040108.AA21988@Larry.McRCIM.McGill.EDU>
Date: 4 Sep 90 01:08:39 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 67
Status: O

> Bill Joy
> Dennis Ritchie
> Steven Jobs

> some of the people I respect the best in the whole wide world; all
> think X is brain-dead.  Do you have any ideas on why?

Yes and no.  I don't know why they think what they think, no.  But I
agree, X has problems.  It's just that I've not seen anything better.
To paraphrase who was it, Churchill I think, X is the worst window
system in the world, except for all the others.

> Did the wide acceptance of X have a lot to do with the urgent need to
> kill NeWS quickly on the part of DEC/HP/IBM (basically, did X rise to
> prominence for political rather than technical reasons)?

I don't know.  I like to think that in large part it was due to its
being freely available to all; that's certainly a big reason we're
using it here.

> Who're the people who did X anyway?  I never heard any names apart
> from the keyword 'MIT'.

>From the LABEL file on the R4 tape,

         X Window System, Version 11
                  Release 4

            contents copyrighted by

     Massachusetts Institute of Technology
	      Adobe Systems, Inc.
	     Apollo Computer Inc.
	     Apple Computer, Inc.
		  AT&T, Inc.
		  Don Bennett
	       Bigelow & Holmes
		Bitstream, Inc.
		 Adam de Boor
		Cognition Corp.
	 Digital Equipment Corporation
    Evans & Sutherland Computer Corporation
		   Franz Inc
	    Hewlett-Packard Company
		IBM Corporation
	Network Computing Devices, Inc.
	 O'Reilly and Associates, Inc.
		Dale Schumacher
		Marvin Solomon
		  Sony Corp.
		      SRI
	    Sun Microsystems, Inc.
		Tektronix, Inc.
	Texas Instruments Incorporated
		UniSoft Systems
  The Regents of the University of California
	    University of Wisconsin
		  Larry Wall
	     Wyse Technology, Inc.

The LABEL.CONTRIB file is much longer and I won't bother including the
whole thing here, but it's as widely varied....

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu


From ucla-cs!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!julius.cs.uiuc.edu!apple!snorkelwacker!bloom-beacon!ZIA.AOC.NRAO.EDU!cflatter Tue Sep  4 18:56:18 PDT 1990
Article: 27170 of comp.windows.x
Path: ucla-cs!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!julius.cs.uiuc.edu!apple!snorkelwacker!bloom-beacon!ZIA.AOC.NRAO.EDU!cflatter
From: cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters)
Newsgroups: comp.windows.x
Subject: OSF statements about OPEN LOOK
Message-ID: <9009041647.AA24685@zia.aoc.nrao.edu>
Date: 4 Sep 90 16:47:26 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 112
Status: O

> I haven't been reading the UNIX trade rags much lately. Can you give refs
> for this 'mudslinging campaign' and particularly their claim that OL is a
> 'closed, proprietary standard'? That is complete rubbish and deserves the
> widest possible refutation.

The mudslinging I refered to is an OSF paper entitled "OSF/Motif: Unparalleled
Portability.  This is dated July 1990 and has a part number (?) of
OSF-1-WP4-0790-1.  This is a comparison of OSF/Motif with OPEN LOOK and,
of course attempts to show Motif in the best posssible light while making
the unenlightened reader wonder why Sun and AT&T ever bothered with OPEN
LOOK.  It is also rather economical with the truth.  Although they don't
go so far as to claim outright that OPEN LOOK is closed and proprietary
this is the clear slant of the document.

Here are some choice extracts:

"...the XView toolkit is more difficult to extend than a toolkit based on
the Xt Intrinsics level of the X Window System.  Developers creating
application-specific widgets must write to the Xlib level (roughly
comparable to coding in assembly level)."	(p10)

OK, the first part is true.  But the second part is kind of wierd.  XView
uses a different paradigm to Xt based toolkits: you don't program in XView
by creating application specific widgets.  It seems rather peculiar to
criticise XView for making it difficult to do something that you wouldn't
normally want (or need) to do.  Besides, writing Xlib calls can hardly
be compared to writing assembly level -- Xlib drawing is more like GKS
without normalization pipelines.

"The OPEN LOOK GUI (XView implementation) is currently running on SPARC,
80386 and 680x0 architecture computers..." (p11)

In July 1990 it was also running on DECstations.  If the Convex C compiler
hadn't blown up while compiling the text sub-window code (insufficient
symbol space) it would have been running on at least one Convex C-1.  Porting
XView to BSD systems should not be a major exercise and I would guess that
there are several unannounced ports of version 1 around.  Version 2 ports
will become common when Sun replaces the missing files in the XView 2
distribution (are you listening Sun?).

"None of the OPEN LOOK toolkits currently complies with the ICCCM
specifications for interclient communications." (p11)

This one sentence is responsible for my antipathy towards this document.
Sun claims that XView conforms to the ICCCM conventions and I have found
no evidence of any ICCCM violations.  I believe that AT&T are also of the
opinion that OLIT is also ICCCM compliant.  The above is a very serious
accusation and requires some explanation from the OSF.  If they actually
have evidence of departures from the ICCCM these departures are contrary
to the intent of the OPEN LOOK developers and should be reported so that
they can be fixed.

"Dependence on proprietary protocols requires the presence of the 
OPEN LOOK window manager for proper operation of OPEN LOOK applications.
This dependence can hinder the ability of OPEN LOOK clients to work with
other clients to work with other clients on heterogenous networks." (p11)

OPEN LOOK uses its own protocols to support interclient communications
that are not covered by the ICCCM (yet), such as drag-and-load and pinnable
menus.  Since Motif does not support these (unless these features have
been extremely well hidden by the people at OSF) we can hardly expect the
OSF to point this out.  We could play semantic games for ever about whether
the OPEN LOOK protocols are proprietary or not.  They do, however, conform to
the ICCCM rules regarding vendor extensions.

The real point is that I have used OPEN LOOK clients in conjuction with
non-OPEN LOOK window managers (the X11R4 version of twm and DECs dxwm) and
while the clients may not work "properly" in the sense of having push pins
in menus and allowing file icons to be dropped on them they do work
acceptably in such circumstances.

"OPEN LOOK implementations are currently limited to eight-byte [shurely
shome mishtake] character sets and are English-based." (p11)

Whew --- this only just made it before Kanji OPEN LOOK was announced.

"... the OPEN LOOK toolkits, NDE, XView and Xt+, are proprietary to
individual, for-profit organizations." (p12)

But Sun give the XView source away for nothing.

"OSF/Motif has already achieved widespread industry acceptance outside
the sphere of its original propenents." (p15)

I accept that more vendors supply Motif binaries than OPEN LOOK binaries
but the last count I saw seemed to show that OPEN LOOK had the lead as
far as ISV applications vendors were concerned.  In all probability
neither interface has been around long enough for a clear trend to be
established.

------------------------

Closing note:

   I don't like to see negative marketing of this kind.  I believe that
is an insult to the consumer and is does no credit to the people who
indulge in it.  Both OPEN LOOK and Motif have their good points.  Neither
one is about to go away.

  An important point is that workstations purchases are rarely (if ever)
determined by GUI considerations.  This means that many people are likely
to end up with networks running a mixture of OPEN LOOK and Motif.  I would
much rather see the OSF and the AT&T/Sun axis getting together to improve
the interoperability of OPEN LOOK and Motif rather than trying to score
cheap shots of one another.

  End of sermon.

			Chris Flatters


----- End Included Message -----


From ucla-cs!usc!pollux.usc.edu!lam Wed Sep  5 07:46:20 PDT 1990
Article: 27187 of comp.windows.x
Path: ucla-cs!usc!pollux.usc.edu!lam
From: lam@pollux.usc.edu (Curtz Lam)
Newsgroups: comp.windows.x
Subject: xterm not setuid?
Message-ID: <26947@usc.edu>
Date: 5 Sep 90 04:18:08 GMT
Sender: news@usc.edu
Organization: University of Southern California, Los Angeles, CA
Lines: 22
Nntp-Posting-Host: pollux.usc.edu
Originator: lam@pollux.usc.edu
Status: O


	
	I remember seeing articles on how to make xterm not setuid,
would any kind souls please forward those articles to me?  My problem
is described below, any help is appreciated.

	I installed X11R4 library under SunOS 4.1 in a directroy other
than /usr/lib.  Everything seems fine except xterm cannot find the
required shared libraries.  I understand the problem is because xterm
is setuid and ld only looks at /usr/lib for setuid programs.  I guess
my problem is whether there is a way to make xterm not setuid? or
force ld to look in other directories? (with potential security
problems).  The way I am running it now is to make symbolic links in
/usr/lib to point to the correct libraries, I am wondering if there is
an easier way to do this.  

							Curtz
-- 
------
INTERNET: lam@usc.edu
BITNET: curtz@gamera
UUCP: ...!uunet!usc!lam


From ucla-cs!elroy.jpl.nasa.gov!sdd.hp.com!decwrl!apple!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse Wed Sep  5 07:47:12 PDT 1990
Article: 27194 of comp.windows.x
Path: ucla-cs!elroy.jpl.nasa.gov!sdd.hp.com!decwrl!apple!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU
Newsgroups: comp.windows.x
Subject: Re:  xterm not setuid?
Message-ID: <9009050653.AA03612@Larry.McRCIM.McGill.EDU>
Date: 5 Sep 90 06:53:19 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 18
Status: O

> I installed X11R4 library under SunOS 4.1 in a directroy other than
> /usr/lib.  Everything seems fine except xterm cannot find the
> required shared libraries.

Funny, we had no problem under 4.1.  We didn't even have to run
ldconfig.  (Not unless "make World" did that for us and I didn't
notice.)  Well, in any case....

My advice would be to link the setuid/setgid programs (xterm, xload, I
think there's one other) with -Bstatic, to make them independent of the
dynamic libraries.  You can turn off xterm's setuid bit, but then it
will be unable to write entries in utmp (unless you make utmp
world-writable, which opens up other security holes).

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu


From ucla-cs!usc!samsung!mitech!gjc Thu Sep  6 07:55:21 PDT 1990
Article: 27253 of comp.windows.x
Path: ucla-cs!usc!samsung!mitech!gjc
From: gjc@mitech.com
Newsgroups: comp.windows.x
Subject: Re: 3d plotting followup
Message-ID: <4876@mitech.com>
Date: 5 Sep 90 17:04:39 GMT
References: <9009041747.AA05001@mvax.EE.CORNELL.EDU>
Organization: Mitech Corporation, Concord MA
Lines: 22
Status: O

There is a package called PLPLOT, available from AMIGA source and binary
archives (comp.sources.amiga, comp.binaries.amiga). It was based on
on Tim Pearsons VAX/Fortran-77 package PGPLOT (from Caltech?) which sees
quite a bit of use for scientific plotting. It was very easy to get
this running on non-AMIGA machines.

I wrote XLIB and POSTSCRIPT level drivers for this,
and use it as a sharable library to call from programs.
Technically, in terms of plotting technique and
capability it is superior to gnuplot, and xgraph-11. It has
2d, 3d, and contour plotting capability.
For an interactive interface I've used the SIOD scheme interpreter.

If somebody would help me with the XMAKEFILE and other considerations
it would could make a worthy X contributed package.

Since it is program callable and encapsulates its state in a few
data structures it isn't too far away from being widget-worthy either.
(I have a list of all internal state variables because of the sharable
library considerations).

-gjc


From ucla-cs!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse Thu Sep  6 08:00:19 PDT 1990
Article: 27255 of comp.windows.x
Path: ucla-cs!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU
Newsgroups: comp.windows.x
Subject: Re:  FATAL SERVER BUG WITH X11R4, SUN 3/80,SunOS 4.? HELP !!
Message-ID: <9009060259.AA29237@Larry.McRCIM.McGill.EDU>
Date: 6 Sep 90 02:59:37 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 31
Status: O

> Help:  I've been trying to make X11 release 4 on a Sun 3/80 with
> Gnu's Gcc (version 1.37.1) compiler.  When I try to run xinit or Xsun
> I get the following error :

> Getting interface configuration: Operation not supported on socket

> Fatal server bug!
> no screens found

> I've run all the patches,fixed errors in ERRATA and run Gcc's
> fixincludes.

Your fixincludes run probably didn't work for some reason.  Do a simple
test:

#include <sys/ioctl.h>
SIOCGIFCONF

Run that through cc -E and gcc -E.  The last line of output is the
piece of interest; it should be identical (modulo irrelevant
differences like whitespace).  If the gcc version has 'x' where the cc
version has 'i', your fixincludes run didn't work for some reason or
other.  If they are identical, try running a make clean in mit/server
and rebuilding, just to make sure everything gets compiled with the
proper include files. If that still doesn't help I have no further
suggestions, short of poking around with a debugger....

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu


From ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!pasteur!postgres.Berkeley.EDU!picasso Fri Sep  7 07:47:03 PDT 1990
Article: 27301 of comp.windows.x
Path: ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!pasteur!postgres.Berkeley.EDU!picasso
From: picasso@postgres.Berkeley.EDU (Picasso Group)
Newsgroups: comp.windows.x
Subject: Picasso GUI Development System Release Announcement
Message-ID: <27558@pasteur.Berkeley.EDU>
Date: 6 Sep 90 23:49:42 GMT
Sender: news@pasteur.Berkeley.EDU
Lines: 55
Status: O


       Picasso Graphical User Interface Development System
                            Lawrence A. Rowe
                  Computer Science Division - EECS Dept
                        University of California
                           Berkeley, CA 94720
        (phone: 415-642-5117; email: larry@postgres.Berkeley.EDU)

Picasso is a graphical user interface (GUI) development system
that includes an object-oriented interface toolkit and application
framework.  The toolkit contains a library of predefined interface
abstractions (e.g., buttons, scrollbars, menus, forms, text fields,
lists and tables, graphics fields, video field, etc.), geometry managers,
and a constraint system.  The constraint system is used to implement
triggered behaviors and to bind variables to interface abstractions.

The application framework provides high-level objects to define GUI's
including modal dialog boxes and non-modal frames and panels.  These
objects are similar to procedures and co-routines in a conventional
programming language in that they have local variables and they can
be called with parameters.  Different types of parameter passing are
used to specify when updates are propagated to different views of the
information displayed.

Picasso is implemented in Common Lisp using the Common Lisp Object
System and the CLX interface to the X Window System.
Currently, it runs on Unix systems including Sun-3's and Sparcstations,
DECStation 3100's, and Sequent Balance in Franz Allegro Common Lisp.

We have developed several applications in the system including:

1) a facility manager tool that displays a 2D schematic view of
   an IC fabrication laboratory and that allows users to access
   other facility and manufacturing information stored in a
   relational dbms (e.g., equipment, utility, and lot information),

2) an interactive executer/debugger for a robot programming language
   that can be used to teach novices how to program in Lisp, and

3) a hypermedia system that includes video, text, and graphic data.

We are currently working on a direct manipulation application development
interface and enhancements to and applications of the hypermedia system.

A paper describing the application framework and a reference manual
are available.  Papers describing our use of CLOS to implement
Picasso, the facility management tool, and the hypermedia system
are currently being written.  If you are interested in receiving
these papers send email to picasso@postgres.Berkeley.EDU.

Picasso is currently being used at three sites outside Berkeley.
If you want to get a copy of the system you can either FTP it
from Berkeley (postgres@Berkeley.EDU (128.32.149.1)) or send us a
check for $150 (US) drawn on a US bank and we'll be glad to send
you a tar tape. Please indicate whether you want a Sun, DEC, or 8mm tape.


From ucla-cs!elroy.jpl.nasa.gov!ncar!boulder!stan!ninja!toml Fri Sep  7 07:50:38 PDT 1990
Article: 27304 of comp.windows.x
Path: ucla-cs!elroy.jpl.nasa.gov!ncar!boulder!stan!ninja!toml
From: toml@ninja.Solbourne.COM (Tom LaStrange)
Newsgroups: comp.windows.x
Subject: small tvtwm patch
Message-ID: <1990Sep6.190125.12372@Solbourne.COM>
Date: 6 Sep 90 19:01:25 GMT
Sender: news@Solbourne.COM
Reply-To: toml@solbourne.com
Organization: Solbourne Computer, Inc.
Lines: 36
Status: O

This unofficial patch fixes a problem that shows up when icon managers
become empty, unmap themselves and then sometime later get remapped
because a client of the appropriate class is created.  Once again, I'll
send out an official patch when I get more stuff to fix/add.

You should be able to apply this patch no matter what patchlevel you're
currently at.

--
Tom LaStrange

Solbourne Computer Inc.    ARPA: toml@Solbourne.COM
1900 Pike Rd.              UUCP: ...!{boulder,sun}!stan!toml
Longmont, CO  80501


*** old/vdt.c	Thu Sep  6 12:54:23 1990
--- vdt.c	Thu Sep  6 12:54:29 1990
***************
*** 259,265 ****
  TwmWindow *tmp_win;
  {
      XUnmapWindow(dpy, tmp_win->frame);
!     XUnmapWindow(dpy, tmp_win->w);
      if (tmp_win->virtualWindow && !tmp_win->sticky)
  	XUnmapWindow(dpy, tmp_win->virtualWindow);
  }
--- 259,266 ----
  TwmWindow *tmp_win;
  {
      XUnmapWindow(dpy, tmp_win->frame);
!     if (!tmp_win->iconmgr)
! 	XUnmapWindow(dpy, tmp_win->w);
      if (tmp_win->virtualWindow && !tmp_win->sticky)
  	XUnmapWindow(dpy, tmp_win->virtualWindow);
  }


From ucla-cs!elroy.jpl.nasa.gov!jarthur!bridge2!mips!decwrl!sgi!zok!mark Mon Oct  1 10:03:59 PDT 1990
Article: 28254 of comp.windows.x
Path: ucla-cs!elroy.jpl.nasa.gov!jarthur!bridge2!mips!decwrl!sgi!zok!mark
From: mark@zok.UUCP (Mark W. Snitily)
Newsgroups: comp.windows.x
Subject: xterm patch for gcc with fix-1[567]
Message-ID: <492@zok.UUCP>
Date: 1 Oct 90 09:59:18 GMT
Organization: The distant planet Zok
Lines: 37
Status: O

The recent MIT X1R4 fix-15, fix-16, fix-17 changed the typedef of XtPointer
(see Intrinsic.h) for compilers that define __STDC__.  It's now a pointer to
void instead of a pointer to a character.  This causes gcc (1.37.1 on a Sun3)
to hiccup when compiling .../src/mit/clients/xterm/charproc.c.

Not sure if type casting to a (char *) is the "correct" solution, but it's
enough to get gcc to compile xterm.  Here's the patch:

*** charproc.c.org	Fri Mar 23 14:57:11 1990
--- charproc.c	Sun Sep 30 18:07:31 1990
***************
*** 2618,2624 ****
      if (*type != XA_STRING || *format != 8) { Bell(); return; }
      len = strlen(value);
      if (len > 0) {
! 	if (value[len-1] == '\n') value[len-1] = '\0';
  	if (!LoadNewFont (&term->screen, value, NULL, True, 
  			  fontMenu_fontescape))
  	  Bell();
--- 2618,2624 ----
      if (*type != XA_STRING || *format != 8) { Bell(); return; }
      len = strlen(value);
      if (len > 0) {
! 	if (((char *)value)[len-1] == '\n') ((char *)value)[len-1] = '\0';
  	if (!LoadNewFont (&term->screen, value, NULL, True, 
  			  fontMenu_fontescape))
  	  Bell();

-- Mark

Mark W. Snitily                 Consulting Services:
894 Brookgrove Lane             Graphics, Operating Systems, Compilers
Cupertino, CA 95014             (408) 252-0456
mark@zok.uucp                   West Coast UUCP X11 archive site

If your mailer doesn't like the .uucp domain, these also work:
...!{mips,sgi}!zok!mark, mark%zok@mips.com, mark%zok@sgi.com


From ucla-cs!usc!wuarchive!zaphod.mps.ohio-state.edu!rpi!crdgw1!ge-dab!tarpit!ucf-cs!tslvax!mike Wed Oct  3 09:26:27 PDT 1990
Article: 28372 of comp.windows.x
Path: ucla-cs!usc!wuarchive!zaphod.mps.ohio-state.edu!rpi!crdgw1!ge-dab!tarpit!ucf-cs!tslvax!mike
From: mike@tslvax.UUCP (Michael J. Tobias)
Newsgroups: comp.windows.x
Subject: Re: X Window System vs Medical (Radiology) Imaging Applications
Message-ID: <359@tslvax.UUCP>
Date: 2 Oct 90 17:49:26 GMT
References: <27308@usc.edu>
Organization: Tech Source Laboratories, Altamonte Springs
Lines: 42
Status: O

in article <27308@usc.edu>, dra@neuro.usc.edu (Diane Annala) says:
> Xref: tslvax comp.windows.x:19614 comp.os.vms:19352
> Nntp-Posting-Host: neuro.usc.edu
> 
> First, could someone send me email with information about high resolution
> (e.g. 2Kx2K plus) frame buffers/monitors compatible with X Window System?
> 
> Second, are there any plans to provide a new visual class with a depth of
> 12 or more bits under the standard distribution of the X Widow System?  I
> am concerned that we may otherwise exclude medical imaging applications--
> which often require 12 bit greyscale images to capture subtle shadows--if
> we don't extend the potential depth of the greyscale visual.
> 
> Diane

Diane,

I tried to email you this information, but it got bounced back.

Tech-Source makes a board called the GDS-3950 which drives several high
resolution color and monochrome displays, such as:

	Sony 2048 x 2048 color display
	Tektronix GMA 201 2048 x 1600 monochrome display

The GDS-3950 is a single size 9U card, with complete software to run
and accelerated version of X11R4 in many of the Sun machines which support
the VMEbus (Sun-3/1xx, Sun-3/2xx, Sun-4/110, Sun-4/2xx, Sun-4/3xx, etc.).

The board supports up to 20 image planes fully configured 8-bits double
buffered plus 4-bits overlay.

For more information contact:

Tech-Source, Inc.
442 S. North Lake Blvd
Altamonte Springs, FL  32701
(407) 830-8301
Attn:  Dick Bendfelt

Mike Tobias
Tech-Source		uunet!ucf-cs!tslvax!mike


From ucla-cs!ucivax!orion.oac.uci.edu!ucsd!swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!agate!darkstar!ucscc.UCSC.EDU!haynes Sun Oct  7 14:22:21 PDT 1990
Article: 28528 of comp.windows.x
Path: ucla-cs!ucivax!orion.oac.uci.edu!ucsd!swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!agate!darkstar!ucscc.UCSC.EDU!haynes
From: haynes@ucscc.UCSC.EDU (99700000)
Newsgroups: comp.windows.x
Subject: Awesome! (was Novice building X on Sun 3/50, SunOS 4.0.3)
Message-ID: <7533@darkstar.ucsc.edu>
Date: 5 Oct 90 18:46:44 GMT
References: <9010042245.AA28915@Larry.McRCIM.McGill.EDU>
Sender: usenet@darkstar.ucsc.edu
Reply-To: haynes@ucscc.UCSC.EDU.UUCP (Jim Haynes)
Organization: University of California, Santa Cruz  CATS
Lines: 23
Status: O

In article <9010042245.AA28915@Larry.McRCIM.McGill.EDU> mouse@LARRY.MCRCIM.MCGILL.EDU writes:
>> I just applied all the patches and did a make World in my sun3
>> directory and got everything made.  Nothing (that I have tried so
>> far) works; they all report "inappropriate ioctl for device" .
>
>You used gcc, right?  This looks suspiciously like the broken include
>files problem.  Try a simple test.  Put these two lines in a file
>somewhere, foo.c say:
>
Absolutely correct!  It's been a long time since I built gcc, and I
had completely forgotten about the 'fixincludes' script, which had never
been run on the workstation on which I did the compiling.  So now
all is much better - well, my xlogin doesn't work with the new
server, but if I can find the source for that I'll rebuild it and
see if that doesn't fix it.


haynes@ucscc.ucsc.edu
haynes@ucscc.bitnet
..ucbvax!ucscc!haynes

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle


From ucla-cs!usc!jarthur!elroy.jpl.nasa.gov!sdd.hp.com!samsung!cs.utexas.edu!tut.cis.ohio-state.edu!morganucodon.cis.ohio-state.edu!jgreely Sun Oct  7 14:27:32 PDT 1990
Article: 28575 of comp.windows.x
Path: ucla-cs!usc!jarthur!elroy.jpl.nasa.gov!sdd.hp.com!samsung!cs.utexas.edu!tut.cis.ohio-state.edu!morganucodon.cis.ohio-state.edu!jgreely
From: jgreely@morganucodon.cis.ohio-state.edu (J Greely)
Newsgroups: comp.windows.x
Subject: Re: Postscript previewer under X
Message-ID: <JGREELY.90Oct5054556@morganucodon.cis.ohio-state.edu>
Date: 5 Oct 90 09:45:56 GMT
References: <655046250@<chic> <22700017@ux1.cso.uiuc.edu>
Sender: news@tut.cis.ohio-state.edu
Reply-To: J Greely <jgreely@cis.ohio-state.edu>
Organization: Ohio State University Computer and Information Science
Lines: 41
In-reply-to: phil@ux1.cso.uiuc.edu's message of 4 Oct 90 21:14:00 GMT
Status: O

In article <22700017@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu writes:
>1.  Ability to override the pixel size relationship, so that I can see what
>    actual dots would be plotted on my 300dpi printer instead of what has to
>    be plotted on my 75dpi (or whatever) X terminal.  Since this would result
>    in magnification of the image, the window should be a port to a virtual
>    window with H and V scrollbars.

Pageview (supplied with OpenWindows 2.0) does this nicely, although it
won't show you the results of 300dpi halftoning.  It would be a fairly
trivial modification if you had the source, although it shouldn't be
the default.

>2.  Both forward AND BACKWARD page buttons, to go between different pages.
>    Bitmaps of previous pages should be kept to some specifiable maximum.

This is only reasonable if the PostScript document conforms to the
Adobe Document Structuring Conventions (and it's still not easy unless
they interpret it in a nice way :-)).  Making the bitmap-caching
scheme work on arbitrary PS would require a healthy, loving
relationship between the interpreter and the user interface (offhand,
the only interpreters I know of that are mature enough for this are
Display PostScript and NeWS).

>3.  An option to tell the previewer to watch for the .ps file to be updated,
>    and rerun it when it is, automatically.

Ick.  How will it know when the updating process is finished?  For
something like a DVI converter, it could take several minutes to
completely update the file, and if I'm currently looking at page
thirty when the previewer notices that the file has been overwritten
by the first 4K of the new version, I'll be very unhappy.

  Your other idea (having the previewer run one or more programs that
produce a PostScript file to use as input) is more practical.

>    A rerun button should be there in either case. ... It would be
>    nice to be able to have an edit window

Pageview does both of these, although the editor is a bit primitive.
--
J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)


From ucla-cs!elroy.jpl.nasa.gov!sdd.hp.com!samsung!cs.utexas.edu!yale!mintaka!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse Sun Oct  7 14:29:48 PDT 1990
Article: 28591 of comp.windows.x
Path: ucla-cs!elroy.jpl.nasa.gov!sdd.hp.com!samsung!cs.utexas.edu!yale!mintaka!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU
Newsgroups: comp.windows.x
Subject: Re:  Reverting snf fonts to bdf fonts (context is xtex).
Message-ID: <9010060345.AA04402@Larry.McRCIM.McGill.EDU>
Date: 6 Oct 90 03:45:50 GMT
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 20
Status: O

> I have many TeX fonts in the SNF form for use with xtex, running
> under X11R4.  In moving to OpenWindows the SNF fonts are no longer
> appropriate.  I need to create the appropriate FB fonts for use with
> xtex under OpenWindows.  This I can do using convertfont to convert a
> BDF font to an FB font.  But I no longer have the original BDF fonts.
> Short of recreating or re-ftp'ing the BDF fonts is there any way to
> reverse the bdftosnf process (i.e., is there a snftobdf)?

I have something close.  It connects to your server and produces a BDF
file for the desired font - which can be any font that server has, and
what sort of format the server keeps its fonts in internally is
entirely irrelevant.

I call it getbdf.  It can be had by ftp from 132.206.1.1, in
X/getbdf.c, or by mail to me if you can't ftp it for some reason.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu


From ucla-cs!elroy.jpl.nasa.gov!sdd.hp.com!samsung!olivea!mintaka!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse Sun Oct  7 14:32:10 PDT 1990
Article: 28593 of comp.windows.x
Path: ucla-cs!elroy.jpl.nasa.gov!sdd.hp.com!samsung!olivea!mintaka!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU
Newsgroups: comp.windows.x
Subject: Re:  How to Get 90 degree Rotated Fonts?
Message-ID: <9010060340.AA04299@Larry.McRCIM.McGill.EDU>
Date: 6 Oct 90 03:40:36 GMT
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 31
Status: O

> How would one get a font rotated +/-90 degrees in X so that I can
> draw text running vertically?

In general, one doesn't.

> The solution should be a run-time one.  The user specifies a given
> font for an application and I wish to use that font for horz and vert
> text.  I can't and don't want to define a new font.

Then your only choice, as far as I can see, is to draw the text
horizontally into a bitmap (or pixmap), suck it over into the client
with XGetImage, rotate it "by hand", send it back, and blit it onto the
screen as graphics.  If the rotated text is highly variable, you may
want to do this for each character, though then displaying the text
will be slower - many blits instead of one.  (I used this technique in
my terminal emulator when I want double height and/or width text: grab
the character's bitmap, magnify it myself, send it back, and blit it
onto the screen.  Of course, if you do this much you should cache the
rotated bitmaps....)

There are various extensions around that can save you the trouble - for
example, any of the various PostScript support extensions present in
various (proprietary) servers would have no trouble.  But using one of
those loses compatibility with all the servers out there. that don't
support that particular extension.  (Sure as you do, you'll find you
want to make it run on an X terminal or something.)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu


From ucla-cs!elroy.jpl.nasa.gov!ames!ncar!ico!auto-trol!marbru Sun Oct  7 14:33:54 PDT 1990
Article: 28632 of comp.windows.x
Path: ucla-cs!elroy.jpl.nasa.gov!ames!ncar!ico!auto-trol!marbru
From: marbru@auto-trol.UUCP (Martin Brunecky)
Newsgroups: comp.windows.x
Subject: Re: How to Get 90 degree Rotated Fonts?
Message-ID: <863@auto-trol.UUCP>
Date: 7 Oct 90 16:07:13 GMT
References: <KHAI.90Oct4144819@snapper.adi.com>
Reply-To: marbru@auto-trol.UUCP (Martin Brunecky)
Distribution: comp.windows.x
Organization: Auto-trol Technology, Denver
Lines: 23
Status: O

In article <KHAI.90Oct4144819@snapper.adi.com> khai@adi.com (S. Khai Mong) writes:
>How would one get a font rotated +/-90 degrees in X so that I can draw
>text running vertically?
>
>The solution should be a run-time one.  The user specifies a given
>font for an application and I wish to use that font for horz and vert
>text.  I can't and don't want to define a new font.
>--
>Sao Khai Mong:   Applied Dynamics, 3800 Stone School Road, Ann Arbor, Mi48108
>(313)973-1300    (uunet|sharkey)!amara!khai   khai@adi.com

    What about drawing all characters in your font into an off-screen bitmap,
    reading it with XGetImage, swapping rows/columns in each character,
    loading it back into (another) off-screen bitmap, and from there on
    use XCopyPlane for each character ?
   [ yeep, XPutFontBitmap would be much better, but there just ain't one,
     and the MIT guys don't like it, they want something really big and
     ugly - called "font server" ].
-- 
=*= Opinions presented here are solely of my own and not those of Auto-trol =*=
Martin Brunecky                   marbru@auto-trol.COM
(303) 252-2499                    {...}ncar!ico!auto-trol!marbru
Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404 


From ucla-cs!usc!samsung!uunet!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws Mon Oct  8 08:12:06 PDT 1990
Article: 28643 of comp.windows.x
Path: ucla-cs!usc!samsung!uunet!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: How to Get 90 degree Rotated Fonts?
Message-ID: <9010080007.AA25121@expo.lcs.mit.edu>
Date: 8 Oct 90 00:07:38 GMT
References: <863@auto-trol.UUCP>
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 12
Status: O


   [ yeep, XPutFontBitmap would be much better, but there just ain't one,
     and the MIT guys don't like it, they want something really big and
     ugly - called "font server" ].

I used to think a font server might be sufficient for this, but no longer.
I think some form of font downloading is desirable, although I'm not sure
what the best form is.  The font server solves a different, but also
important problem, and it need be neither "big" nor "ugly".  Right now
resources within the Consortium are focused on the font server, because
the people involved feel it is a more important problem to solve.  I hope
that we will eventually find the resources to work on font downloading.


From ucla-cs!usc!wuarchive!uunet!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!HITCHCOCK.ENG.UIOWA.EDU!yiannis Mon Oct  8 08:12:35 PDT 1990
Article: 28646 of comp.windows.x
Path: ucla-cs!usc!wuarchive!uunet!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!HITCHCOCK.ENG.UIOWA.EDU!yiannis
From: yiannis@HITCHCOCK.ENG.UIOWA.EDU (Yiannis Papelis)
Newsgroups: comp.windows.x
Subject: Re: How to display a postscript file in X windows?
Message-ID: <9010062230.AA07219@hitchcock.eng.uiowa.edu>
Date: 6 Oct 90 22:30:24 GMT
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 11
Status: O

I have to agree about ghostscript.  Version 2.0 is much better than
version 1.X which I couldn't even get to compile correctly on a sun.
It is significantly faster than ralpage on almost any kind of graphics
too.

BTW, has anybody managed to compile it for a PC yet?

Yiannis Papelis
yiannis@hitchcock.eng.uiowa.edu
Dept. of Electrical and Computer Engineering
University of Iowa


From ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!morganucodon.cis.ohio-state.edu!jgreely Tue Oct  9 08:33:34 PDT 1990
Article: 28660 of comp.windows.x
Path: ucla-cs!usc!cs.utexas.edu!tut.cis.ohio-state.edu!morganucodon.cis.ohio-state.edu!jgreely
From: jgreely@morganucodon.cis.ohio-state.edu (J Greely)
Newsgroups: comp.windows.x
Subject: Re: Postscript previewer under X
Message-ID: <JGREELY.90Oct8152645@morganucodon.cis.ohio-state.edu>
Date: 8 Oct 90 19:26:45 GMT
References: <655046250@<chic> <22700017@ux1.cso.uiuc.edu>
	<106894@convex.convex.com>
Sender: news@tut.cis.ohio-state.edu
Reply-To: J Greely <jgreely@cis.ohio-state.edu>
Organization: Ohio State University Computer and Information Science
Lines: 12
In-reply-to: datri@convex.com's message of 5 Oct 90 17:18:59 GMT
Status: O

In article <106894@convex.convex.com> datri@convex.com
 (Anthony A. Datri) writes:
>Beware that PostScript devices define their own transfer functions,
>so without intimate knowledge of your specific printer, you can't
>always know exactly what dots will be plotted.

Adobe supplies PPD (PostScript Printer Description) files for most or
all real PostScript printers, available from the mail-server.  Among
other things, these contain the default halftone settings and transfer
function.  Damn handy.
--
J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)


From ucla-cs!usc!wuarchive!julius.cs.uiuc.edu!coolidge Tue Oct  9 11:05:01 PDT 1990
Article: 28673 of comp.windows.x
Path: ucla-cs!usc!wuarchive!julius.cs.uiuc.edu!coolidge
From: coolidge@cs.uiuc.edu (John L. Coolidge)
Newsgroups: comp.unix.aux,comp.windows.x
Subject: X11R4 with shared libraries for A/UX 2.0, release 2, now available
Summary: X11R4pl18 for A/UX 2.0 w/ shared libraries, release 2
Message-ID: <1990Oct9.000331.23597@julius.cs.uiuc.edu>
Date: 9 Oct 90 00:03:31 GMT
Sender: news@julius.cs.uiuc.edu (USENet News)
Reply-To: coolidge@cs.uiuc.edu
Organization: U of Illinois, Dept. of Computer Science, Systems Research Group
Lines: 51
Xref: ucla-cs comp.unix.aux:3093 comp.windows.x:28673
Originator: coolidge@vlad.cs.uiuc.edu
Status: O

I'm happy to announce that the second release of my port of X11R4 to
A/UX 2.0, complete with shared libraries for libs X11, Xt, Xaw, Xmu,
and Xext, is now available from wuarchive.wustl.edu in the directory
/archive/systems/aux/X11R4 (from ftp: systems/aux/X11R4). This version
of X11R4 is based on the most recent patchlevel from MIT, X11R4pl18.

This release incorporates fixes for every bug sent to me during the
test release. The most important "usability" bug fixed was the lack
of a working xinit; that appears to have been solved, and I've used
the provided xinit and startx commands to get X running with no
trouble. The other bugs fixed are 1) xterm sometimes incorrectly
updated the screen, repeating lines or mangling characters, and 2)
the server occasionally left bits of windows around. Interestingly,
these both had the same root cause. It's quite possible that bugs 
still exist; however, I haven't found any recently nor had any
reported.

The entire distribution consists of six tar files:

          Xbin.tar.Z     -- 2.5M (5M uncompressed)
          Xfonts.tar     -- 2.9M
          Xinclude.tar.Z -- 280K (1M uncompressed)
          Xlib.tar.Z     -- 1M   (2.5M uncompressed)
          Xman.tar       -- 1.3M
          Xmisc.tar.Z    -- 99K  (290K uncompressed)

plus installation instructions (in the file XREADME). There are also
several files of the form Xbin.tar.Z.a[abcd] and Xfonts.tar.[abcd];
these contain the same information as the larger tar files. They're
provided for those who can't ftp large files. When cat'ted together
they should produce the original tar file.

For those who picked up the earlier distribution, you need not get
the fonts or the man pages. Everything else has changed (the fonts
have too, actually, but not much --- just a mkfontdir in the misc
directory, and if you've gotten it running you're past that problem).

Enjoy!, and please send me problem reports so that I can fix whatever
bugs are still around (and please don't send me bugs that are in the
X code itself; I'll let MIT fix those :-)).

I'm hoping to have the source patches out within the next couple of
days.

--John

--------------------------------------------------------------------------
John L. Coolidge     Internet:coolidge@cs.uiuc.edu   UUCP:uiucdcs!coolidge
Of course I don't speak for the U of I (or anyone else except myself)
Copyright 1990 John L. Coolidge. Copying allowed if (and only if) attributed.
You may redistribute this article if and only if your recipients may as well.


From ucla-cs!usc!wuarchive!decwrl!bacchus.pa.dec.com!wsl.dec.com!klee Tue Oct  9 11:09:01 PDT 1990
Article: 28701 of comp.windows.x
Path: ucla-cs!usc!wuarchive!decwrl!bacchus.pa.dec.com!wsl.dec.com!klee
From: klee@wsl.dec.com (Ken Lee)
Newsgroups: comp.windows.x
Subject: Re: Attempting to interpret X application error msg
Message-ID: <1990Oct9.094430@wsl.dec.com>
Date: 9 Oct 90 16:44:30 GMT
References: <9010091448.AA03485@lilac.berkeley.edu>
Sender: news@wrl.dec.com (News)
Reply-To: klee@wsl.dec.com
Organization: DEC Western Software Laboratory
Lines: 14
Status: O

In article <9010091448.AA03485@lilac.berkeley.edu>, lwv27@CAS.BITNET writes:
|>   X Error:  BadValue, integer parameter out of range for operation
|>   Request Major code 1 ()

Major code 1 is a CreateWindow request.  BadValue is probably caused by
an invalid.  The default window size is often 0 x 0, which is invalid.
Try checking your geometry resources to make sure the window size is
set to something.

-- 
Ken Lee
DEC Western Software Laboratory, Palo Alto, Calif.
Internet: klee@wsl.dec.com
uucp: uunet!decwrl!klee


From ucla-cs!rutgers!netnews.upenn.edu!grip.cis.upenn.edu!bradley Wed Oct 10 16:39:28 PDT 1990
Article: 28742 of comp.windows.x
Path: ucla-cs!rutgers!netnews.upenn.edu!grip.cis.upenn.edu!bradley
From: bradley@grip.cis.upenn.edu (John Bradley)
Newsgroups: comp.windows.x
Subject: XV Announcement
Message-ID: <30933@netnews.upenn.edu>
Date: 10 Oct 90 18:39:28 GMT
Sender: news@netnews.upenn.edu
Reply-To: bradley@grip.cis.upenn.edu (John Bradley)
Distribution: na
Organization: Grasp Lab
Lines: 58
Status: O

(XV has been put up on expo, and posted to comp.sources.x)

XV is a direct successor to XGIF.  

New features include:
  * more graphic formats supported (GIF, PBM/PGM/PPM, and X11 bitmap)

  * works on most X displays (1-, 4-, 6-, 8-, and 24-bit displays are
    supported)

  * arbitrary scaling, cropping, rotation (in 90-degree steps)

  * can write files in all formats listed above

  * arbitrary gamma correction curve for brightness/contrast control
    and interesting effects

  * cool-whizo user interface

  * better color allocation code, including the ability to install its own
    colormap if necessary

  * more robust error handling

  * and more bug fixes than we'd care to discuss...


Full Description:
-----------------
XV is a program that displays image files in GIF, PBM/PGM/PPM, and X11 Bitmap
formats.  It is a direct sequel to XGIF, and fixes most (if not all) of the
shortcomings of that program.  XV runs on nearly ALL X displays, 1-bit,
4-bit, 6-bit, 8-bit, and 24-bit, color, grayscale, and black/white.  

XV displays one image at a time in an output window.  You can arbitrarily
stretch or compress the window, and the picture will be rescaled to fit.  
You can rotate the picture in 90-degree steps.  You can repeatedly 'crop'
a picture (define a rectangular 'region-of-interest' and 'throw away' the
rest).  You can magnify any portion of the picture by any amount, up to the 
maximum size of your screen.  

XV allows you click on the picture to determine pixel RGB values and x,y 
coordinates.  You can perform arbitrary 'gamma correction' on the picture
both in RGB space and HSV space.  You can specify the maximum number of colors
that XV should use, for some interesting visual effects.  You can have
the program produce a stippled version of the picture using black and white,
or any other pair of colors.  

XV can write images in a variety of formats, with many of the modifications 
you may have made to the picture saved as well.  You can use XV to do format 
conversion.  XV will also automatically uncompress compress-ed files, as well 
as read files from stdin.


John Bradley                    University of Pennsylvania  -  GRASP Lab
     bradley@cis.upenn.edu

     October 9, 1990


From ucla-cs!usc!wuarchive!uunet!snorkelwacker!bloom-beacon!zephyrus.crd.ge.COM!whitegm Wed Oct 10 16:40:19 PDT 1990
Article: 28744 of comp.windows.x
Path: ucla-cs!usc!wuarchive!uunet!snorkelwacker!bloom-beacon!zephyrus.crd.ge.COM!whitegm
From: whitegm@zephyrus.crd.ge.COM (gerald m white)
Newsgroups: comp.windows.x
Subject: (none)
Message-ID: <9010101454.AA29128@zephyrus.crd.Ge.Com>
Date: 10 Oct 90 14:54:01 GMT
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 25
Status: O

Subject: Updated version of xwd2ps on expo
A new version of xwd2ps (xwd to Color Postscript utility) has been placed 
on expo. The current version fixes the following bugs that
were discovered since the Aug. 14th release.

1. When using a pipe from xwd to xwd2ps the printed PostScript file would
   sometimes have "rips". 
2) An EOF not correctly being interpreted in xwd2ps.c when running on
   a Silicon Graphic's Iris workstation.
3) Having the -l (logo option) print correctly when my_logo.h was used for the
   logo.
4) Some corrections for printing Big Endian xwd dumps on Little Endian
   systems (This may still not work correctly).
5) Supplying an Imakefile rather than a Makefile.
6) Initialized 2 variables since some c-compilers gave serious warning
   messages. (This also may have fixed a bug in the -f option.)
7) Date appears to work. Removed the statement that it doesn't from the
   manual page.

An earlier version submitted Aug. 14th had the following fixes
1) A bug passing strings to strcpy.
2) An improvement to the way memory is used in the downloaded PostScript
   program.
If you find bugs (with hopefully corrections) or other difficulties
send mail to xwd2ps-support@crd.ge.com


From ucla-cs!usc!cs.utexas.edu!sun-barr!ccut!s.u-tokyo!hideki Tue Oct 23 08:31:50 PDT 1990
Article: 29196 of comp.windows.x
Path: ucla-cs!usc!cs.utexas.edu!sun-barr!ccut!s.u-tokyo!hideki
From: hideki@is.s.u-tokyo.ac.jp (YOSHIDA Hideki)
Newsgroups: comp.sources.d,comp.text.tex,comp.windows.x
Subject: Re: v10i009: xdvi, Patch10, Part01/02
Message-ID: <964@utsun.s.u-tokyo.ac.jp>
Date: 20 Oct 90 00:41:08 GMT
References: <csx-10i009:xdvi@uunet.UU.NET> <143915@sun.Eng.Sun.COM>
Sender: news@s.u-tokyo.ac.jp
Reply-To: hideki@is.s.u-tokyo.ac.jp
Followup-To: comp.sources.d
Organization: Dept. of Information Science, the Univ. of Tokyo, Japan.
Lines: 27
Xref: ucla-cs comp.sources.d:6176 comp.text.tex:3468 comp.windows.x:29196
In-reply-to: vojta@math.Berkeley.EDU's message of 18 Oct 90 22:35:18 GMT
Status: O

I have a problem with xdvi (patchlevel 10); If I tell xdvi to reread
dvi files with `R', it sometimes aborts with `Non-existent font'. 

Following patch seems to solve this problem:

*** dvi_init.c.orig	Fri Oct 19 11:10:39 1990
--- dvi_init.c	Fri Oct 19 11:29:39 1990
***************
*** 182,187 ****
--- 182,188 ----
  	    if (strcmp(fontp->fontname, fontp1->fontname) == 0
  		    && size == fontp1->size) {
  		*fontpp = fontp1->next;
+ 		fontp1->TeXnumber = fontp->TeXnumber;
  		free(fontp->fontname);
  		free((char *) fontp);
  		fontp = fontp1;

I want to know whether this change is correct.
---
					Yoshida Hideki

					Department of Information Science
					Faculty of Science
					The University of Tokyo

					hideki@is.s.u-tokyo.ac.jp


From ucla-cs!rutgers!gatech!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse Tue Oct 23 08:32:56 PDT 1990
Article: 29217 of comp.windows.x
Path: ucla-cs!rutgers!gatech!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU
Newsgroups: comp.windows.x
Subject: Re:  Russian (Cyrillic) fonts for x11
Message-ID: <9010200502.AA26647@Larry.McRCIM.McGill.EDU>
Date: 20 Oct 90 05:02:01 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 13
Status: O

> Does anyone know of any available Russian Cyrillic fonts for X11?

I don't know how it relates to what modern Russian uses, but in k14
there is a set that looks to my eyes like a complete Cyrillic set (mind
you, I haven't touched Russian in fifteen years).  The capital letters
are 0x2721 through 0x2741 and the small are 0x2751 through 2771.  I
*think* both sets are in alphabetical order, but my memory is hazy
enough that I'm not at all sure.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu


From ucla-cs!elroy.jpl.nasa.gov!lll-winken!uunet!xwind!ron Tue Oct 23 08:34:10 PDT 1990
Article: 29240 of comp.windows.x
Path: ucla-cs!elroy.jpl.nasa.gov!lll-winken!uunet!xwind!ron
From: ron@xwind.UUCP (Ronald P. Hughes)
Newsgroups: comp.windows.x,comp.terminals
Subject: Re: NCD terminals: comments on quality requested
Message-ID: <400@xwind.UUCP>
Date: 20 Oct 90 19:34:02 GMT
References: <1990Oct11.235154.25565@mtcchi.uucp>
Reply-To: ron@xwind.UUCP (Ronald P. Hughes)
Followup-To: comp.windows.x
Distribution: na
Organization: CrossWind Technologies, Inc., 6630 Highway 9, Suite 201, Felton, Ca. 95018
Lines: 13
Xref: ucla-cs comp.windows.x:29240 comp.terminals:2586
Status: O

In article <1990Oct11.235154.25565@mtcchi.uucp> levy@mtcchi.uucp (2656-Daniel R. Levy(0000000)0000) writes:
>I am requesting comments, positive or negative, on the overall quality of NCD
>(Network Computing Devices) terminals.

We have an NCD16 which we purchased back in the spring of 1989.  We've used it
here in the office and dragged it to various shows.  We have also had various
NDC demo units at shows and here at the office.  All of them have worked great.
No problems.  The image is still crisp, square & centered.

Ronald P. Hughes		ron@xwind.com  (or ...!uunet!xwind!ron)
CrossWind Technologies, Inc.	408-335-4988

STANDARD DISCLAIMER:  I have no interest in NCD.  They seem like nice folks, though.


From ucla-cs!oahu.cs.ucla.edu!william Sun Oct 28 18:19:28 PST 1990
Article: 29532 of comp.windows.x
Path: ucla-cs!oahu.cs.ucla.edu!william
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: Tgif-1.16 (Xlib based 2-D drawing tool) is available on expo ...
Keywords: draw, tool, postscript, latex, hierarchical, x11, xlib, wysiwyg
Message-ID: <40695@shemp.CS.UCLA.EDU>
Date: 28 Oct 90 01:01:45 GMT
Sender: news@CS.UCLA.EDU
Followup-To: william@cs.ucla.edu
Organization: UCLA Computer Science Department
Lines: 3700
Nntp-Posting-Host: oahu.cs.ucla.edu
Originator: william@oahu.cs.ucla.edu
Status: RO

I've just put tgif-1.16 in the following places for anonymous ftp:

	expo.lcs.mit.edu	contrib/tgif-1.16.tar.Z
	cs.ucla.edu		pub/tgif-1.16.tar.Z

Here's a short list of added features/bug fixes.

1) Fix bugs related makeing a grouped object iconic.  Used to have the
   wrong file name.
2) Remove the restriction of just being able to edit files under the
   current directory.
3) New implementation of domains.  Now a domain specifies a search path
   for the .sym files.  The mechanism is very similar as the csh PATH
   environment variable.  Please read the man pages for details (grep
   for the string "domain" or "Domain" in 'tgif.man').

I've talked to some people about putting in support for color PostScript
and dash patterns and I can't get them done yet.  They will be in the
next release.  I appologize for my delay.

The following is the patch to take tgif from version 1.15 to 1.16.
---------------------------------> cut here <---------------------------------

From ucla-cs!oahu.cs.ucla.edu!william Sun Oct 28 18:19:51 PST 1990
Article: 29533 of comp.windows.x
Path: ucla-cs!oahu.cs.ucla.edu!william
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: missing patches in Tgif-1.16 news posting ...
Keywords: draw, tool, postscript, latex, hierarchical, x11, xlib, wysiwyg
Message-ID: <40696@shemp.CS.UCLA.EDU>
Date: 28 Oct 90 01:19:16 GMT
Sender: news@CS.UCLA.EDU
Followup-To: william@cs.ucla.edu
Organization: UCLA Computer Science Department
Lines: 174
Nntp-Posting-Host: oahu.cs.ucla.edu
Originator: william@oahu.cs.ucla.edu
Status: RO

I forgot to include the following patches for my previous posting.
Apply the following patch in addition to the patch to take tgif from
1.15 to 1.16.  Here is the patch.

---------------------------------> cut here <---------------------------------

From ucla-cs!oahu.cs.ucla.edu!william Wed Oct 31 10:04:27 PST 1990
Article: 29552 of comp.windows.x
Path: ucla-cs!oahu.cs.ucla.edu!william
From: william@oahu.cs.ucla.edu (William Cheng)
Newsgroups: comp.windows.x
Subject: Another missing patch in Tgif-1.16 news posting ...
Keywords: draw, tool, postscript, latex, hierarchical, x11, xlib, wysiwyg
Message-ID: <40713@shemp.CS.UCLA.EDU>
Date: 29 Oct 90 02:33:15 GMT
Sender: news@CS.UCLA.EDU
Followup-To: william@cs.ucla.edu
Organization: UCLA Computer Science Department
Lines: 40
Nntp-Posting-Host: oahu.cs.ucla.edu
Originator: william@oahu.cs.ucla.edu
Status: RO

I appologize for missing another patch for Tgif-1.16.  Apply the following
patch in addition to the patch to take tgif from 1.15 to 1.16 and the
bitmap patches posted previously (Articles 29532 and 29534 of comp.windows.x).
Thanks to Paul Nakada <pnakada@pnakada.oracle.com> for pointing this out.

Apply this patch and the previous bitmap patches with the following command:

	patch -p -N < patchfilename

---------------------------------> cut here <---------------------------------

From ucla-cs!oahu.cs.ucla.edu!william Wed Nov  7 10:24:10 PST 1990
Article: 29915 of comp.windows.x
Newsgroups: comp.windows.x
Path: ucla-cs!oahu.cs.ucla.edu!william
From: william@oahu.cs.ucla.edu (William Cheng)
Subject: Tgif-1.17 (Xlib based 2-D drawing tool) is available on expo ...
Message-ID: <1990Nov6.202809.28671@cs.ucla.edu>
Followup-To: william@cs.ucla.edu
Originator: william@oahu.cs.ucla.edu
Keywords: draw, tool, postscript, latex, hierarchical, x11, xlib, wysiwyg
Sender: news@cs.ucla.edu (Mr. News)
Nntp-Posting-Host: oahu.cs.ucla.edu
Organization: UCLA Computer Science Department
Date: Tue, 6 Nov 90 20:28:09 GMT
Status: RO

I've just put tgif-1.17 in the following places for anonymous ftp:

	expo.lcs.mit.edu	contrib/tgif-1.17.tar.Z
				contrib/tgif-1.16to1.17.Z
	cs.ucla.edu		pub/tgif-1.17.tar.Z
				pub/tgif-1.16to1.17.Z

Here's a short list of added features/bug fixes.

1) Fix bugs to use getwd() to get current working directory.  Thanks to
   Peter Mutsaers (muts@fysaj.fys.ruu.nl) for pointing it out.
2) Add color attributes in color PostScript files.  (Default for
   printing is still non-color.  Type ^#K to switch to color
   PostScript output.)
3) Add dash patterns and change tgif file version to 9.
4) Add 4 more buttons in the panel (choice window).  Now all secondary
   pop-up menus can be poped-up from the panel (except for the edit menu).
5) Add the ``UpdateSymbols()'' feature.  Selected icons can be
   ``brought up-to-date'' with the current representations found
   in the symbol path.  Each new icon is placed so that it is lined
   up at the upper-left corner with the old icon.  This feature is
   accessible by typing ^#U.
6) If one of the font can not be found, a font with a different
   dots-per-inch is automatically chosen.  If both can not be found,
   tgif exits.  (Apparently some machines only support 100dpi fonts
   by default.)

Someone complained that I shouldn't post patches in this newsgroup,
and so I put the patches at the ftp sites as tgif-1.16to1.17.Z.  If you
don't have ftp capability, please send e-mail to william@cs.ucla.edu,
and I'll be happy to send you the patches.

I do not intend to add any more features to tgif in the near future;
however, I'll be posting patches to fix bugs and add minor enhancements.
Please feel free to send me comments and bug reports.
-- 
Bill Cheng // UCLA Computer Science Department // (213) 206-7135
3277 Boelter Hall // Los Angeles, California 90024 // USA
william@CS.UCLA.EDU      ...!{uunet|ucbvax}!cs.ucla.edu!william


From ucla-cs!oahu.cs.ucla.edu!william Thu Nov  8 17:11:09 PST 1990
Article: 29965 of comp.windows.x
Newsgroups: comp.windows.x
Path: ucla-cs!oahu.cs.ucla.edu!william
From: william@oahu.cs.ucla.edu (William Cheng)
Subject: Tgif-1.18 (Xlib based 2-D drawing tool) is available on expo ...
Message-ID: <1990Nov7.204817.1491@cs.ucla.edu>
Originator: william@oahu.cs.ucla.edu
Keywords: draw, tool, postscript, latex, hierarchical, x11, xlib, wysiwyg
Sender: news@cs.ucla.edu (Mr. News)
Nntp-Posting-Host: oahu.cs.ucla.edu
Organization: UCLA Computer Science Department
Date: Wed, 7 Nov 90 20:48:17 GMT
Status: RO

I've just put tgif-1.18 in the following places for anonymous ftp:

	expo.lcs.mit.edu	contrib/tgif-1.18.tar.Z
	cs.ucla.edu		pub/tgif-1.18.tar.Z

Here's a short list of added features/bug fixes.

1) Fix rotated text.  On some servers it doesn't work.  (Should use
   ZPixmap instead of XYPixmap when calling XGetImage ().)
2) There was this problem that after a new symbol file is saved and
   one tries to save it again (with ^s), tgif thinks the file name
   is /symbolfilename.  This bug is fixed.
3) If fonts of certain dots-per-inch can not be found and an
   alternative fonts with different dots-per-inch can be found,
   the file status should be set to 'MODIFIED'.
4) If the symbol path contains a ".", then whenever a directory is
   changed, the symbol name cache should be updated.

Due to the SMALL size of this patch, the patch file is posted in this
newsgroup.

The following is the patch to take tgif from version 1.17 to 1.18.
---------------------------------> cut here <---------------------------------

From ucla-cs!oahu.cs.ucla.edu!william Sat Nov 10 14:21:20 PST 1990
Article: 30104 of comp.windows.x
Newsgroups: comp.windows.x
Path: ucla-cs!oahu.cs.ucla.edu!william
From: william@oahu.cs.ucla.edu (William Cheng)
Subject: Tgif-1.19 (Xlib based 2-D drawing tool) is available on expo ...
Message-ID: <1990Nov10.221949.25387@cs.ucla.edu>
Originator: william@oahu.cs.ucla.edu
Keywords: draw, tool, postscript, latex, hierarchical, x11, xlib, wysiwyg
Sender: news@cs.ucla.edu (Mr. News)
Nntp-Posting-Host: oahu.cs.ucla.edu
Organization: UCLA Computer Science Department
Date: Sat, 10 Nov 90 22:19:49 GMT
Status: RO

I've just put tgif-1.19 in the following places for anonymous ftp:

	expo.lcs.mit.edu	contrib/tgif-1.19.tar.Z
	cs.ucla.edu		pub/tgif-1.19.tar.Z

Here's a short list of added features/bug fixes.

1) Fix a bug in names.c which cause segmentation faults on some machines.
2) If certain color can not be found, skip it, don't leave it blank.
3) Add explanations in tgif.man about how the alignments work.

Due to the small size of this patch, the patch file is posted in this
newsgroup.

The following is the patch to take tgif from version 1.18 to 1.19.
---------------------------------> cut here <---------------------------------

