Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!julius.cs.uiuc.edu!rpi!ispd-newsserver!ism.isc.com!ico!attc!marbru
From: marbru@attc.UUCP (Martin Brunecky)
Newsgroups: comp.windows.x
Subject: Re: Synchronizing with Xt (XtPopup).
Keywords: XtPopup Xt events Athena
Message-ID: <1010@attc.UUCP>
Date: 25 Jan 91 16:32:34 GMT
References: <1991Jan25.033150.12714@mel.dit.csiro.au>
Reply-To: marbru@auto-trol.UUCP (Martin Brunecky)
Organization: Auto-trol Technology, Denver
Lines: 84

In article <1991Jan25.033150.12714@mel.dit.csiro.au> kmy@mel.dit.csiro.au (Kid Mun Yap) writes:
>
>Does anyone know why flushing events using :
>
>while (XtAppPending(app_context))
>	XtAppProcessEvent(app_context, XtIMAll);
>
>immediately after an XtPopup(widget, ...) does not flush all the events
>associated with the widget and its descendants but does so if a delay
>is introduced in between.
>
   Unless you use an override shell, the Map request from the popup
   will be redirected to the window manager, which may take quite a
   while to wake up and respond by actually mapping the window. So
   even if you did XSync(dpy,FALSE) first, your window will NOT be
   mapped and your expose events will not arrive. 

   The only time you can be assured that your popup is UP is when the
   Expose or Visibility (if selected) events arrive. It is my belief
   that you can't even rely on MapNotify, as with reparenting window
   managers your shell window can be mapped, but if it's parent window
   is not mapped (yet) it is not on the screen.

   Now, what I do may sound a little bit crazy - but I have the same
   problem: need to assure that my popup is completely DISPLAYED
   before I go on. So my WsPopupWidget code:

   1) Checks for special, weird shells used by Motif and does what
      is appropriate for those .... ick.

   2) Calls XtRealize and computations for shell positioning, where
      necessary. Most people may not need this.

   3) Calls XtPopup
   
   4) Finds ALL the WINDOWS (windowObject, managed, mapped when managed)
      in the popped-up tree.

   5) Enters a LOOP waiting for Exposure or Visibility event on ANY
      of the windows in the tree (XCheckTypedWindowEvent()).
      Note I am using usleep() (or it's equivalend on non-Sun systems)
      between my checks to let the server get some CPU cycles.
      Also note, that since the OpenWindows 2.0 Xserver seems to require
      occasional kick-in-the-but to wake up, for this server I call 
      XSync(dpy, FALSE) on each loop (you may ask the user to move the
      mouse around instead -).

   6) I keep a counter; if I don't get any event within ... 5 sec ?
      I just give up, assuming either the Server, WM or something else
      is broken. This would result in incomplete popup - but I can't
      wait for ever.

   7) As soon as I get the FIRST exposure event, I assume my shell has
      become visible. Now I traverse my widget tree down again, and for
      each window object that is managed, mapped-when-managed, realized
      I call XtDispatchEvent with a manufactured XExpose event - thus
      forcing it's redisplay without waiting for an XExpose event for
      this particular widget to arrive.
      Note if some windows are (partially) obscured, I am displaying
      more than needed - but the server will clip it off.

   8) After I have forced the redisplay, I go into the event queue
      again, and throw away any XExpose events for windows in my tree.
      as I already caused an "exposure". Note that not ALL Exposure events
      arrived at this time, and some may be dispatched later - but
      a second redisplay will not hurt.

   All the above implies the knowledge of the Intrinsics to the level
   any Composite widget writer has to have. It does seem to solve the
   problem of Transient and other non-override shells. In fact, for
   override shells I do the same - but without waiting for exposure
   events (window gets mapped when requested), resulting in much
   speedier popup. This is something that Motif's MenuShell does (but
   in less generic way, making typical Motif assumptions about the
   widget tree layout).

   Now the ususal disclaimer. This is what *I* do. It does not neceaasy
   mean it is CORRECT or fully legiment. Any comments are wellcome.

-- 
=*= Opinions presented here are solely of my own and not those of Auto-trol =*=
Martin Brunecky                           {...}sunpeaks!auto-trol!marbru
(303) 252-2499                        (sometimes also:  marbru@auto-trol.COM )
Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404