Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!ames!ucbcad!ucbvax!decvax!gancarz
From: gancarz@decvax.UUCP (Mike Gancarz)
Newsgroups: comp.windows.x
Subject: Re: Killing X-windows
Message-ID: <133@decvax.UUCP>
Date: Thu, 20-Aug-87 09:14:06 EDT
Article-I.D.: decvax.133
Posted: Thu Aug 20 09:14:06 1987
Date-Received: Sat, 22-Aug-87 10:05:52 EDT
Reply-To: comp.windows.x
Followup-To: comp.windows.x
Distribution: world
Organization: Ultrix Engineering Group, Digital Equipment Corp.
Lines: 24
Keywords: kill maim xdestroy
Summary: Breaking windows doesn't kill them.

Rick.Busdiecker@H.GP.CS.CMU.EDU writes:
>I put "xdestroy &" on a menu item, where xdestroy is a program which
>written by David C. Martin, UC Berkeley that grabs the mouse with a
>bulls-eye cursor and destroys the window that you click on.

Just destroying a window doesn't do the trick.  The client attached to
it won't exit until it gets an error from the server when it tries to
write to the window.  Unfortunately, some clients (xterm, e.g.) do
nothing until the user initiates some input in the window.  If the window
is gone, then there's no way to force the client to get a write error.
Eventually this leads to the familiar 'no more processes" message.

What you really want to do here is kill the process behind the window.
This is a bit tougher, because the process may be on a remote machine
(possibly in another state) and it may not even be a U*IX process.  This
leads to all sorts of creative solutions, none of which I'm comfortable
with.

Thinking back, I seem to recall some bright young upstart who came to me
with a wonderful new "f.destroy" function that he added to uwm.  He never
did figure out why he had problems creating new xterms around 4:00 every
afternoon.

--Mike