luke@umnstat.uucp (Luke Tierney) (10/12/90)
[I tried to send this out earlier but am not sure I succeeded. I apologize if this reaches you twice] I have been attempting to make an application I am developing ICCCM compliant. I thought I had more or less managed to do so, but I have run into a problem when running the application under the DEC dxwm window manager (ULTRIX 4.0 on a DECstation 3100). I am writing this note in the hope that someone who understands ICCCM can perhaps point out where I am going wrong. The application I am writing can, for present purposes at least, be thought of a tool for prototyping a graphical user interface. The program is designed to run as an interpreter in a standard tty window, such as an xterm. Typing an expression like (get-string-dialog "Enter a string") should pop up a modal dialog with an editable text field, an OK and a Cancel button. To implement this setup I use the following approach: I set up an unmapped window as a group leader in the ICCCM sense. I then construct dialogs as transients for the group leader. This seems to work fine under R4 twm and the olwm in R4. It does not work under dxwm: the dxwm window manager refuses to allow the transients to be mapped unless the leader is mapped as well. The ICCCM does not seem deal explicitly with this setting. It does state that group leaders do not need to be mapped. I think it allows window managers to unmap transients for iconified windows, but it seems to indicate that a window that is never mapped is supposed to be considered to be withdrawn, not iconified. So here are my questions: 1) is the dxwm behavior consistent with ICCCM in this respect? 2) Is there some other way I should be setting up these dialogs? One alternative approach that does not work is to use override redirect and grab the pointer and keyboard. This does not work for two reasons: if you mess up and forget to put a quit button in a dialog you freeze your display this approach does not guarantee you access to typed text directed at text fields (at least not from my reading of the ICCCM on this) I have also tried making the dialogs transients for the root window. It is not clear to me whether this should work under ICCCM or not. It does work with the twm and olwm versions from R4, but not with dxwm. This may be related to the fact that dxwm seems to use a pseudo-root. Any help or advice on this would be greatly appreciated. Luke Tierney luke@umnstat.stat.umn.edu
asente@adobe.com (Paul Asente) (10/13/90)
In article <1990Oct12.125837.22738@cs.umn.edu> luke@umnstat.stat.umn.edu (Luke Tierney) writes: >I have been attempting to make an application I am developing ICCCM >compliant. I thought I had more or less managed to do so, but I have >run into a problem when running the application under the DEC dxwm >window manager (ULTRIX 4.0 on a DECstation 3100). ... >So here are my questions: > 1) is the dxwm behavior consistent with ICCCM in this respect? dxwm is not at all consistent with the ICCCM. Its implementation predates the ICCCM and it hasn't been fully updated. If you want an ICCCM window manager, you'll have to use something else. -paul asente New address! asente@adobe.com ...decwrl!adobe!asente
dshr@eng.sun.COM (David Rosenthal) (10/16/90)
> I set up an unmapped window as a group leader in the ICCCM sense. > > I then construct dialogs as transients for the group leader. > Windows which are transients-for a never-mapped window are likely not to work right under many window managers. You are confusing two mechanisms. Transient-for is for popup dialogs. Window groups are to allow the window manager to operate on a group of related permanent top-level windows. > The ICCCM does not seem deal explicitly with this setting. It does > state that group leaders do not need to be mapped. Correct - Section 4.1.2.4. > I think it allows > window managers to unmap transients for iconified windows, Whether transient-for windows are unmapped when the window they are transient-for is unmapped is a user interface policy decision that different window managers will implement differently. But that isn't what is happening in your case. The window they are transient-for is withdrawn, not iconified. And it never changes state, so there is nothing to trigger the window manager to change the state of the transients. > but it > seems to indicate that a window that is never mapped is supposed to be > considered to be withdrawn, not iconified. > Correct - Section 4.1.4. > 1) is the dxwm behavior consistent with ICCCM in this respect? > I don't think that your program is behaving in a way anticipated by the ICCCM, so it is hard to say what the window manager should do. > 2) Is there some other way I should be setting up these dialogs? > Forget groups. Your application needs at least one real top-level window for which the pop-ups can be transient-for. I would suggest that this should be a window into which the user types your language. > One alternative approach that does not work is to use override > redirect and grab the pointer and keyboard. This does not work for two > reasons: > And as well as not working it violates the ICCCM - Section 4.2.2. > > I have also tried making the dialogs transients for the root window. This again is not anticipated by the ICCCM and is unlikely to work. The root window cannot change state, so there can be no triggers for the window manager to change the state of the pop-ups. David.