Motif & Gnome, destroy option - Motif

This is a discussion on Motif & Gnome, destroy option - Motif ; 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 ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Motif & Gnome, destroy option

  1. Motif & Gnome, destroy option

    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
    state.

    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.


  2. Re: Motif & Gnome, destroy option


    DVik wrote:
    > [...] 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
    > state.
    >
    > How can I trap Gnome Destroy signal via Motif calls?


    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


  3. Re: Motif & Gnome, destroy option

    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?


  4. Re: Motif & Gnome, destroy option


    DVik wrote:
    > 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.


    Are destroying the application window or the termnal window?

    > Any more ideas how to trap that Destroy?


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

    --- Casantos


  5. Re: Motif & Gnome, destroy option

    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.

  6. Re: Motif & Gnome, destroy option


    DVik wrote:

    > 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.


    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);
    exit(0);
    }

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

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

    XSetErrorHandler(myXErrorHandler);
    XSetIOErrorHandler(myXIOErrorHandler);
    XtAppSetErrorHandler(app_context, myXtErrorHandler);
    button = XmCreatePushButton(toplevel, "button", NULL, 0);
    XtManageChild(button);
    XtRealizeWidget(toplevel);
    XtAppMainLoop(app_context);

    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


  7. Re: Motif & Gnome, destroy option

    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.


+ Reply to Thread