HDTenEightyP/NetNews huggingface dataset:
From: converse@expo.lcs.mit.EDU (Donna Converse)
Subject: Re: cursor in spring-loaded menu
Organization: X Consortium, MIT Laboratory for Computer Science
Date: Mon, 27 Jul 1992 23:09:56 GMT


> I have a menu widget which I have written intended to be used as a
> spring-loaded popup when a button is pressed (by means of an XtMenuPopup() in
> the translations).  While the menu is popped up I would like the cursor to have
> some special shape.  It seems to be hard to do this.

Right.

> The widget does have a cursor resource.
> It is used in the widget's realize method to set the cursor for the widget's
> window.  My problem (or complaint?) is that when the widget it is popped up
> with the XtMenuPopup action that this resource has no effect.  The cursor
> used seems to alway be that of window of the widget making the grab.  I believe
> that this is because XtMenuPopup (as far as I can figure out) makes an
> XButtonGrab with cursor of None.

You are right.

> I know that the resource is properly set because I successfully used it in
> the XChangeActivePointerGrab() call.

That's what you have to do, make a call to XChangeActivePointerGrab to get
the menu to use a cursor other than the cursor supplied by the grabbing window.

> I still don't see how I can get the behavior I want
> (the grab done with the menu's cursor rather than with the grabbing window's
> cursor) without writing my own version of the XtMenuPopup() action routine or
> by the use of XChangeActivePointerGrab().

The Xaw Simple Menu widget makes a call to XChangeActivePointerGrab in a callback
registered on the popupCallback list.  These callbacks will be called before
the menu widget is mapped, through XtPopupSpringLoaded, which is called 
through XtMenuPopup, the action you use to pop up the menu.  So, you're right,
sorry I got confused by this one.  The menu widget that you are writing would
register this callback in its Initialize method.


Donna Converse
MIT X Consortium
From: gildea@EXPO.LCS.MIT.EDU (Stephen Gildea)
Newsgroups: comp.windows.x.announce
Subject: Type 1 Rasterizer Patch available
Date: 28 Jul 92 20:56:01 GMT
Distribution: inet
Organization: X Consortium, MIT Laboratory for Computer Science

Patches for a variety of problems in the R5 contributed Type 1
(PostScript) rasterizer are now available via anonymous ftp in the
file /pub/R5/contrib-fixes/Type1.patch on export.lcs.mit.edu.
Instructions for applying the fix are included in the file.

This patch fixes the following problems in the version on
the R5 contrib tape:

fontlib: interface changes with public patch 13
Type1: fonts with character sets other than ISOLatin1 fail
Type1: t1_Unique() can dereference a null pointer
Type1: memory leaks
Type1: fails to recognize Weight object in font
Type1: NULL is undeclared in t1info.c
Type1: errors in properties computation
Type1: abort() called instead of t1_abort() in malloc
From: converse@EXPO.LCS.MIT.EDU (Donna Converse)
Newsgroups: comp.windows.x.announce
Subject: X11R5 public fix #15 now available
Date: 30 Jul 92 21:34:53 GMT
Distribution: inet
Organization: X Consortium, MIT Laboratory for Computer Science


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 file for this fix is "fix-15".
Instructions for applying the fix are included in the file.  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 (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 15
to get this 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 15 corrects the following problem:

Following fix-14, clients attempting to use XDM-AUTHORIZATION-1 or SUN-DES-1
may not connect properly to the X server.
From: dwex@mtgzfs3.att.com (David E Wexelblat)
Newsgroups: comp.windows.x.announce
Subject: Clarifications of X386 1.2E 1.0 announcement
Date: 21 Jul 92 21:41:01 GMT
Distribution: inet

This is a followup to the announcement of X386 1.2E 1.0 that was posted
on Saturday, July 18, 1992.  This is solely to clarify a few points.

1) The name of this product is X386 1.2E 1.0.  Please be very careful when
   referencing this name, so as not to confuse it with commercial products
   from SGCS (Snitily Graphics Consulting Service).  We don't really want
   to change the name at this late date, but there has been confusion,
   and if it persists, we will have to change the name.

2) This is not a product of Thomas Roell or SGCS.  Any reports of problems
   with X386 1.2E should be sent to <x386@physics.su.oz.au>.  If there is
   a reason to contact Mark or Thomas about a bug, we will do so.  But all
   reports should come to us first.

3) This is free (but copyrighted) software.  It will remain free software,
   for the forseeable future (i.e. at the very least, until X11R6 is
   released).  We will support it, and keep up to date with MIT public
   fixes.  This software, being freely available, may or may not become
   part of commercial products; we are not restricting that.  When X11R6
   rolls around, we will be working with SGCS to submit a merge of our
   software with their SVGA product to X11R6.  Depending on what the
   final outcome is, we may or may not continue this project past then
   (and no, I have no idea when X11R6 is coming, or what will be in it,
   so don't ask).

4) At this time, support for Mach386 and 386BSD 0.1 is not yet ready.
   Mach386 is reportedly close (which is why the original announcement did
   not list it as working correctly).  The release of 386BSD 0.1 caught us
   by surprise.  X386 1.2E 1.0 is up on 386BSD 0.0, but the new release
   is not yet ready, and we don't have a time table.  BSD/386 and Linux
   were reported by Beta-Testers to be ready before the announcement was
   posted.  For now, requests for support for these systems are being
   directed to the Beta-Tester who has volunteer to provide source and/or
   binary support.  We will be looking into merging support of these OS's
   into the core release, but since none of the core team is currently
   running any of these OS's, we have no way to test, so it will be a
   slow process.

5) Shared library support for SVR3 is still not present.  If anyone wants
   to volunteer to put that together, a lot of people would be grateful.

As always, all requests for information, and other communications on
X386 1.2E should be directed to <x386@physics.su.oz.au>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Wexelblat             | dwex@mtgzfs3.att.com  | Somebody get me a 
AT&T Bell Laboratories      | ...!att!mtgzfs3!dwex  |   cheeseburger!
200 Laurel Ave - 4B-421     |                       |      
Middletown, NJ  07748       | (908) 957-5871        | --Steve Miller Band
From: dwex@mtgzfs3.att.com (David E Wexelblat)
Newsgroups: comp.windows.x.announce
Subject: X386 1.2E has been updated to 1.0.1 (incorporating MIT fix-13)
Date: 24 Jul 92 15:15:13 GMT
Article-I.D.: expo.9207241515.AA04497
Distribution: inet

X386 1.2E 1.0.1 is now available.  This update incorporates the recently
released fix-13 from MIT.

[ For those who do not know, X386 1.2 is the Intel-based Unix SVGA server
  provided with X11R5.  X386 1.2E is a set of enhancements to that server. ]

The following files are available:

	X386-1.2E-1.0.1.diff.Z		Patch kit reletive to X11R5-PL13
	1.0-1.0.1.diff.Z		Patch kit for 1.0.1 relative to 1.0
					(This includes MIT's fix-13)
	Type1.patch1.Z			patch required for the Type1 font
					code to work with PL13, relative
					to the X386 1.2E Type1.tar.Z

These are available from:

	export.lcs.mit.edu (under /pub/contrib/X386-1.2E)
	ftp.physics.su.oz.au (under /pub/X386)
	ftp.win.tue.nl (under /pub/X386)

An update to the SVR4 binary distribution, containing those files that have
changed, can be found in the files core-1.0.1.tar.Z-?? on

	ftp.physics.su.oz.au (under/pub/X386/SVR4)
	ftp.win.tue.nl (under /pub/X386/SVR4)


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Wexelblat             | dwex@mtgzfs3.att.com  | Somebody get me a 
AT&T Bell Laboratories      | ...!att!mtgzfs3!dwex  |   cheeseburger!
200 Laurel Ave - 4B-421     |                       |      
Middletown, NJ  07748       | (908) 957-5871        | --Steve Miller Band
From: converse@EXPO.LCS.MIT.EDU (Donna Converse)
Newsgroups: comp.windows.x.announce
Subject: X11R5 public fix #14 now available
Date: 27 Jul 92 18:37:35 GMT
Distribution: inet
Organization: X Consortium, MIT Laboratory for Computer Science


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 file for this fix is "fix-14".
Instructions for applying the fix are included in the file.  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 (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 14
to get this 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 14 corrects the following problems:

An enhancement to Xlib for the X Consortium's Xlib and X Protocol Test Suite:
the test suite can now use the internal interface _XConnectDisplay to obtain
raw connections to the X server, thus allowing maximum portable protocol test
coverage.  In order to ensure this coverage, set XP_OPEN_DIS to XlibXtst.c
when configuring the Xlib and X Protocol Test Suite.

Xlib: IO error during connect may dereference NULL
Xlib: duplicate free() in XCloseDisplay from IO error handler
Xlib: could use better _XConnectDisplay interface for test suite
Xlib: XCloseDisplay does not free memory
Xlib: endian definition is missing when compiling XConnDis.c for OSF1
Xlib and Xt: LATIN2 keysyms are not handled correctly in ConvertCase
Xlib and Xt: Latin-3 case converter
Xt: XIM w/ keycode 0 (as defined by Xlib I18N) does not work with Xt
Xt: XtCreateWidget errs when parent is an Object, not a Widget
Xt: SetValues on TopLevelShell's iconic resource when popped_up is True
Xt: set values on iconic resource should not affect initialState
Xt: identifyWindows hack clobbers real information
Xt: frees memory returned by Xlib with Xt interface
Xt: unintentional reference inside Display structure
Xt: geometry requests with SetValues 
Xt: release of passive grab not recognized
Xt: XtOpenDisplay ignores -name when appl_name parameter is present
Xt: XtOpenDisplay should check that argv[0] isn't the empty string
Xt: XtCloseDisplay frees NULL per-display keysyms
Xext: XShmPutImage missing gc update
fonts: missing copyright for Bitstream Courier Speedo fonts
From: bobmcg@CASTLE.ED.AC.UK (Bob McGonigle)
Newsgroups: comp.windows.x.announce
Subject: Europena X User group Conference
Date: 27 Jul 92 14:05:23 GMT
Distribution: inet


EUROPEAN X USER GROUP CONFERENCE

ANNOUNCEMENT AND CALL FOR ADDITIONAL PAPERS

24-25 September 1992

Brunel University, Uxbridge, Great Britain
  (5 minutes from Heathrow)

The conference this year comprises the conference itself, a choice of
optional tutorials, a vendor exhibition and demonstrations.

TUTORIALS

The tutorials will be held on the morning of Thursday 24th September.
Four subject areas are offered:

X Window System Administration,
PEX programming,
Starting off with X, and
Debugging X Windows programs.

CONFERENCE

The conference commences at mid-day on Thursday 24th September and
continues through the whole of Friday.  It will include major speakers
from the USA such as Bob Scheifler, Donna Converse, Oliver Jones and
Doug Young.  A wide range of topics will be covered including:

GUI tools in high level languages,
fonts made easy,
X in group working, and 
Help via X Windows.

ADDITIONAL PAPERS

There is still an opportunity for you to present a paper on your
favourite subject at the conference. To contact the paper committee, you
should fax your name, address, telephone, email address and proposed
topic of paper to the secretariat. Someone will then contact you to
discuss further details.

VENDOR EXHIBITION

The exhibition will be the only one dedicated to X and exhibitors will
be showing products and services offered to the X community.

DEMONSTRATIONS

There will also be demonstrations by developers working within the X
environment, plus video presentations of various applications.

COST

The conference fee is 250 pounds.
Price includes refreshments and lunch, plus the conference dinner on the
Thursday evening.

Optional tutorial fee is 50 pounds.
Choose one of the above four subject areas.

Accommodation - 27.50 pounds per person per night.
Bed and Breakfast in en-suite rooms. Available Wed 23rd, Thur 24th and
Fri 25th September.

SPECIAL OFFER

Members of the User Group may be eligible for a 10% discount for early
registration and payment. Ask for details.

EXHIBITION STANDS

If you would like to exhibit your organisation's
products/services/research developments, please contact the secretariat.

TO BOOK

Registration forms and further information are available from:

  EXUG Secretariat
  PO Box 458
  Cambridge 
  CB4 4AA
  Great Britain

  Tel: +44 (0) 223 426534
  fax: +44 (0) 223 420251
From: jipping@CS.HOPE.EDU (Mike Jipping)
Newsgroups: comp.windows.x.announce
Subject: XVTDL 3.0 Released
Date: 29 Jul 92 13:32:29 GMT
Distribution: inet
Organization: Hope College

Release 3.0 of XVTDL, the XView ToDo List mananger, is now available
for anonymous FTP from export.lcs.mit.edu as /contrib/xvtdl-3.0.tar.Z.
The README file can be picked up from export.lcs.mit.edu as
/contrib/xvtdl-3.0-README

Thanks to all who responded to versions 2.x.  Version 3.0 has bugfixes
and new features:
   * a logging feature which allows the user to log her checked off
     items in a number of different ways.
   * a "List All" feature that allows the user to combine all lists
     into one psuedo-list -- which works like any other list (e.g., 
     one can check off items or print the combined list).
   * a button to iconify the tool and to write out the todo list
     database
   * a properties window that controls X resources and makes the tool
     user customizable.

See the CHANGES file for a list of changes from previous versions.

Thanks to those who have sent comments so far.  There is a list of
features (the file "TODO", in XVTDL format of course) that are being
planned for future releases.  I would again appreciate comments and
feedback on these (and any other comments you wish to make).

   -- Mike Jipping
      Hope College Department of Computer Science
      jipping@cs.hope.edu
From: joe@ATHENA.MIT.EDU (Joseph C Wang)
Newsgroups: comp.windows.x.announce
Subject: Tk Interface to the World Wide Web (ALPHA Release 0.1)
Date: 27 Jul 92 14:03:09 GMT
Distribution: inet

I've uploaded a very preliminary interface to World Wide Web using the
tk toolkit to export.lcs.mit.edu and the tcl archive in
barkley.berkeley.edu.

tkWWW Version 0.1 alpha (joe@athena.mit.edu)
--------------------------------------------

This a first pass at a browser for World Wide Web using the tk
library.  It is very buggy.  Use at your own risk.

The Tk browser has the following advantages.

1. Since the entire user interface is written in an interpreted 
   language, it should be very easy to make modifications and extensions
   to the system.

2. More important, it is possible to imbed Tk code into hypertext
   documents.  To see an example of this, load in the hypertext file
   file:$pwd/Tcl/text2.html


INSTALLATION
------------
In order to install tkWWW you will need

   The code for the WWW line-mode browser. (anon ftp from info.cern.ch)
   Libraries for tk and tcl (I'm using tk2.1 and tcl6.3)

   A wish intepreter which contains the Hyper and XYGraph widgets

To install this program, unpack the WWW line-mode browser source and 
cd to the directory WWW.  Unpack this tar file.
From: aw@JELLO.BAE.BELLCORE.COM (Andrew Wason)
Newsgroups: comp.windows.x.announce
Subject: Xbae 3.7
Date: 29 Jul 92 13:34:01 GMT
Distribution: inet
Organization: Bell Communications Research


Release 3.7 of Xbae (the Motif XbaeMatrix and XbaeCaption
widgets) is available at export.lcs.mit.edu:contrib/Xbae-widgets-3.7.tar.Z.
There are no new features, just a couple of small bug fixes.

A patch to bring 3.6 up to 3.7 is at
export.lcs.mit.edu:contrib/Xbae-3.6-to-3.7.patch.shar.  The patch
does _not_ patch the PostScript documents, because even though
the changes were small, the diffs were not.  If you want the
updated docs, fetch the entire 3.7 distribution.

If you can't ftp, try sending email to ftpmail@decwrl.dec.com
with the word "help" alone in your message body.  You will receive
instructions on how to ftp via email.

Xbae 3.7 fixes the following problems:

 * XbaeMatrix would occasionally steal the focus from other widgets
   in the same shell.  The Clip widget was changed to only respond
   to synthetic FocusIn events.
 * XbaeMatrix StringToAlignmentArray converter should free the array
   when the conversion fails.
 * All header files now use a more specific inclusion protection symbol
   to avoid conflicts with other packages.
 * The XbaeMatrix documentation incorrectly documented the
   XbaeMatrixLeaveCellCallbackStruct.


Andrew

_______________________________________________________________________________

Andrew Wason                                       Bell Communications Research
aw@bae.bellcore.com                                Piscataway, NJ
bellcore!bae!aw
Newsgroups: comp.windows.x
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Subject: Re: Scrolling a window....
Organization: McGill Research Centre for Intelligent Machines
Date: Thu, 30 Jul 92 01:08:54 GMT

In article <1992Jul27.003635.4498@iWarp.intel.com>, daw@iwarp.intel.com (David A. White) writes:

> [something about scrolling a window.]

> I tried using XCopyArea() to do this by first copying from the window
> to a Pixmap I created, and then copying from the Pixmap back to the
> window in a new location.  This worked fine as long as there was no
> other window on top of the window being scrolled.  However, if my
> drawingarea window was obscured, then the first XCopyArea() would not
> get the correct information so garbage would appear in the window
> when it was copied back.  I could not get GraphicsExpose events from
> this because the destination is not a window.

Hm?  GraphicsExpose events should be generated just fine, regardless of
whether the destination is a window or not.

By the way, why are you copying to a pixmap?  Why not just copy the
window to itself?  You mention you tried this...why did you feel it
necessary to do it in little increments?

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: stgprao@xing.unocal.com (Richard Ottolini)
Newsgroups: comp.windows.x
Subject: Re: X Window Security
Date: 30 Jul 92 15:43:14 GMT
Article-I.D.: unocal.1992Jul30.154314.9311
Organization: Unocal Corporation
Originator: stgprao@xing

In article <1992Jul30.124558.24089@cscs.ch> giordano@tamaro.cscs.ch (Silvia Giordano) writes:
>Hello folks.
>I would like to get your opinions and experiences about X Window
>traffic. We are receiving many requests to open X Window traffic in
>unrestricted way. The opinion of the Network&Security group at
>our Supercomputer Centre is that this represents a definite security 
>hole since X Window is not considered to be a safe product (e.g. use
>of not privileged TCP ports, weak X11R4 security design and so on).
>
>Could someone give me more info on X Window System security? I read the 
>tutorial by Dennis Sheldrick and explained the above well enough for me, 
>but I don't know any X installation filtering X access for security.
>Isn't there an X-Window technical conference on security topic? 
>Isn't there anyone having experiences with X Window System security?
>What is the policy implemented at your centre? Did you have negative
>experiences with unrestricted X Window traffic?

Basically there is no security unless you have explicitly turned it on.
It is not to hard to write a little deamon to eavesdrop on someone's xterm
session or insert keystroke events into someone's xterm.  For example,
window managers use event interception to implement their features.
I am surprised so few serious hacks have been reported so far.
From: rjc@cogsci.ed.ac.uk (Richard Caley)
Newsgroups: comp.windows.x
Subject: Shell widget and child's border width
Date: 26 Jul 92 17:14:41 GMT
Distribution: comp
Organization: Human Communication Research Center


I'm writing a widget which is used as a direct child of a top level
Shell widget. Because of what the widget does, it should be able to
have a border, however somewhere between the initialize procedure and
the Realize procedure the border width gets set to 0, I presume by
the toolkit or the shell widget. 

Is there some easy way I can stop this happening? I have tried the FM,
but it doesn't seem to be anywhere I can spot. I'd like to avoid
creating a custom Shell widget :-).

This is R4 and the Athena widgets. My code doesn't even mention the
border width except to use it to calculate things, so it probably
isn't me. 

Probably. :-)

--
rjc@cogsci.ed.ac.uk	I am barred, from the event...
				- David Bowie, `It's no Game'	
Newsgroups: comp.windows.x
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Subject: Re: Double Click in a window (Motif Drawing Area)
Keywords: Mouse Events, double click, drawing area, ButtonPress
Organization: McGill Research Centre for Intelligent Machines
Date: Fri, 24 Jul 92 18:37:23 GMT

In article <50599@dime.cs.umass.edu>, nikoulis@venice.pilgrim.umass.edu (Panos Nikoulis) writes:

> Is there a way to detect a double click mouse event in a window

Not reliably.  The protocol does not contain enough support to allow
this to be done right.  (It needs some sort of timeout event.)

> Currently, I am using time functions to make it "wait" for a time
> equal to the double click interval and detect a second ButtonPress
> after the first one (inside the Drawing Area callback).

Some toolkits/widget sets contain code that does this for you.  It'll
work as well as your code does, presumably, but will suffer from the
same basic problem: it can lose big in the presence of network hiccups
(it can fail both ways: it can mistake a double click for two single
clicks, and it can mistake two single clicks for a double click).

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu