Kimbrough@dsg.csc.ti.COM (Kerry Kimbrough) (03/21/90)
olwm fails to obey ICCCM conventions: when a client sends a ConfigureRequest on a (reparented) top-level window, olwm does not reply with a ConfigureNotify containing the resulting top-level geometry. In the case observed, the client program is using a custom toolkit, not XView. The top-level window is a transient shell which has not set any of the olwm-specific decoration properties. Therefore, the window appears without any olwm resize controls, etc. Thus, it's possible that olwm believes that all client ConfigureRequest's should be rejected (if so, this is probably a bug). Nevertheless, ICCCM mandates that olwm must send a synthetic ConfigureNotify reporting the unchanged geometry. I'm using a stock olwm right out of the R4 box. There are probably many fixes since then. How should I go about getting them?
smarks@eng.sun.COM (Stuart W. Marks) (03/22/90)
Before I get into this, let me point out that, if you don't want to bother the entire xpert list, you can submit bug reports against olwm (or XView) by sending mail to "xviewbugs@sun.com". | olwm fails to obey ICCCM conventions: when a client sends a | ConfigureRequest on a (reparented) top-level window, olwm does not | reply with a ConfigureNotify containing the resulting top-level | geometry. Does this happen in *all* cases, or just the case you mention below? | In the case observed, the client program is using a custom toolkit, not | XView. The top-level window is a transient shell which has not set any | of the olwm-specific decoration properties. Therefore, the window | appears without any olwm resize controls, etc. Thus, it's possible that | olwm believes that all client ConfigureRequest's should be rejected (if | so, this is probably a bug). Nevertheless, ICCCM mandates that olwm must | send a synthetic ConfigureNotify reporting the unchanged geometry. I don't believe there's any code in olwm to reject ConfigureRequests on transient windows. If a window requests to be resized, olwm will just resize it (along with decorations, of course). Could it be possible that the following is happening? 1. Client issues a ConfigureWindow request on its window, requesting to be resized to the same size it is currently. 2. Server redirects this request, issuing a ConfigureRequest event to the window manager. 3. Window manager issues its own ConfigureWindow request on the client's window, expecting that the server will generate a ConfigureNotify event. 4. Because of a "feature" in the protocol, a ConfigureWindow request that is a no-op (such as this one) will not generate a ConfigureNotify event. Thus, the client receives no such event. Notice that, if no window manager is running, steps 2 and 3 are skipped, and the client doesn't receive a ConfigureNotify event anyway. Now, the ICCCM doesn't require window managers to send a synthetic ConfigureNotify event if a real one would be generated as a result of a resizing operation. But if the resize is a no-op, no such event will be generated. One might argue that olwm should detect this case and issue a synthetic ConfigureNotify if a real one won't be generated. But that seems strange, because in the no-window-manager case, the client doesn't have reason to expect one in the first place. Looking at the code again, I see a case where if the client issues a ConfigureWindow request that specifies a move and a resize simultaneously, they will both happen; but if the resize is a no-op, no event will get sent. This does seem like a bug. Is this what's happening? In any case, please send more details via private mail (smarks@eng.sun.com). | I'm using a stock olwm right out of the R4 box. There are probably many | fixes since then. How should I go about getting them? There is a fix available for FTP on expo, in contrib/XView/olwm-1.Z but it's unrelated to the issues mentioned here. s'marks Stuart W. Marks ARPA: smarks@eng.sun.com Window Systems Group UUCP: sun!smarks Sun Microsystems, Inc.