After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 95454 - Lost focus when input method window is up and down
Lost focus when input method window is up and down
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: general
unspecified
Other opensolaris
: Normal major
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks:
 
 
Reported: 2002-10-11 01:16 UTC by Hidetoshi Tajima
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
ATOK status window gets focus when the app closed (752.06 KB, image/png)
2002-10-11 18:24 UTC, Hidetoshi Tajima
Details
log file - open ATOK candidate selection window once and close (153.96 KB, text/plain)
2002-10-11 21:54 UTC, Hidetoshi Tajima
Details

Description Hidetoshi Tajima 2002-10-11 01:16:09 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.
Comment 1 Havoc Pennington 2002-10-11 01:42:32 UTC
I don't know what metacity is supposed to do about this. Does it work
with any other window manager? How?
Comment 2 Hidetoshi Tajima 2002-10-11 16:38:49 UTC
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.
Comment 3 Havoc Pennington 2002-10-11 17:04:35 UTC
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.
Comment 4 Hidetoshi Tajima 2002-10-11 18:21:56 UTC
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?




Comment 5 Hidetoshi Tajima 2002-10-11 18:24:55 UTC
Created attachment 11499 [details]
ATOK status window gets focus when the app closed
Comment 6 Havoc Pennington 2002-10-11 18:46:51 UTC
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.)
Comment 7 Hidetoshi Tajima 2002-10-11 21:54:21 UTC
Created attachment 11501 [details]
log file - open ATOK candidate selection window once and close
Comment 8 Hidetoshi Tajima 2002-10-11 22:08:17 UTC
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.
Comment 9 Hidetoshi Tajima 2002-11-12 21:19:28 UTC
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
Comment 10 Havoc Pennington 2002-11-12 21:26:03 UTC
It should be (window->input || window->take_focus)

Otherwise yes that seems sane.
Comment 11 Hidetoshi Tajima 2002-11-12 21:31:19 UTC
Thanks, will you please commit this to the HEAD?
Comment 12 Havoc Pennington 2002-11-12 21:58:04 UTC
Yes, done.