jzw@lanl.gov (Jay Waller) (01/18/89)
There seems to be a bug when running xfig under twm. If you start xfig with no file name and do some operations everything seems to work fine. If you then save the file with the "Save" option in the xfig menu the "Text" function will not work. You can choose the text function and place the cursor on the canvas, but it doesn't seem to read input from the keyboard. This also happens when you use such things as "Read file" from the menu. You can get around this as long as you start up xfig from the command line with a filename. Also, I cannot duplicate this bug when running another window manager such as uwm. We are currently running X11R3 on Sun 3/50s. Any ideas on what could be causing this? Thanks.
davep@ginsu.apple.COM (01/19/89)
I just spent a solid day debugging twm & xbrowser, and found a bug in the intrinsics that would also cause problems in xfig and other toolkit programs, as noted by Jay Waller and Sundar Narasimhan. In <8901181543.AA09479@special-k.ai.mit.edu>, Sundar indicates that awm may also trigger the problem, but less reliably. The problem comes when using twm (without having NoTitleFocus set in the .twmrc file) with an application that uses popup shells without destroying them when it pops them down. When the popup shell is popped down, characters are no longer sent to text widgets in the main window. I will create a trivial example program and submit a bug report to MIT, but I wanted to let people know what was happening. Two possible workarounds are: a) call XtDestroyWidget to destroy the widget after popping it down with XtPopdown, or b) set NoTitleFocus in .twmrc. When NoTitleFocus is set, twm explicitly sets the input focus to the top-level client window when the pointer enters the frame window, by calling XSetInputFocus. Doing this causes the server to send the client FocusIn and FocusOut events that don't normally get sent (run xev with and without twm to see this). The intrinsics handle these events by calling InsertFocusEntry() and RemoveGrab() to modify the focusList in lib/Xt/Event.c. Normally there is only one entry on the focusList (for the active shell window). However, when you popdown a dialog without destroying it, RemoveGrab() doesn't get called on it. InsertFocusEntry() does get called for the main window, as usual. Now there are two entries on the focusList; the main window's entry is at the head of the list. When keyboard input comes in, the FindFocusWidget() routine in Event.c is called to determine what widget the event should be dispatched to. There is a bug in FindFocusWidget() -- if the focusList entry it finds is not at the end of the list, the "if (start == NULL)" test in the while loop fails, and eventually it finishes the loop rather than returning from the middle of it. If the test had succeeded, it would later have deduced that dst is an ancestor of widget, and returned widget. At the end of the routine, it merely returns dst (the ancestor), which is the child of the top-level shell window. Twm's behaviour here is reasonable, although the current implementation of title focus (i.e., sending characters to the client window when the pointer is in the frame window) can cause a delay in shifting the input focus when moving the pointer to another top-level window. Dave Payne Apple Computer, A/UX Engineering Group, Cupertino, CA. davep@apple.com (408) 974-5545