smarks@eng.sun.COM (Stuart W. Marks) (03/20/90)
| Is there a solution to the problem of not receiving keyboard events in an | overrideShell popup under olwm (X11R4, Fixes 1-6, Sun4/110, SunOS 4.0.3)? | | I have written an application using the Athena widgets and the toolkit | intrinsics which does set the input resource to true using the XtSetArgs | mechanism when creating the popup, and which works correctly with each of the | other five choices of window manager available under R4, but which refuses | to accept keyboard events under olwm. I note that there has been no response | to Jim Frost's similar question posted 2-March to comp.windows.x. Perhaps | there IS no solution, but could someone in the know please respond? This is yet another one of those phenomena that works by coincidence most of the time, but which isn't guaranteed to work all of the time. The problem is that under many window managers, including the "other five" window managers available from MIT, the input focus mode is usually (but not always) in PointerRoot. This mode lets keystrokes fall to whatever window is under the pointer, like your overrideShell popup. Olwm maintains tighter control over the input focus, rather than using PointerRoot mode. The problem is that you create an overrideShell widget, which is by definition *not* managed by the window manager. Since the window manager manages the input focus, you can't get keyboard input. Setting the XtNinput resource to True doesn't help, because all that does is tell the window manager that the window wants the input focus. This doesn't help if the window manager isn't managing the window in the first place. Olwm isn't alone in this regard. DEC's window manager, dxwm, will also exhibit this behavior. You can also set up twm to show this problem. Try using twm's f.focus function to move your input focus around. You'll find that it will be unable to direct the input focus to your overrideShell widget. So, that's the background. What's the solution? Either manage the input focus yourself (sort of), or let the window manager do it. If you insist on using an overrideShell popup, you must do something drastic like grabbing the keyboard while the popup is up. This is pretty antisocial, though; the user won't be able to type anywhere else while your popup is active. Do you really want that? I would suggest that you use a transientShell popup instead. This lets the window manager manage the window and the focus. Many window managers will provide less decoration for transientShell popups than for regular windows. For instance, olwm will provide a border but no title bar for transient windows. s'marks -- Stuart W. Marks ARPA: smarks@eng.sun.com Window Systems Group UUCP: sun!smarks Sun Microsystems, Inc.
jimf%saber@HARVARD.HARVARD.EDU (03/21/90)
|I would suggest that you use a transientShell popup instead. [...] |Many window managers will |provide less decoration for transientShell popups than for regular windows. |For instance, olwm will provide a border but no title bar for transient |windows. Sure, and many window managers (the ever popular twm for instance) ignore the hint and fully decorate the window and -- much worse for transients -- force the user to place the window, which is kind of stupid since most transients are confirm dialogs which only want a yes or no click before they go away. My conclusion is that there's a documented way to accomplish transients but that method is useless in practice because many common window managers ignore it, leaving the applications writer no alternative but to use an override redirect window, a nastyism that I would prefer to avoid. As I told someone yesterday, "do you want to know the 'right' way that doesn't work or the 'wrong' way that does?". jim frost saber software jimf@saber.com
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (03/21/90)
> Sure, and many window managers (the ever popular twm for instance) > ignore the hint and fully decorate the window. Side note: Twm doesn't decorate my transiets, I also believe that you have to explicitly ask it to do so with the DecorateTransients option. Yes, but this is a matter of user choice. If the user for some reason believes that this is what a window manager should do, then there is nothing that stops him from buying a window manager that does this for him. Attempting to subvert this is bad programming, and anti-social :-) > ...much worse for transients -- force the user to place the window, which is > kind of stupid since most transients are confirm dialogs which only want a yes > or no click before they go away. Agreed, this is bad, but I have yet to have a window manager actually do this to me. This is not reason enough to use OverrideRedirect windows, there are better ways of working around this problem. For example, you can set the USSize and USPosition hints, while this is the wrong thing to do, it should have no effect on a transient window anyway since its behavior should be to place the window where the program wants it. > My conclusion is that there's a documented way to accomplish > transients but that method is useless in practice because many common > window managers ignore it, leaving the applications writer no > alternative but to use an override redirect window... Wrong. This is just the wrong thing to do. Some users actually want their transients decorated since they want to be able tot move them around, and resize them. Example: A user has selected load-file in a Text editor, and you have just popped up a dialog window asking him if he is really wants to remove all changes. The dialog is most likely over the text window, so the user wants to move it out of the way, while he checks to see of he can destroy the buffer. If you had coded this with an OverrideRedirect window the user may very well be unable to move that window. "a nastyism that I would prefer to avoid." :-) :-) > As I told someone yesterday, "do you want to > know the 'right' way that doesn't work or the 'wrong' way that does?". We are dealing with conventions here and good programs should follow them. If window managers to things right, and clients do things right then everyone will win. If application writers try to second guess the window manager, or work around buggy implementations then they will only enforce the poor behavior that we are currently seeing because everyone is not playing by the rules. Solution number 1: Ship twm with your product :-) Chris D. Peterson MIT X Consortium Net: kit@expo.lcs.mit.edu Phone: (617) 253 - 9608 Address: MIT - Room NE43-213
csvsj@garnet.berkeley.edu (Steve Jacobson) (03/21/90)
In article <9003201645.AA10445@armory> jimf%saber@HARVARD.HARVARD.EDU writes: >|I would suggest that you use a transientShell popup instead. [...] >|Many window managers will >|provide less decoration for transientShell popups than for regular windows. >|For instance, olwm will provide a border but no title bar for transient >|windows. > >Sure, and many window managers (the ever popular twm for instance) >ignore the hint and fully decorate the window and -- much worse for >transients -- force the user to place the window, which is kind of >stupid since most transients are confirm dialogs which only want a yes >or no click before they go away. > >My conclusion is that there's a documented way to accomplish >transients but that method is useless in practice because many common >window managers ignore it, leaving the applications writer no >alternative but to use an override redirect window, a nastyism that I >would prefer to avoid. As I told someone yesterday, "do you want to >know the 'right' way that doesn't work or the 'wrong' way that does?". > >jim frost >saber software >jimf@saber.com Please specify your environment. The R4 twm treats a transient shell created with XtCreatePopupShell() the way one would hope it would - no title bar at all, and if the program sets the XtNx and XtNy resources, it will pop it up where you want it to. And, since in R4, XtGetValues() works correctly for the XtNx and XtNy resources, you can pop up the transient window at a location relative to another frame, even if the user moves the frame somewhere different from where it originally popped up. The only down side to using transient windows is when you would prefer that the server be grabbed. We've had problems with users running window managers that are set to raise windows on entry. The dialog window pops up, the user lets the mouse wander a bit, and lo, the tiny dialog window is now completely hidden behind some larger window and you have to start iconyfying left and right until you can find it. I agree with Jim's opinion that there are problems using Xt when you want a transient confirm window that includes a widget that wants to see keyboard input.
toml@ninja.solbourne.com (Tom LaStrange) (03/21/90)
In article <9003201645.AA10445@armory>, jimf%saber@HARVARD.HARVARD.EDU writes: > Sure, and many window managers (the ever popular twm for instance) > ignore the hint and fully decorate the window and -- much worse for Do you have DecorateTransients someplace in you .twmrc? > transients -- force the user to place the window, which is kind of > stupid since most transients are confirm dialogs which only want a yes > or no click before they go away. I would think this is a bug. It used to work, is that good enough? :-) -- Tom LaStrange Solbourne Computer Inc. ARPA: toml@Solbourne.COM 1900 Pike Rd. UUCP: ...!{boulder,sun}!stan!toml Longmont, CO 80501