Tekwm The Tektronix Window Manager Bug Status Public Domain Release Glenn Widener Tektronix, Inc. November 22, 1989 The following is a list of known bugs, with Tek "XWS" bug tracking numbers where they have been encountered by someone other than the author, and bug priorities noted at the end of the description. (1=crash, 2=serious, no workaround, 3=serious with workaround, or in minor feature, 4=minor, 5=enhancement). XWS00526 If a decorated window is undecorated, resize, etc, is screwed because it is based on the awi->attrs regardless of whether the window is currently reparented. 3 XWS00527 Certain tekwm ops don't always stop at the exact button release position. If you do a moveOpaque, and release the button while moving the mouse, the window ends up at a position reached after the button is released. This is a "timing bug" in the way that "tekwm" (window manager) handles the motion vs button activity. tekwm does a "queryposition" rather than getting the next position from the event queue.... so it can end up moving after the button up transition. Need to either dispense with QueryPointer and use Motion Events (best), or else place the window at the button release location on completion. (uwm's approach). 3 XWS00528 Race condition between client window changes and tekwm button presses. In my 'xuserclients' I put up a window that overlaps the console window. Usually I've manually collapsed the console window before the new window gets a chance to map. This time, however, I clicked in the title bar of the console window just as the new window was mapping. Tekwm grabbed the mouse event, and I suspect did an X call to find out where it was, found the newly mapped window, and collapsed it instead of the other window (the new one doesn't have a title bar). Two possible solutions - make sure the click was from a known title bar (easy), or get the window data from the keyclick event (better). Tekwm does a TranslateCoordinates to find the top-level window when the button is pressed in a client's subwindow. So yes, the problem you see can happen. 3 --------------------------------------------------------------------- Level 4 --------------------------------------------------------------------- XWS00148 When icon is drug off-screen, text is not redrawn. Need to process expose events as they occur. 4 - uwm fix? XWS00523 autoRaise should be suppressed when the tekwm menu is up. Actually, this is a general problem - it shows up with xterm windows. So instead of raising a window to the top, tekwm should raise above the highest non-override-redirect non-TRANSIENT_FOR window, so that popup windows are ignored. Also, f.raiseandlower should ignore popup menus (i.e. override-redirect and tekwm menus) when computing whether to raise or lower. 4 raiseandlower fails to lower window if not highest window and partially off-screen. 4 XWS00522 f.restart complains that gadgets are redefined and aborts wm (if -f option used? Is it re-reading the wrong file?). < I blew it here. FIXED. Actually, this problem is eliminated if resetgadgets is given. Jordan's fix left the complaint, but allowed awm to continue. It should not complain since it does not complain about menus or bindings. It should take the new definition. You should not have to rebind a gadget to redefine it. 4 XWS00530 If autoraise is on, and icon is drug around the screen, even if the idon is not redrawn, it is several seconds after release before tekwm will respond to another button press. Apparently, it gets clogged up with motion events. Either speed up event loop, or turn motion off? 4 XWS00531 If mouse moves off window on which button was pressed, wrong window is used. Make functions on button up use the button press context window and position. Prevents problems with erratic operation if button is released off of item, but means that you never press button, drag to item of interest, and release. Also needed to fully fix problem with button release in client window losing the next button input. 4 XWS00532 Chorded buttons cancel function, but button goes to client. If another button is pressed while a DownFunction (Resize, Move, etc.) is active, the function is cancelled, but not all button releases are absorbed. 4 XWS00533 If a mouse button is held down on root while tekwm is starting up, RootWindow fails to be registered! 4 XWS00534 If frameFocus is off, initial focus window does not get highlighted at tekwm startup. 4 XWS00535 f.decorate fails if the window is initially undecorated at tekwm startup. 4 XWS00536 With frameFocus=off, client colormap should still be installed when the cursor enters the title. 4 XWS00537 If Wm.gadgets is on and wm_options.gadgets is off, the title height still allows for the gadgets. 4 XWS00308 Warp on Raise does not work. (Not verified.) 4 XWS00539 Window position is not always recovered exactly at tekwm startup. If a window is placed at ur or ll corner (-geom -0+0 or +0-0), when tekwm is killed and restarted, the window moves to the right or down 6 pixels for a borderWidth of 3 and borderContext of 4. Actually, the whole thing is wrong - see wm mail: One way to actually make this work: If the window was last positioned by the client, the deltax and deltay should reflect the difference between the client's mapped position and the current client window position. If the window was last positioned by the wm, the deltax and deltay should reflect the difference between the frame position and the current client window position. Then we need to add a flag to the XWMDecoration property to tell the new wm whether to ignore the win_gravity. 4 XWS00540 f.decorate does not cause the title background to get repainted. Need to force a repaint. 4 Tekwm and x10tox11 are fighting over button events in icons. Tekwm must passive-grab icon buttons iff there is a button binding to icons. Ungrab is already taken care of. 4 XWS00544 The defaulting to "colors of root window" (What does this mean?) when you run out of colors is not consistent. - sometimes we get white on black, other time green on black (the default). 4 XWS00546 If you release a button before the menu gets mapped, you may actually cause an action to occur. This needs to be syncronized better, and abort if the button release event is not actually in the menu. 4 XWS00471 Is it acceptable to grab on unreparented windows? Not according to the new grab section in the ICCCM. Tekwm needs to change to grab buttons on the root window, and replay the ButtonEvents if they are not being used on the client window (i.e. used only on root). Window manager button bindings to a WINDOW context will currently not operate on override_redirect windows that were present when the window manager started up, and which are not reparented. What should we allow? Let's assume that if a normal override-redirect window is mapped, any Active Button grabs will already be in effect, so we won't interfere. Sequence: we grab on root, we replay a ButtonPress on the client window, the client grabs the pointer, maps the popup, and everything is fine. 4 XWS00547 If autoRaise is on and the move gadget is partly off-screen, the move function is delayed by raiseDelay. 4 XWS00548 Tekwm should delete the WM_ICON_SIZE property on the root window when it exits, so that if another wm fails to set it, it won't mislead a client. 4 If you pop up a tekwm menu at the edge of the screen, and move the mouse and stop moving right when you press the button, occasionally the item under the initial pointer position is selected until the mouse moves again. Note that the item is alwasy briefly highlighted, only occasionally it remains selected. 4 Set a gadget to a string, and bind a menu narrower than the string. If the menu obscures only the one gadget, on menu release, the gadget fails to redraw! (Wayne@purdue). 4 Some windows fail to re-iconify on tekwm restart. Perhaps particualr to the "xcolors" client? (errol) 4 Occasionally, an iconify followed by an immediate deiconify fails to deiconify. (David S; also Jeff G?) 4 Level 5 On initial window sizing, right button does not allow for border when setting vertical size to fit from cursor to bottom of screen. But anyway, what kind of brain-damaged function is this? It should be something useful like "tile to the borders of all windows above the selected window". 5 XWS00263 Tekwm ignores WM_SIZE_HINTS after the window is mapped. Xt clients need to set min_size after mapping the window. 2 - ignore - must solve in toolkit. Take "X-SHELL" out of xshell picture (now in title bar). Why should saveUnder imply backingStore for icons? 5 title fg/bg is not responding to foreground/background resources?? (not sent in - recheck) 4 - probably long gone... Umm, why do you have to make your foster parent and titlebar windows the same depth as the client window? The only reason I can see that this is required is if the client window sets its background to ParentRelative, a generally strange thing to do to a top-level window, and even stranger once awm runs. This points out that to be really robust, awm probably should handle this case, and reset the client window's background to be explicitly whatever is the root window background (including aligning the origin). Of course, then when xsetroot changes the root background, we would have to update the client background, and there is no NotifyBackground event, so the only way to know when to re-check the root background is to select for exposure events (I am guessing a bit here), and this is getting to be gross! So I would just set such a client's background to the current root window background, and leave it at that. (Hmm, this is the second time I have wanted to select for notification on a change to a window attribute (other than colormap)!) 5 borderContext cursor gets inherited by the client window if the client window has not set a cursor. < I know.. I don't know how to correct this as it's a server issue. I < can't exactly just set a root cursor arbitrarily since I don't know which < clients have cursors and which don't. These are the breaks. Suggestions < welcome. Right you are, the XWindowAttributes structure is missing cursor and border/background pixel/pixmap. We could ask for another client convention to fix cursor, by setting a window property. It could even be wired into the appropriate window routines (XCreateWindow, XCreateSimpleWindow, XChangeAttributes), so that when windows are created as children of root or have their cursor changed, they get the property set. Or we could just ask for a protocol fix... Should we query Bob Scheifler on this one? 5 move loading of default font in GetFontRes to end, put font name in .h file, < fixed. Actually, Jordan did not do this yet. 5 Bugs being investigated by Jordan Hubbard Startup file error should give the file name. < Right. I'm in the process of rationalizing all the error messages. 5 bugs fixed by Jordan reverseVideo should cause swapping of foreground and background colors, not just swapping the black/white defaults. (This means all colors with resource class Foreground or Background, including menu.foreground, etc.) (FIXED by Jordan) Well, not quite. Only the Foreground and Background default resources are swapped. All resources should be swapped. 5 SYSV fixes The select() call for autoRaiseDelay (Titlebar.c) needs to be replaced with a timer. (Not required for Blackbird) 2 Don't count anymore Found in pre-SIR release: Xterm will paint first shell prompt in a column down the screen if it is printed before the window is mapped. (Xterm problem - don't count) 5 If xterm is initially iconic (-iconic) it is iconified, then a second mapRequest is received by tekwm and tekwm de-iconifies it. Bug has probably existed forever...only with xterm, not even with xclock. Tekwm is getting two MapRequests with the same serial (sequence #), window(xterm's shell), and parent (root). This says that xterm is mapping only once. However, xterm is indeed mapping its shell (top-level) window twice, as demonstrated by instrumenting the Xlib XMapWindow call, and it should be mapping only once. tekwm event trace: mainloop: EVENT MapRequest(20), serial 69939 on window 11534341(0xb00005), parent 524397(0x8006d) mainloop: EVENT MapRequest(20), serial 69939 on window 11534341(0xb00005), parent 524397(0x8006d) The server bug is that it is giving two consecutive MapRequest events the same sequence number even though they are from two different requests. I do not believe I have seen this problem with any other events. However, I don't know why I get two DestroyNotifys fron the same window: mainloop: EVENT UnmapNotify(18), serial 69677 on window 3146530(0x300322) mainloop: EVENT DestroyNotify(17), serial 69677 on window 3146530(0x300322) mainloop: EVENT DestroyNotify(17), serial 69678 on window 3146550(0x300336) mainloop: EVENT Expose(12), serial 69679 on window 3145836(0x30006c) mainloop: EVENT Expose(12), serial 69679 on window 3145836(0x30006c) mainloop: EVENT Expose(12), serial 69679 on window 3145836(0x30006c) mainloop: EVENT Expose(12), serial 69679 on window 3145852(0x30007c) mainloop: EVENT Expose(12), serial 69679 on window 3145846(0x300076) mainloop: EVENT Expose(12), serial 69679 on window 3145840(0x300070) mainloop: EVENT Expose(12), serial 69679 on window 3145795(0x300043) mainloop: EVENT DestroyNotify(17), serial 69679 on window 3146530(0x300322) 2 (Don't count - xterm bug) The red rubber box is not very visible against the default root background. Change to fluorescent orange?? Really, what is needed here is to have xsetroot examine the root window tile, then allocate all unallocated default cmap entries, set them to a color not used in the root tile, else white, then deallocate the entries. Or xsetroot or tekwm can take an option of the color to set. Also, we should consider xoring with a user-specified plane mask, default 00001 (or BlackPixel & WhitePixel)? 5 ICCCM says that wm's do not modify client properties, tekwm modifies GetButton.c: XSetIconName(dpy, awi->client, ICONSTR); GetButton.c: XSetSizeHints(dpy, awi->client, &wsh, XA_WM_NORMAL_HINTS); 5 If a tekwmrc declaration appears twice in one file, which takes precedence? First one encountered is the wrong answer... 5 Ignore events that propogate to the root window from a client window that is not selecting events, so root bindings do not take effect on some windows, e.g. xclock or xmail. 5 Menus bound to a client window do not use client window colormap. This causes the colormap to change when menus are popped up. Also, focus is tracked while menu is up. Focus should be set to None while menu is up, supressing keyboard input? fix 1: On a HandleFocusOut/In with a Leave/EnterNotify with mode NotifyGrab/Ungrab, change colormap, but leave highlighting and focus alone. fix 2: Ditto, but set focus to None. fix 3: create a menu for each client cmap, and use it if button context is client window. Then ignore these Leave/EnterNotifys. 5 Various apparently harmless protocol errors (printed when print ProtoErrors is on): From ??? tekwm: X Protocol error detected by server: BadMatch (parameter mismatch) Failed request major op code 42: X_SetInputFocus Failed request minor op code 0 (if applicable) ResourceID 0x400001 in failed request (if applicable) From UnRegister... we start to unregister on an UnmapNotify from a window deletion, and we get errors on the destroyed resources. Problem is compounded if we are futzing with focus while the client window is destroyed (e.g. on exit of close popup window over client). We might want to immediately unregister window before killing the client. But this is only a partial solution to a generally unsolvable problem. 5 If a tekwm menu is brought up with user focus set to a window, then the mouse is moved out of the menu, then back in, the client window colormap stays installed. If we start registering override-redirect windows, we can distinguish them from tekwm menus, and always install the window colormap if the window is unregistered, on the assumption that it is a tekwm menu and should take precedence over the focus window. 4- Should colormap be set to a transient_for window belonging to the window that has user focus set to it? Or should the client be required to set input focus to get the colormap to change? 5 If most allocations in the client colormap failed, set the title and gadget colormaps to Default. 5 - not needed until we have per-window-colormap hardware. If cursor is moved out of a client window with a non-default colormap immediately after mapping, the client's colormap is installed. 4- Unclassified New Possible Bugs title.background should be effective even if no title pixmaps are specified. I suspect that context and keymask expressions that end with '|' will match anything... Rejected Bugs f.pushXXX and f.redraw are not disabled on an override-redirect window. Once override-redirect wins are registered, and wm ops on them are considered legal, this becomes a non-bug... 5 - rejected based on not following ICCCM