Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ico!auto-trol!marbru
From: marbru@auto-trol.UUCP (Martin Brunecky)
Newsgroups: comp.windows.x
Subject: Re: Motif and "work-in-progress"
Message-ID: <725@auto-trol.UUCP>
Date: 6 Feb 90 16:10:15 GMT
References: <9002052045.AA16268@osf.osf.org>
Reply-To: marbru@auto-trol.UUCP (Martin Brunecky)
Organization: Auto-trol Technology, Denver
Lines: 45

In article <9002052045.AA16268@osf.osf.org> vania@osf.ORG (Vania Joloboff) writes:
>
>"mike%snowhite.cis.uoguelph.ca@mitvma.mit.edu" submitted a while ago a
>problem with OSF/Motif "work-in-progress" widget.  When the work in
>progress takes too many cycles, the dialog box don't get the expose
>necessary to tell the user there is work in progress...
>
>Here follows a work around proposed by Bill Wilhelmi from HP,
>Thanks Bill.
>
	.... code deleted ....

Using a focus event is fine, especially since Motif widgets have a callback
for it - but using map event would be more generic, i.e. would work even
for widgets which do NOT take intput focus. 

I am not 100% sure what the X protocol says about expose event order, but
I tend to beleve that expose event for subwindows will FOLLOW the one for
the parent window. 
Thus, waiting for the focus (or map) and expose event on the main widget
will NOT be enough - it's children's events will still be in a queue.
This may not be visible where Gadgets are used (Gadgets are repainted
on parent's expose), but definitly will cause troubles in case of subwindows
- such as "real" widgets.

Toolkits like Motif should provide something like "XmForceDisplay" routine,
using techniques similar to Motif MenuShell (but in a generic fashion):
	- popup the shell (and PLEASE, don't replace XtPopup by XtManage...)
	- XSync or some wait for map event on the shell
	  (no wait on OverrideShell, wait for WM action on others)
	- traverse the widget tree starting with shell, 
	  calling "expose" method for each WindowObject with
	  an artificial expose event/region to force redisplay
	- remove expose events for all windows touched above
	  to avoid double repaint.

To do everything correctly requires more code and XtIntrinsic internals
knowledge than appropriate for application code - therefore it should
be a part of the toolkit.
 
-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Martin Brunecky                   marbru@auto-trol.COM
(303) 252-2499                    {...}ncar!ico!auto-trol!marbru
Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404