Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!ISI.COM!tsang
From: tsang@ISI.COM (Kam C. Tsang)
Newsgroups: comp.windows.x.motif
Subject: Help with dialogs!
Message-ID: <9105240315.AA10758@phecda>
Date: 24 May 91 03:15:31 GMT
References: <9105240206.AA07282@lim1>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 29

> This is what I'd like to do:  For each dialog, I want to make sure it is not
> obscured by any of the dialogs that brought it up -- this is particularly
> important for modal dialogs, since if the dialog expecting input is obscured,
> the system is semi-deadlocked :-(

We had the same problem with modal dialogs not bahaving as advertised
in other window managers, too.  Here's what I came up with: instead of
forcing the dialog to resist being obscured, I allow the user to move
other windows on top of the dialog; even iconify it.  What I then do
to enforce the missing half of the modal behavior is that in our
event-loop, whenever I see a KeyPress or ButtonRelease event, I re-map
the dialog using XMapWindow.  Of course this means that you have to
keep a certain of info about your dialogs yourself (eg. who's up now,
which may require some sort of linked list in your case).

If you run into a sun4 somewhere with our just-released product
"xmath" running, check out the behavior.

-kam

ps. You don't want to re-map the dialog on ButtonPress, because that
    can screw up option menus in olwm.

     ----------------------------+-----------------------------
                      Kam Tsang  |  User Interface Group
           (408) 980-1590 x 275  |  Integrated Systems, Inc.
           (408) 980-0400 [Fax]  |  3620 Jay Street
                  tsang@isi.com  |  Santa Clara, CA  94054
     ----------------------------+-----------------------------