Motif & Gnome, destroy option

Motif & Gnome, destroy option

Post by DVik » Wed, 22 Feb 2006 20:53:37

I have an application written in XMotif. It works fine under most of
the window Managers like the CDE of Solaris. I recently start testing
my application in Gnome (usually remote login and running it under
Gnome terminal).

I 've noticed the system menus in the widgets has two options Delete &
Destroy. Delete is trapped by my motif code calling my callbacks and
works fine. However, Destroy it isn't. It kiils one of the many windows
without the application been notified and leaving it in a misserable

How can I trap Gnome Destroy signal via Motif calls? To maintain my WM
independance do not want to include Gnome specific code. Also is any
programatic way to deactive Destroy?

Any help much appreciated.

Motif & Gnome, destroy option

Post by nojun » Thu, 23 Feb 2006 02:10:03

The "delete" option sends a client message to your application. Motif
handles these events for you. Destroy forces the X server to close the
connection with the client, so it dies due to an I/O error.

You must install an error handler by means of XtAppSetErrorHandler.
This will work with any desktop environment and even if you use xkill,
the merciless X terminator.

--- Casantos


Motif & Gnome, destroy option

Post by DVik » Wed, 01 Mar 2006 18:46:17

Well, I 've tried to register an error handler using
XtAppSetErrorHandler or even XtAppSetWarningHandler. I even used the
Xlib functions XSetIOErrorHandler and XSetErrorHandler. Unfortunately
when I picked the destroy option none of my error handlers was called.
Parhaps might have to do with the fact that I am running an Sun solaris
application via a remote terminal in a Linux machine.

Any more ideas how to trap that Destroy?

Motif & Gnome, destroy option

Post by nojun » Fri, 03 Mar 2006 01:45:57

Are destroying the application window or the termnal window?

Does your program shows a message like "X connection to :0.0 broken
(explicit kill or server shutdown)."?

--- Casantos

Motif & Gnome, destroy option

Post by ST » Fri, 03 Mar 2006 02:13:46

Even if you do fix it, it's likely to be an arms race. After all,
someone can kill -9 your application and there's no way you can trap that.

I'd see if there's a way to structure things so you app is more tolerant
of unexpected shutdowns, or at least remove those tempting buttons from
the window manager UI.

Motif & Gnome, destroy option

Post by nojun » Fri, 03 Mar 2006 06:17:41

Sorry, my mistake. You must set an X I/O ehhor handler to catch display
disconnections. The following code contains an example:

static int myXErrorHandler(Display *display, XErrorEvent *ev)
char buffer[BUFSIZ];
XGetErrorText(display, ev->error_code, buffer, BUFSIZ);
fprintf(stderr, "X error: %s\n", buffer);
return 0; /* die */

static int myXIOErrorHandler(Display *display)
fprintf(stderr, "X I/O error\n");
return 0; /* die */

static void myXtErrorHandler(String msg)
fprintf(stderr, "Xt error: %s\n", msg);

int main(int argc, char **argv)
XtAppContext app_context;
Widget toplevel, button;

toplevel = XtAppInitialize(&app_context, "XmTest", NULL, 0,
&argc, argv, NULL, NULL, 0);

XtAppSetErrorHandler(app_context, myXtErrorHandler);
button = XmCreatePushButton(toplevel, "button", NULL, 0);

return 0;

You can not use any display service in your I/O error handler
(the connection is probably lost, anyway). Of course nothing
prevents you from trying to open a new connection to show
an error message or a dialog. My preference, however, would
be to shut down the application ass soon as possible.

Be warned that your program will be terminated when one of
the X error handlers returns. I don't know why the functions
must return an int value. Xlib apparently does not use it for
any purpose. I guess it is a legacy from K&R C when the "void"
return type did not exist.

--- Casantos

Motif & Gnome, destroy option

Post by DVik » Tue, 07 Mar 2006 18:55:08

Well, I 've tried all these and still haven't shorted my problem. I
suspect that the reason is that the application is rather passive
expecting from the UI an event. I am not sure that it tries to check if
the UI is still there and running thus never gets an I/O error to kick
the hanlders. Do you know who will sent that error? Will the Gnome
Destroy option sent such error to the application?

To remove those options will be ideal. But my problem is that I am
running via terminal a solaris application in a Linux Gnome Machine. I
use rlogin to log into the Sun machine and then set the DISPLAY
environment variable to get the correct terminal. The destroy option
comes from the Window system menu that Gnome provides and I figured out
that differs among window managers. Thus, any idea how to do that. My
original libraries in Solaris does not include any Gnome specific code.