HDTenEightyP/NetNews huggingface dataset:
From: matt@centerline.com (Matt Landau)
Newsgroups: fj.mail-lists.x-window
Subject: Re: FLAME, FLAME ON X!!!
Date: 18 Nov 92 09:09:30 GMT
Distribution: fj
Organization: CenterLine Software, Inc.

Date: 10 Nov 92 18:28:15 GMT
Message-Id: <1douvvINNe8a@armory.centerline.com>
Newsgroups: comp.windows.x

In <1992Nov10.173203.10719@dsd.es.com> pmartz@dsd.es.com (Paul Martz) writes:
>Yes but this doesn't sound like what the guy's describing. If this is
>just free() only freeing memory back to the process, then starting the
>same X client over again and walking it through the same sequence of
>tasks should not cause the server process size to grow, because the
>memory it freed before is still available to it.

I think this depends on what happens between invocations of the client.  
Depending on what other clients are running and what requests are being 
made of the server, it seems possible that the large contiguous blocks 
or memory previously used for displaying large pixmaps might be partially 
or wholly reallocated to other clients, and that the resulting memory
fragmentation would require malloc(some-large-size) to go back to the
operating system for more memory if no suitably large block remained
on the free list.
From: cjmchale@dsg.cs.tcd.ie (Ciaran McHale)
Newsgroups: fj.mail-lists.x-window
Subject: Re: Initializing Bitmap's
Date: 19 Nov 92 21:53:26 GMT
Distribution: fj
Organization: DSG, Dept. of Computer Science, Trinity College Dublin

Date: 19 Nov 92 14:23:18 GMT
Message-Id: <1992Nov19.142318.22505@dsg.cs.tcd.ie>
Newsgroups: comp.windows.x

In <1eem4rINNl0c@uwm.edu> amit@point.cs.uwm.edu (Amit Srivastava) writes:
>Is there way to initialize a bitmap to say all 0's , without
>doing without loading it from a data file.  I am drawing on the Pixmap,
>of depth 1, but I getting garbage at locatiuons I have not drawn.
>		Any quick way to do this?  Thanx.

Yes, use XFillRectangle; have the foreground color of the GC set to 0.


Ciaran.
-- 
---- Ciaran McHale (cjmchale@dsg.cs.tcd.ie)
\bi/ Department of Computer Science, Trinity College, Dublin 2, Ireland.
 \/  Telephone: +353-1-7021539 FAX: +353-1-6772204
From: anderson@mayo.edu (Alfred I. Anderson)
Newsgroups: fj.mail-lists.x-window
Subject: Can X accept non-traditional data (Voice, Pen)
Date: 17 Nov 92 10:47:31 GMT
Distribution: fj
Organization: Mayo Foundation

Date: Mon, 16 Nov 1992 18:04:26 GMT
Message-Id: <anderson.52.721937065@mayo.edu>
Newsgroups: comp.windows.x

I'm brand new to X-Windows and have been following this group to gain 
knowledge of X. 

This may be a nieve question but, OS/2 and Windows NT will support 
alternative data modalities (pen, handwriting recognition, voice 
acquisition, voice presentation)?

Alfred
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Alfred Anderson                Internet:    anderson@Mayo.edu
Mayo Foundation - Rochester MN 55905
-----------------------------------------------------------------
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: fj.mail-lists.x-window
Subject: Re: Communcation with applications using XSendEvent?
Date: 16 Nov 92 12:54:15 GMT
Distribution: fj
Organization: McGill Research Centre for Intelligent Machines

Date: Sun, 15 Nov 92 21:16:13 GMT
Message-Id: <1992Nov15.211613.21790@thunder.mcrcim.mcgill.edu>
Newsgroups: comp.windows.x

In article <1e0id4INNgmi@uwm.edu>, amit@point.cs.uwm.edu (Amit Srivastava) writes:

> I am trying to use XSendEvent to communicate with diff. applications,
> using the ClientMessageEvent as my event type.  What kind of Mask
> needs to be set up on the receiveing side for an application to
> receive client message events?

RTFM.  The (R4) Xlib document says

	8.3.  Event Masks
[...]
	Unless the client has specifically asked for them, most events
	are not reported to clients when they are generated.  [...]
	SelectionClear, SelectionRequest, SelectionNotify, or
	ClientMessage cannot be masked.  [...]

So no mask need be set by the receiving application; indeed, it cannot
prevent itself from getting such events - if it doesn't want them, it
must ignore them.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: okeefe@cs.Buffalo.EDU (Paul O'Keefe)
Newsgroups: fj.mail-lists.x-window
Subject: Re: OLIT: Red focus color: HOW DO I GET RID OF IT????
Date: 17 Nov 92 14:53:24 GMT
Distribution: fj
Organization: State University of New York at Buffalo/Comp Sci

Date: 17 Nov 92 01:17:34 GMT
Message-Id: <Bxu69A.LzE@acsu.buffalo.edu>
Newsgroups: comp.windows.open-look,comp.windows.x


In article <1992Nov16.043159.1258@netlabs.com>, gerolima@netlabs.com (Mark Gerolimatos) writes:
> 
> In OLIT 3.0 and 2.5 applications, the widget with the focus gets turned bright, 
> awful, "dog in heat" red. I hate it. Customers hate it. Our Q-n-A guys hate it. 
> Some of my friends at Sun hate it. EVERYONE hates it.
> 

Keyboard traversal can be turned off altogether or you can change the focus color.
It's turned on/off by the OLIT resource XtNtraversalOn.
The focus color is set by OLIT resource XtNInputFocusColor.

If you leave keyboard traversal ON and attempt to set 
InputFocusColor == background color, OLIT ignores it.
The best you can do is something close.

Most OLIT widgets have traversal turn on by default.

-Paul O'Keefe
From: villa@sparrow.lcs.mit.edu (Ferdinando Villa)
Newsgroups: fj.mail-lists.x-window
Subject: Re: Scatter Plotting
Date: 17 Nov 92 03:23:15 GMT
Distribution: fj
Organization: Ecologia Universita' di Parma

Date: 16 Nov 92 11:57:58 +0100
Message-Id: <1992Nov16.115759.642@cine88.cineca.it>
Newsgroups: comp.windows.x


  The most powerful program I know of is Xgobi, available through statlib
and a number of FTP sites. It is an analysis tool rather than a plotting 
program, and can do a great number of operations on multidimensional 
scatterplots. The problem is it has not yet very well expanded for producing
printed plots (I understand postscript output is not yet implemented) but
if you are involved in scattergrams it is a must, and you should at least
try it.



Ferdinando Villa, dr. 

Institute of Ecology                     Direct phone: +39-521-905615
University of Parma                               FAX: +39-521-905665
Viale delle Scienze                      e.mail: villa@sparrow.bio.unipr.it
43100 Parma, Italy                               villa@aida.eng.unipr.it
From: snail@lsl.co.uk
Newsgroups: fj.mail-lists.x-window
Subject: Re: How does a Motif App know if a shell widget is iconified?
Date: 19 Nov 92 02:12:48 GMT
Distribution: fj
Organization: Laser-Scan Ltd., Cambridge

Date: 18 Nov 92 16:10:49 GMT
Message-Id: <1992Nov18.171049.2651@lsl.co.uk>
Newsgroups: comp.windows.x.motif,comp.windows.x

In article <1992Nov18.003838.22438@ccd.harris.com>, djs@controls.ccd.harris.com (Dan J. Smith) writes:
> 
> I'm trying to figure out how a motif application can tell if a shell widget
> is iconified. I've looked through the O'Reilly books and tried few things 
> with no success. Does anyone out there have a solution? 

static int _check_wm_state(Display *display,
                           Window  window)
{
unsigned long *property = NULL;
unsigned long nitems;
unsigned long leftover;
Atom          xa_WM_STATE, actual_type;
int           actual_format;
int           status;

#define WM_STATE_ELEMENTS 1

XSync(display, FALSE); /* Ensure everything up to date, not absolutely needed*/

xa_WM_STATE = XInternAtom(display, "WM_STATE", False);
status = XGetWindowProperty(display, window, xa_WM_STATE,
                            0L, WM_STATE_ELEMENTS,
                            &actual_type, &actual_format, &nitems, &leftover,
                            (unsigned char **)&property);
if (!((status == Success) &&
      (actual_type == xa_WM_STATE) &&
      (nitems == WM_STATE_ELEMENTS)))
{
	if (property != NULL)
	{
		XFree((char *)property);
		property = NULL;
	}
}

/* now determine shell state from this info */

if (property == NULL)
	/* unknown */
else if (*((int *)property) == IconicState)
	/* Iconic */
else if (*((int *)property) == NOrmalState)
	/* Normal, visible */
else if (*property == WithdrawnState)
	/* Not visible, not iconic */
else
	/* unknown */

if (property != NULL)
	XFree((char *)property);

---------

Apologies for the formatting, I've had to type this, looking at another window,
our news reader isn't up to much and this editor doesn't understand cut/paste.
But the code is correct, as are the casts (and in places lack of casts). Type
it as it is (for ANSI C). Works on multi platforms here.
-- 
snail@lsl.co.uk      

You Have To Remember, You Need To Believe,
The Time Has Past, Dust In The Leaves.
From: rescorla@rtnmr.chem.yale.edu (Eric Rescorla)
Newsgroups: fj.mail-lists.x-window
Subject: Re: FLAME, FLAME ON X!!!
Date: 19 Nov 92 23:40:47 GMT
Distribution: fj
Organization: Rescorla for himself.

Date: Wed, 18 Nov 1992 19:49:05 GMT
Message-Id: <1992Nov18.194905.16185@cs.yale.edu>
Newsgroups: comp.windows.x

In article <1992Nov18.183826.2652@lsl.co.uk> snail@lsl.co.uk writes:
>In article <1992Nov9.235741.25166@dsd.es.com>, pmartz@dsd.es.com (Paul Martz) writes:
>> Care to tell us in which vendor's X is this a bug? I've certainly
>> never heard of it before.
>
>This is NOT an X bug. This is a feature of C's memory allocation routines. When
>memory is allocated, if there is no spare space, the C library asks the
>OS for more memory, but when memory is freed, C does not give the memory back
>to the OS. As a result programs can only get bigger, or stay the same size as
>memory as allocated and freed. The program gets bigger every time memory is
>requested and cannot be allocate out of the current free heap space. When this
>happens the C library ask the OS for more memory. When the memory is freed,
>it is returned to the free memory heap, not the OS.
>
>*** This is not a UNIX feature, this is a C feature, to be found on PCs, Ataris
>, UNIX boxes, VAXes etc. This a feature, ie: C is designed this way. ****
>
>My apologies for replying to this thread 3 days late, someone has probably said
>this before. But then again, maybe they haven't.
I hope not. It's wrong. It is not part of the definition of the
C language or of malloc(3). It happens that it is a very common way to
do things, because sbrk(2) calls are expensive and it's not obviously
worthwhile to return memory to the system. (This is on Unix. I imagine
that similar conditions obtain on other machine.)

However, it would be quite legal to return the memory to the OS. I believe
Jim Frost mentioned previously that he had in fact written such a malloc
routine.
-Ekr


-- 
-------------------------------------------------------------------------------
Eric Rescorla, DoD#431 (Nighthawk S)              rescorla@rtnmr.chem.yale.edu
Former chemist now CM400 mechanic                 ekr@eitech.com(preferred)
                "Meet the new boss, same as the old boss."
From: ygor@aplexus.jhuapl.edu (Daniel E. White  (F2C))
Newsgroups: fj.mail-lists.x-window
Subject: Re: Pixmap width and height?
Date: 16 Nov 92 12:34:16 GMT
Distribution: fj
Organization: Johns Hopkins U. Applied Physics Lab

Date: Tue, 10 Nov 1992 13:03:18 GMT
Message-Id: <BxI49I.HqE@netnews.jhuapl.edu>
Newsgroups: comp.windows.x.motif,comp.windows.x

In article <1992Nov10.123700.2627@lsl.co.uk>, snail@lsl.co.uk writes:
|> Hello everyone, the snail has a problem...
|> 
|> Does anyone know how to determine the width of a pixmap that you have. Say
|> for example I had used XmGetPixmap(...) to fetch a pixmap from a UIL file
|> (an exported icon, for example) I do not know the pixmap's width or height.
|> I would like this info so that I can extract a bitmap from this pixmap.
|> 
|> Don't ask why, or suggest specifying the bitmaps a different way. We want
|> bitmaps from Pixmaps (I can do that bit), but I need to know the width and
|> height of the pixmap automatically (ie: through a function)rather than the user
|> specifying the width and height.
|> 
|> Alternatively, if you know of a way of extracting a bitmap from a pixmap
|> without previously knowing the width or height of the pixmap, let me know.
|> 
|> Thanks folks
|> -- 
|> snail@lsl.co.uk      
|> 
|> You Have To Remember, You Need To Beleive,
|> The Time Has Past, Dust In The Leaves.

How about XGetGeometry() or XtGetValues()

-- 
------------------------------------------------------------------------
                                                               Dan White
------------------------------------------------------------------------
"Sometimes  I  think  the  surest  sign  that  intelligent  life exists
 elsewhere  in the universe is that none of it has tried to contact us."
                                                  Calvin (Bill Waterson)
From: ndiaye@sol.cs.uni-sb.de (Alassane Ndiaye)
Newsgroups: fj.mail-lists.x-window
Subject: HOW TO CONVERT FROM POSTSCRIPT TO GIFF OR PBM ?
Date: 16 Nov 92 23:12:17 GMT
Distribution: fj
Organization: University of Saarbruecken -- Germany

Date: 16 Nov 92 10:03:39 GMT
Message-Id: <NDIAYE.92Nov16110339@sol.cs.uni-sb.de>
Newsgroups: comp.windows.x,comp.windows.x.apps,comp.graphics


Hello Netters,
Can someone send me please a tool to convert bitmaps from POSTSCRIPT
format to GIFF, PBM, or PGM format. I've already looked in the pbmplus
tools, but didn't found anything appropriate.

Please e-mail me additionally to posting.
Regards,
--
-------------------------------------------------------------
|NET: ndiaye@cs.uni-sb.de				    |
|-----------------------------------------------------------|
|POST: Alassane NDIAYE   	   |                        |
|      FB 14 - Informatik IV	   | PHONE: +49-681-302-4135|
|      Universitaet des Saarlandes |                        |
|      Im Stadtwald 15		   |------------------------|
|      D-6600 Saarbruecken 11	   | FAX:   +49-681-302-4421|
|      Federal Republic of Germany |			    |
-------------------------------------------------------------
From: william@lanai.cs.ucla.edu (William Cheng)
Newsgroups: fj.mail-lists.x-window
Subject: Tgif-2.12-patch13 is available on export...
Date: 18 Nov 92 22:16:05 GMT
Distribution: fj
Organization: UCLA, Computer Science Department

Date: Wed, 11 Nov 92 08:14:28 GMT
Message-Id: <1992Nov11.081428.26887@cs.ucla.edu>
Newsgroups: comp.windows.x

I've just put tgif-2.12-patch13 (13th patch for tgif-2.12) in the
following places for anonymous ftp:

	export.lcs.mit.edu:/contrib/tgif-2.12-patch13.Z
	cs.ucla.edu:/pub/tgif/tgif-2.12-patch13.Z

The patch is also posted to comp.sources.bugs.

Please uncompress and then apply the patch with
'patch -p -N < tgif-2.12-patch13'.
Here's a short list of added features/bug fixes.

1)  Fix bugs related to the tgif -print feature.  The problem was that
    popen() calls sh(1) and that quotes are stripped by sh(1).
    Thanks to Yoichiro Ueno <ueno@cs.titech.ac.jp> for the code fixes.
2)  The TextSize and TextStyle menus were reversed.
3)  Generate integer bounding box in PostScript output files.  This is to
    conform to the PostScript standard.
4)  Augment the UsePsAdobeString X default such that specific %!PS-Adobe
    string can be specified.  In addition to ``true'' and ``false'',
    UsePsAdobeString can also be specified with <Adobe_Version>/<EPSF_Version>.
    The command line option "-adobe=<Adobe_Version>/<EPSF_Version>" is also
    added.
5)  Add a new X default, ForceClearAfterEPS.  When it is set to ``true'',
    the PostScript stack is cleared after printing an EPS object.  This action
    was always taken in patchlevel 12 of version 2.12.  However, recently
    I found that the PostScript Language Reference Manual strongly discourages
    doing so.  Therefore, use this only if you REALLY want to generate the
    illegal "clear" command to get around some buggy EPS documents (such as
    the one generated by xgrabsc).
6)  Add the -DHP_LINE_BUG compile option to get around some buggy HP servers.
7)  Remove unrecognized commands in the man pages.

(running 'sum' on tgif-2.12-patch13.Z on a SUN4 should get: 32710  19)

Please send bug reports to william@cs.ucla.edu.
-- 
Bill Cheng // UCLA Computer Science Department // (310) 645-8328
3564-C Boelter Hall // Los Angeles, California 90024 // USA
william@CS.UCLA.EDU      ...!{uunet|ucbvax}!cs.ucla.edu!william
From: rchui@nswc-wo.nswc.navy.mil (Raymond Chui)
Newsgroups: fj.mail-lists.x-window
Subject: Why KeyPress/Release not work in DrawingAreaWidget?
Date: 17 Nov 92 14:05:18 GMT
Distribution: fj
Organization: Naval Surface Warfare Center - White Oak

Date: 10 Nov 92 16:31:48 GMT
Message-Id: <1992Nov10.163148.19985@relay.nswc.navy.mil>
Newsgroups: comp.windows.x,comp.windows.x.motif,comp.windows.x.apps


I am writing a Motif program, I try do some sample as following:

....
....
drawing_a = XtVaCreateManagedWidget("drawing_a",
        xmDrawingAreaWidgetClass, sw, /* scroll widget */
	....
	....
	NULL);
XtAddCallback(drawing_a, XmNinputCallback, input, NULL);
......
......

void input(widget, data, cbs)
Widget widget;
XtPointer data;
XmDrawingAreaCallbackStruct *cbs;
{
	XEvent *event = cbs->event;
	.....;
	.....;

	if (cbs->reason == XmCR_INPUT) {
		switch (event->xany.type) {
		case ButtonPress:
			printf("got a buttonpress\n");
			break;
		case ButtonRelease:
			printf("got a buttonrelease\n");
			break;
		case KeyPress:
			printf("got a keypress event\n");
			break;
		case  KeyRelease:
			printf("got a keyrelease event\n");
			break;
		default:
			;
			break;
		} /* end switch */
	} /* end if */
} /* end function */

This only work for ButtonPress/Release, but not KeyPress/Release, why?

If you see O'Reilly volume 6 "Motif Programming Manual" page 339
Table 10-1 "Callback Reasons and Event Types"
You will see:

Callback		cbs->event->xany.type		cbs->reason
-------------------------------------------------------------------
XmNinputCallback	ButtonPress, ButtonRelease,	XmCR_INPUT
			KeyPress, KeyRelease

Can someone out there explain to me why the KeyPress/Release are
not work for me? Do I missing something? Why the ButtonPress/Release
are work for me?
Thank you in advance!

-- 
Raymond H. Chui
NSWC N62
10901 New Hampshire Ave.
Silver Spring, MD 20903-5000
U.S.A.
Voice:1-301-394-5192 Fax:1-301-394-5835
E-Mail:rchui@nswc-wo.nswc.navy.mil
 _ __                                  _    ,    __
' )  )                           /    ' )  /    /  ) /
 /--' __. , , ____   ______   __/      /--/    /    /_  . . o
/  \_(_(_(_/_/) ) )_(_) /) )_(_(_     /  ( o  (__/ / /_(_/_(_
          /
         '
From: u438813@imux120.ncu.edu.tw (Lin Wei-Ting)
Newsgroups: fj.mail-lists.x-window
Subject: Resizing a pixmap
Date: 18 Nov 92 00:20:04 GMT
Distribution: fj
Organization: Sun Microsystems, Inc.

Date: Tue, 17 Nov 1992 00:51:02 GMT
Message-Id: <1992Nov17.005102.15503@sparc4.ncu.edu.tw>
Newsgroups: comp.windows.x

I'm looking for a quick way to resize a pixmap.
Suggest an algorithm,thanks.
From: czim@apache.scp.caltech.edu (Chris Ziomkowski)
Newsgroups: fj.mail-lists.x-window
Subject: Can Xsun run on a Sparc2/GT?
Date: 18 Nov 92 21:58:35 GMT
Distribution: fj
Organization: caltech

Date: 10 Nov 92 21:44:45 GMT
Message-Id: <1dpagdINNivb@gap.caltech.edu>
Newsgroups: comp.windows.x

I was wondering if anyone has managed to get Xsun to work on a Sparc2 with
a GT accelerator? All attempts at getting Xsun to recognize /dev/gt0 have
failed miserably. If we can't figure out how to get the MIT server up and
running, we are going to have to use (gasp) openwindows. I can feel my
applications slooowwwwing down already.....

Any help is greatly appreciated,

Chris.

-- 
---------------------------------------------------__-----------------------
 Chris Ziomkowski                                 /  |
 Software Consultant                              |  |           _______
                                              |___|  |____/-|   /  |
 czim@scp.caltech.edu - ---- ---- ---- ---- - *|__|  |____----  \_/
                                              |   |  |    \-|
 "Flying is more fun anyway"                      |  |          --------
                                                  \__|
----------------------------------------------------------------------------
From: JOHNSON@northeastern.edu ("I am only an egg.")
Newsgroups: fj.mail-lists.x-window
Subject: bandwidth use
Date: 19 Nov 92 20:11:29 GMT
Distribution: fj
Organization: Workstation Div., Supermicro Systems Group, Sony Corporation

Date: Thu, 19 Nov 1992 13:28 EST
Message-Id: <01GRC5Q3M6UO8WYEYV@northeastern.edu>
X-Envelope-To: xpert@expo.lcs.mit.edu
X-Vms-To: IN%"xpert@expo.lcs.mit.edu"
X-Vms-Cc: JOHNSON

     Hi.

     I'm looking for statistics on bandwidth use for Xwindows over 
Ethernets.  We're building a new network at Northeastern University and 
I'm tryig to plan for traffic.  We expect to be running X from pc's 
Mac's, DECstations, X terminals, etc.  Any pointers to data, people,
test programs, etc. will be VERY much appreciated. 

     I'm not on this list.  Please send replys to;

     johnson@northeasern.edu

     Thanks much.

Chris Johnson
Northeastern University.
From: rws@expo.lcs.mit.edu (Bob Scheifler)
Newsgroups: fj.mail-lists.x-window
Subject: X11R5 public fixes #18 and #19 now available on export
Date: 17 Nov 92 01:23:44 GMT
Distribution: fj
Organization: Workstation Div., Supermicro Systems Group, Sony Corporation

Date: Mon, 16 Nov 92 15:25:21 -0500
Message-Id: <9211162025.AA24920@expo.lcs.mit.edu>

Patches for a variety of problems in R5 are now available via anonymous ftp
on export.lcs.mit.edu, and the xstuff mail archive server on expo.lcs.mit.edu.

Fixes are available via anonymous ftp to export.lcs.mit.edu (18.24.0.12),
in the directory /pub/R5/fixes/.  The files for the new fixes are "fix-18",
"fix-19", and "PEXlib.tar.Z".  PEXlib.tar.Z is part of fix #19.  Instructions
for applying the fixes are included in the files.  Fixes usually propagate
to other distribution sites as well, so it may pay to check at a nearer
site first.

WARNING:
Fix #18 was previously released as an optional patch, in support of the
X Test Suite, and was labeled "Release 5 XTEST Public Patch" (the file on
expo was "/pub/XTEST/R5fix-xtest-1").  If you have already applied that patch,
do not try to apply fix-18!  Proceed instead to apply fix-19.

For those without ftp access, individual fixes can be obtained by mail by
sending a message to xstuff@expo.lcs.mit.edu (18.24.0.11).  In the usual
case, the message should have a subject line and no body, or a single-line
body and no subject.  For example, make the line:
	send fixes 18
to get fix #18, and
	send fixes 19
to get fix #19.  To obtain PEXlib.tar.Z, you need to request the individual
parts "PEXlib.uu.1", "PEXlib.uu.2", "PEXlib.uu.3", and "PEXlib.uu.4", then
concatenate them together to create a file "PEXlib.uu" and then do
	uudecode PEXlib.uu
to produce "PEXlib.tar.Z".

To get a summary of all 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.


Brief notes on what patch 18 provides:

xtest: add implementation of XTEST extension

Brief notes on what patch 19 provides:

PEXlib: add implementation of PEXlib, a new X Consortium standard
Xlib: improve extension error reporting