Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!osf.org!dbrooks
From: dbrooks@osf.org
Newsgroups: comp.windows.x.motif
Subject: Re: XmUpdateDisplay - the little engine that couldn't?
Message-ID: <9106261850.AA19628@osf.osf.org>
Date: 26 Jun 91 18:50:21 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 98

I just got back from vacation (11 days with a youth orchestra in 11 cities in
Europe; clearly some strange new meaning of the word "vacation") so apologies
for joining in too late.

As Gabe suggested, the problem of a dialog not displaying before the client
goes "busy" is a kind of race.  The server tells the client that its request to
map a window has been honored; unfortunately, in this case, this means only
that the request has been sent on to the (reparenting) window manager.  The wm
is now at liberty to yawn, scratch, thrash the paging disk a little, decorate
the window, walk the dog, pay its bills, and finally map the entire decorated
concoction (whereupon the server will yawn, scratch -- etc).

There is one problem with solutions like the two posted.  We know from a
separate, recent thread, that it's possible to "pop-up" a dialog from an
iconified main window, and it will then not be actually mapped.  I think the
following works a little better.  It may be over-general for your requirement;
note in particular it climbs a tree to find shell widgets, and the chances are
you already know these.

It doesn't work with olwm, as noted.  This isn't deliberate OSF policy ;-)
It's just because olwm has a different approach to transient children of
iconified parents.  It could be made to work.

David Brooks
Systems Engineering
Open Software Foundation

/*
 * This procedure will ensure that, if a dialog window is being mapped,
 * its contents become visible before returning.  It is intended to be
 * used just before a bout of computing that doesn't service the display.
 * You should still call XmUpdateDisplay() at intervals during this
 * computing if possible.
 *
 * The monitoring of window states is necessary because attempts to map
 * the dialog are redirected to the window manager (if there is one) and
 * this introduces a significant delay before the window is actually mapped
 * and exposed.  This code works under mwm, twm, uwm, and no-wm.  It
 * doesn't work with olwm if the mainwindow is iconified.
 *
 * The argument to ForceDialog is any widget in the dialog (often it
 * will be the BulletinBoard child of a DialogShell).
 */

ForceDialog(w)
     Widget w;
{
  Widget diashell, topshell;
  Window diawindow, topwindow;
  Display *dpy;
  XWindowAttributes xwa;
  XEvent event;
  XtAppContext cxt;

/* Locate the shell we are interested in */

  for (diashell = w;
       !XtIsShell(diashell);
       diashell = XtParent(diashell))
    ;

/* Locate its primary window's shell (which may be the same) */

  for (topshell = diashell;
       !XtIsTopLevelShell(topshell);
       topshell = XtParent(topshell))
    ;

  if (XtIsRealized(diashell) && XtIsRealized(topshell)) {
    dpy = XtDisplay(topshell);
    diawindow = XtWindow(diashell);
    topwindow = XtWindow(topshell);
    cxt = XtWidgetToApplicationContext(diashell);

/* Wait for the dialog to be mapped.  It's guaranteed to become so unless... */

    while (XGetWindowAttributes(dpy, diawindow, &xwa),
	   xwa.map_state != IsViewable) {

/* ...if the primary is (or becomes) unviewable or unmapped, it's
   probably iconified, and nothing will happen. */

      if (XGetWindowAttributes(dpy, topwindow, &xwa),
	  xwa.map_state != IsViewable)
	break;

/* At this stage, we are guaranteed there will be an event of some kind.
   BEWARE; we are presumably in a callback, so this can recurse. */

      XtAppNextEvent(cxt, &event);
      XtDispatchEvent(&event);
    }
  }

/* The next XSync() will get an expose event if the dialog was unmapped. */

  XmUpdateDisplay(topshell);
}