Normally I find that if I start up a program that uses X for a UI, and I kill the window, the program dies ungracefully with a fatal X error, usually along the lines of, "X connection to gigantor:0.0 broken (explicit kill or server shutdown)." Actually exactly along those lines most of the time for me, since I just copied that from my xterm here at work. However, some programs are a little more tactful about this, like emacs for instance, or xterm itself. Kudos to them. My question is, surely there must be a better way to accomplish this than just using XSetIOErrorHandler() to avoid the ugly message. In fact it's not even a solution, it's more of a hack, misusing the function--which could very well be deprecated I'm learning the X API from a book that talks about the marvels of X11R4 and how it is important to continue to write with backwards compatibility with R3. It also uses archaic C syntax that almost makes me want to keep it under glass and charge admission to people who swear by C++/Java and try to deny the fact that C is in fact the language of the gods and that this book is one of the "old testements" to the way things used to be. I digress. emacs even has a handy popup if you attempt to kill a window in which a buffer has been changed. xterm just goes away when the window is closed. I'm guessing (as a beginner X programmer, mind you) that this is being handled by some kind of an event handler? But that didn't get me very far, as I told CreateWindow that I wanted to receive the events that I thought were being generated but alas, I came up empty. Can anyone clue me in?

Why don't you take a look at some sourcecode from any of those apps? They're all open source, and then maybe you'll find out how they did it. Sorry if this isn't much of a help, but I've never used X directly to create a window. And as for your book, it does indeed sound deprecated, and you should try and find some other source of knowledge.

I've already ordered a new book and while looking at source is a good idea I'll have to wait a few hours to get hom to do that, as at work it's all Solaris and the source to nothing is handy, short the projects I'm working on which are not even using X.

I don't have much experience in this area (someone correct me if i'm wrong), but have you thought about catching signals such as SIGTERM using sigaction()? Also check out its man page.

Also here's a bit more info from wikipedia on killing an app.

Though I suspect that using signals throws out portability to a non unix-like OS.

Well, I don't think it's a signal that actually causes the failure, it's an internal X error that the client catches noticing that the connection with the server has been severed. I know (at least I've noticed) in X you can close windows and then you can just outright obliterate them, usually through the window manager. I think the former is in some way identifiable in the code (as I've said, some programs catch on fine and work with it) although I haven't tried it I'm willing to believe the latter is going to catch almost any program off guard and crash it. The problem is identifying the two. There's probably an event I'm not subscribing to or something of that matter, I'm still getting my feet wet with X. I'll find this problem and I'll destroy it.

But we're going to need a bigger boat.

Quote: Original message from Omaha:
Well, I don't think it's a signal that actually causes the failure, it's an internal X error that the client catches noticing that the connection with the server has been severed.

maybe, but I'm sure that the SIGTERM gets sent to the application, anyway... what you could do is catch the SIGTERM and disconnect from the X Server, along with performing some cleanup before exiting, then you might avoid the error message.

Quote: also by Omaha:
I know (at least I've noticed) in X you can close windows and then you can just outright obliterate them, usually through the window manager. I think the former is in some way identifiable in the code (as I've said, some programs catch on fine and work with it) although I haven't tried it I'm willing to believe the latter is going to catch almost any program off guard and crash it.

Catching the SIGTERM or SIGKILL or SIGQUIT signals is the common way for *nix applications to know that it's time to shut down, and it gives them a last-minute chance to clean things up and die gracefully.

There's also the DestroyNotify event type (found in X11/X.h)... you could also send a message to the XServer indicating that you want to know about those events (you might already be doing this?)

Of course, what actually happens when a user clicks on the [close] button in an X window is entirely up to the window manager... since the window manager owns the framing windows for the title bar and borders, and it's in charge of sending signals and events to the reparented client window when the user interacts with the title bar or borders.

EDIT: I just checked the WindowMaker, lwm, and hackedbox wm sources... the first two use XDestroyWindow when closing out a client window, and I couldn't immediately tell where hackedbox does its client management (as far as closing its windows).

So, try telling the XServer that you want to know about DestroyNotify type events and maybe then you'll be able to disconnect from X gracefully.

[Edited by - void* on July 8, 2005 8:30:40 PM]