Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!usc!ucsd!ucsdhub!hp-sdd!hp-pcd!hpcvlx!gabe
From: gabe@hpcvlx.cv.hp.com (Gabe Begeddov)
Newsgroups: comp.windows.x
Subject: Re: WM for Motif or is R4 twm ICCCM compliant
Message-ID: <100920168@hpcvlx.cv.hp.com>
Date: 15 Feb 90 22:53:22 GMT
References: <1061@esatst.yc.estec.nl>
Organization: Hewlett-Packard Co., Corvallis, OR, USA
Lines: 56


   / hpcvlx:comp.windows.x / toml@ninja.Solbourne.COM (Tom LaStrange) /  3:27 pm  Feb 14, 1990 /
   > 1) The manual specifies that  Dialogs should always be iconified
   >    together with the toplevel window for the application. This does
   >    not work when using R4 twm but (of course) when I use the Motif
   >    windowmanager mwm.
   > 
   > 
   > Why is this so? I can think of two reasons:
   > 
   > - Motif is designed to always require mwm. And mwm does more than what
   >   is required by the ICCCM standard.
   
   There is nothing in the ICCCM (at least that I could find) that says
   that a transient should be removed from the display when the
   transient_for window is iconified.  Motif and mwm decided that this was
   reasonable behavior, and I tend to agree with them even though it is
   not spelled out in the ICCCM.  And it's not just transient stuff either,
   both Motif and Open Look specify a private protocol that their clients and
   their window managers understand.

There doesn't seem to be anything about window_group being the basis for 
iconification either. At least not explicitly. In R3 Xt the window_group 
resource (if shell) was used to set both the window_group field in WM_HINTS
and the transient_for (if the window was a transient). 
   
As I said in response to the original posting (that this seems to be rehashing),
I think the problem here is the ordering of creation/realization of the 
dialogs versus the toplevel. If that is the case then the fault is neither
on twm, mwm, or the motif toolkit but rather the logic in the shell widget 
which is part of the intrinsics. This logic does a one shot setting of the 
window_group and transient_for values (which are both window ids) without 
waiting for the associated window to be realized. Motif 1.0 worked around this
for the transient_for setting (since this is the one we use) and did not
provide corrolary logic for the window_group. This can be construed as being
non-ICCCM compliant, but the intent is to be ICCCM compliant and gracefully
degrade in functionality when Mwm isn't present. When I brought this problem
of realization ordering up during the R4 Xt design, it was not considered
that this was a design flaw. The 1.1 motif toolkit will work around this for
both window_group and transient_for.

The reason we have a private protocol for input mode is both historical (mwm
was already doing it), and human factors. Since Xt doesn't use the X focus to
implement modality, you need a way to inform the window manager of what 
hierarchies in the application are actually in the modal set so that it can
provide visual feedback on the frames. We went too far in 1.0 by placing all
of the burden of modality management on Mwm, since it needed to know about
it anyway. In addition, we only supported PM modal settings rather than
also providing the Xt settings. 

We will be providing more toolkit modality support in 1.1 in order to both fix
bugs with latency of Mwm setting the X focus to the new window and in order
to provide full motif functionality (if not visual feedback) when running
with other window managers.

Gabe Beged-Dov