GNOME Bugzilla – Bug 95454
Lost focus when input method window is up and down
Last modified: 2004-12-22 21:47:04 UTC
When keyboard focus policy is "Click to focus", applications loses focus when candidate selection window of Atok12 input method is closed. The candidate selection window is a toplevel window and takes focus when it maps, and does not return a focus to the application window when unmapped, as it is not a transient child of the application window.
I don't know what metacity is supposed to do about this. Does it work with any other window manager? How?
It works with CDE's dtwm. It returns focus to the application as soon as the Atok12 window is unmapped. In general, this is controlled by autoKeyfocus settings, written below. It is True by default. autoKeyFocus (class AutoKeyFocus) This resource is available only when the keyboard input focus policy is explicit. If autoKeyFocus is given a value of True, then when a window with the keyboard input focus is withdrawn from window management or is iconified, the focus is set to the previous window that had the focus. If the value given is False, there is no automatic setting of the keyboard input focus. It is recommended that both autoKeyFocus and startupKeyFocus be True to work with tear off menus. The default value is True. FYU, startupKeyFocus is defined as below. I think metacity behaves samely at the moment: startupKeyFocus (class StartupKeyFocus) This resource is available only when the keyboard input focus policy is explicit. When given the default value of True, a window gets the keyboard input focus when the window is mapped (that is, initially managed by the window manager). It is recommended that both autoKeyFocus and startupKeyFocus be True to work with tear off menus. The default value is True.
I guess metacity is already supposed to do that (focus the topmost window when the current focus window closes). I'm not sure why it isn't happening.
Metacity on Solaris returns focus to the topmost when gnome apps(I tested with gnome-terminal and gedit) closed. When non-gnome apps such as xterm and CDE dtterm closed, it returns the focus to input method's status window attached to the topmost window. I'll attach a screen shot. A small window leveled "ATOK" gets focus when xterm or CDE closed. The "ATOK" is a tranient child of the terminal window. (It does not look like taking focus, since I had to move focus to hit screen_shot button..) And when Atok12 lookup choice window closed, it however does not return focus to either the topmost or the status window - no window has focus. Any insight?
Created attachment 11499 [details] ATOK status window gets focus when the app closed
Not obvious to me what's wrong. You might try looking at the log file or attaching it here. (Run a new metacity with METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 - you could do it with "metacity --replace" to replace current metacity. Quickly reproduce the bug, without doing anything else to clutter the log file. Then pack up the log file and attach to the bug report, or "grep FOCUS" in the logfile and look to see what goes wrong.)
Created attachment 11501 [details] log file - open ATOK candidate selection window once and close
I attached the whole log. When a gnome-terminal is served by Atok12 input method, I run a new metacity, and bring up Atok12's choice window and close it.
Havoc, how about adding window->take_focus check to get a default_focus_window in window stack? A patch will be like below. This has fixed a problem for me with Atok12's candidate window. Index: stack.c =================================================================== RCS file: /sgnome/cvsroots/sun-gnome/metacity/src/stack.c,v retrieving revision 1.3 diff -u -p -r1.3 stack.c --- stack.c 5 Nov 2002 18:15:54 -0000 1.3 +++ stack.c 12 Nov 2002 21:08:58 -0000 @@ -1307,7 +1307,8 @@ meta_stack_get_default_focus_window (Met * focusing dock, even though docks are stacked higher. */ if (topmost_overall == NULL && - window->type != META_WINDOW_DOCK) + window->type != META_WINDOW_DOCK && + window->take_focus) topmost_overall = window; /* We could try to bail out early here for efficiency in
It should be (window->input || window->take_focus) Otherwise yes that seems sane.
Thanks, will you please commit this to the HEAD?
Yes, done.