title: Window focusing issues
lastupdated: 2008-07-30


This is a possibly long-term task, aimed at fixing various window focusing
issues present in GNUstep GUI.


<div id="outline-container-1" class="outline-2">
<h2 id="sec-1">Outcome</h2>
<div id="text-1">

<p>Ensure that GNUstep application windows (and menus) will obtain and retain
focus correctly in EWMH-compliant window managers and especially WindowMaker.
</p>
</div>

</div>

<div id="outline-container-2" class="outline-2">
<h2 id="sec-2">Tasks</h2>
<div id="text-2">


</div>

<div id="outline-container-2.1" class="outline-3">
<h3 id="sec-2.1"><span class="todo">WAITING</span> gather information on focusing issues that are present  &nbsp;&nbsp;&nbsp;<span class="tag">COLLABORATION</span></h3>
<div id="text-2.1">

<ul>
<li>
sent out <a href="http://article.gmane.org/gmane.comp.lib.gnustep.general/30893">email requesting information</a>, and got back some responses, but more
reports are welcome
</li>
</ul>
</div>

</div>

<div id="outline-container-2.2" class="outline-3">
<h3 id="sec-2.2"><span class="todo">NEXT</span> categorize (and prioritize?) issues                            &nbsp;&nbsp;&nbsp;<span class="tag">READING</span></h3>
<div id="text-2.2">

<ul>
<li>
need to figure out which ones to work on, and which ones should be part of
other sub-projects
</li>
</ul>
</div>

</div>

<div id="outline-container-2.3" class="outline-3">
<h3 id="sec-2.3"><span class="todo">NEXT</span> look through source code                                       &nbsp;&nbsp;&nbsp;<span class="tag">READING</span></h3>
<div id="text-2.3">

<p>Implementation is in:
</p><ul>
<li>
<a href="http://svn.gna.org/viewcvs/gnustep/libs/gui/trunk/Source/NSWindow.m?view=auto">NSWindow</a> (<a href="http://svn.gna.org/viewcvs/gnustep/libs/gui/trunk/Headers/AppKit/NSWindow.h?view=auto">header</a>)
<ul>
<li>
<code>- (void) _lossOfKeyOrMainWindow</code>
<ul>
<li>
tries to find another window to make key/main.  Skip the main menu as
potential key window unless no others were found.
</li>
<li>
called by:
<ul>
<li>
<code>- (void) orderWindow: (NSWindowOrderingMode)place relativeTo:         (int)otherWin</code> when ordering out
</li>
<li>
<code>- (void) miniaturize: (id)sender</code>
</li>
<li>
<code>- (void) sendEvent: (NSEvent*)theEvent</code> on <code>GSAppKitWindowFocusIn</code>
when focus goes to the main menu window
</li>
</ul>
</li>
</ul>
</li>
<li>
window creation: <code>- (id) initWithContentRect: (NSRect)contentRect styleMask: (unsigned int)aStyle backing: (NSBackingStoreType)bufferingType     defer: (BOOL)flag screen: (NSScreen*)aScreen</code>, <code>- (void)     _initBackendWindow</code>, <code>- (void) _startBackendWindow</code>, <code>- (void)     _terminateBackendWindow</code>
<ul>
<li>
<code>_initBackendWindow</code> calls <code>XGServerWindow</code>'s <code>window::::</code> and
<code>setwindowlevel</code> methods
</li>
</ul>
</li>
<li>
<code>- (id) initWithWindowRef: (void *)windowRef</code>
</li>
<li>
<code>- (void) becomeKeyWindow</code>, <code>- (void) becomeMainWindow</code>,
<code>- (void) makeKeyAndOrderFront: (id)sender</code>, <code>- (void) makeKeyWindow</code>, <code>-     (void) makeMainWindow</code>, <code>- (void) resignKeyWindow</code>, <code>- (void) resignMainWindow</code>
</li>
<li>
<code>- (void) orderBack: (id)sender</code>, <code>- (void) orderFront: (id)sender</code>, <code>-     (void) orderFrontRegardless</code>, <code>- (void) orderOut: (id)sender</code>, <code>- (void)     orderWindow: (NSWindowOrderingMode)place relativeTo: (int)otherWin</code>
</li>
<li>
<code>- (void) setLevel: (int)newLevel</code>
</li>
<li>
<code>- (void) _didDeminiaturize: sender</code>, <code>- (void) deminiaturize: sender</code>, <code>-     (void) miniaturize: (id)sender</code>
</li>
<li>
<code>- (void) sendEvent: (NSEvent*)theEvent</code>
<ul>
<li>
handles events e.g. from window manager, sent via NSApplication
</li>
</ul>
</li>
<li>
<code>- (BOOL) hidesOnDeactivate</code>, <code>- (void) setHidesOnDeactivate: (BOOL)flag</code>
</li>
</ul>
</li>
<li>
<a href="http://svn.gna.org/viewcvs/gnustep/libs/gui/trunk/Source/NSApplication.m?view=auto">NSApplication</a>
<ul>
<li>
AppIcon definitions
</li>
<li>
<code>- (void) finishLaunching</code> (where windows are first ordered)
<ul>
<li>
find key and main windows
</li>
<li>
if more than one key/main window, deactivate all but one
</li>
<li>
if no main window, choose one
</li>
</ul>
</li>
<li>
<code>- (void) hide: (id)sender</code> <code>- (void) unhide: (id)sender</code>, <code>- (void)     unhideWithoutActivation</code>
</li>
<li>
<code>- (void) unhideWithoutActivation</code>
</li>
<li>
<code>- (void) arrangeInFront: (id)sender</code>
</li>
<li>
<code>- (NSWindow*) keyWindow</code>, <code>- (NSWindow*) mainWindow</code>
</li>
<li>
<code>- (void) miniaturizeAll: sender</code>
</li>
<li>
<code>- (void) preventWindowOrdering</code> <i>(not implemented)</i>
</li>
<li>
<code>- (void) activateIgnoringOtherApps: (BOOL)flag</code>, <code>- (void) deactivate</code>
</li>
<li>
<code>- (void) mouseDown: (NSEvent*)theEvent</code>
<ul>
<li>
raise the app
</li>
</ul>
</li>
</ul>
</li>
<li>
<a href="http://svn.gna.org/viewcvs/gnustep/libs/back/trunk/Source/x11/XGServerWindow.m?view=auto">XGServerWindow</a>
<ul>
<li>
<code>- (void) orderwindow: (int)op : (int)otherWin : (int)winNum</code>
</li>
<li>
<code>- (void) setwindowlevel: (int)level : (int)win</code>?
</li>
<li>
<code>- (void) setinputfocus: (int)win</code>
<ul>
<li>
calls <code>XSetInputFocus</code> to claim focus
</li>
</ul>
</li>
<li>
<code>- (int) window: (NSRect)frame : (NSBackingStoreType)type : (unsigned int)style : (int)screen</code>
<ul>
<li>
the main window creation function
</li>
<li>
does lots of stuff
</li>
<li>
window isn't displayed until <code>-orderwindow::</code> is called
</li>
</ul>
</li>
</ul>
</li>
<li>
<a href="http://svn.gna.org/viewcvs/gnustep/libs/back/trunk/Source/x11/XGServerEvent.m%3Fview%3Dauto">XGServerEvent</a>
<ul>
<li>
<code>- (void) processEvent: (XEvent *) event</code>
<ul>
<li>
process X11 events
</li>
<li>
big switch statement for all sorts of X11 events
<ul>
<li>
<code>ClientMessage</code>: may call <code>-_handleTakeFocusAtom:forContext:</code>
</li>
<li>
<code>FocusOut</code>: calls <code>[NSApp deactivate]</code> if focus goes do another
application; may cancel previous focus request
</li>
</ul>
</li>
</ul>
</li>
<li>
<code>- (NSEvent *)_handleTakeFocusAtom: (XEvent)xEvent forContext:     (NSGraphicsContext *)gcontext</code>
<ul>
<li>
called when the Window Manager wants us to take focus
</li>
<li>
calls <code>-setinputfocus:</code> for the appropriate window
</li>
</ul>
</li>
</ul>
</li>
</ul>
</div>

</div>

<div id="outline-container-2.4" class="outline-3">
<h3 id="sec-2.4"><span class="todo">NEXT</span> come up with a flow for what should be correct behaviour        &nbsp;&nbsp;&nbsp;<span class="tag">DESIGN</span></h3>
<div id="text-2.4">

<ul>
<li>
application with or without normal windows
</li>
<li>
ways of gaining focus
<ul>
<li>
application starts
<ul>
<li>
if a main window is created, it should be focused, otherwise focus the
main menu
</li>
</ul>
</li>
<li>
user clicks on window (i.e. window manager gives application focus)
</li>
<li>
user changes desktop (window manager gives application focus)
</li>
<li>
new window
</li>
<li>
application asks for focus
</li>
<li>
window unminiaturized
</li>
<li>
another window loses focus
</li>
<li>
double-click on application icon
</li>
<li>
select window from popup menu
</li>
</ul>
</li>
<li>
ways of losing focus
<ul>
<li>
application terminates
<ul>
<li>
nothing to be done.  We don't care what happens
</li>
</ul>
</li>
<li>
user clicks on another window (i.e. window manager takes away focus)
</li>
<li>
user changes desktop (window manager takes away focus)
</li>
<li>
window closed
</li>
<li>
application releases focus
</li>
<li>
window miniaturized
</li>
<li>
application is hidden
</li>
</ul>
</li>
</ul>
</div>

</div>

<div id="outline-container-2.5" class="outline-3">
<h3 id="sec-2.5">implement focusing logic                                     &nbsp;&nbsp;&nbsp;<span class="tag">IMPLEMENTATION</span></h3>
<div id="text-2.5">

</div>

</div>

<div id="outline-container-2.6" class="outline-3">
<h3 id="sec-2.6">consider different window managers                                  &nbsp;&nbsp;&nbsp;<span class="tag">TESTING</span></h3>
<div id="text-2.6">


</div>
</div>

</div>

<div id="outline-container-3" class="outline-2">
<h2 id="sec-3">Questions</h2>
<div id="text-3">

<ul>
<li>
<b>Q:</b> Why does <code>NSApplication</code>'s <code>-sendEvent</code> have different cases?  Why don't
we check if <code>theEvent</code> is <code>nil</code> at the beginning?
</li>
<li>
<b>Q:</b> Why are some atoms stored in stored in <code>generic</code>, and some in
function-local static variables?
<ul>
<li>
<b>A:</b> They should all go into <code>generic</code> eventually.

</li>
</ul>
</li>
</ul>
</div>

</div>

<div id="outline-container-4" class="outline-2">
<h2 id="sec-4">X Events (from xev, on xfwm4)</h2>
<div id="text-4">


</div>

<div id="outline-container-4.1" class="outline-3">
<h3 id="sec-4.1">On iconize:</h3>
<div id="text-4.1">

<ul>
<li>
FocusOut (mode NotifyNormal, detail NotifyNonlinear)
</li>
<li>
UnmapNotify (<code>from_configure</code> NO)
</li>
<li>
<code>WM_STATE</code> set
</li>
<li>
<code>_NET_WM_STATE</code> set
</li>
<li>
<code>_WIN_STATE</code> set
</li>
</ul>
</div>

</div>

<div id="outline-container-4.2" class="outline-3">
<h3 id="sec-4.2">On uniconize</h3>
<div id="text-4.2">

<ul>
<li>
MapNotify (override NO)
</li>
<li>
VisibilityNotify (state VisibilityUnobscured)
</li>
<li>
Expose (x4)
</li>
<li>
<code>WM_STATE</code> set
</li>
<li>
<code>_NET_WM_STATE</code> set
</li>
<li>
<code>_WIN_STATE</code> set
</li>
<li>
FocusIn
</li>
</ul>
</div>

</div>

<div id="outline-container-4.3" class="outline-3">
<h3 id="sec-4.3">On lose focus:</h3>
<div id="text-4.3">

<ul>
<li>
FocusOut (mode NotifyNormal, detail NotifyNonlinear)
</li>
<li>
maybe: LeaveNotify (mode NotifyGrab, detail NotifyNonlinear, <code>same_screen</code> YES,
focus YES, state 6)
</li>
</ul>
</div>

</div>

<div id="outline-container-4.4" class="outline-3">
<h3 id="sec-4.4">On gain focus:</h3>
<div id="text-4.4">

<ul>
<li>
FocusIn (mode NotifyWhileGrabbed, detail NotifyNonlinear)
</li>
<li>
maybe: EnterNotify (mode NotifyUngrab, detail NotifyNonlinear, <code>same_screen</code>
YES, focus YES, state 0)

</li>
</ul>
</div>
</div>

</div>

<div id="outline-container-5" class="outline-2">
<h2 id="sec-5">Issues</h2>
<div id="text-5">


</div>

<div id="outline-container-5.1" class="outline-3">
<h3 id="sec-5.1"><span class="done">DONE</span> Application does not gain focus on initial start</h3>
<div id="text-5.1">

<ul>
<li>
window manager: kwin, xfwm4
</li>
<li>
GNUstep versions: several
</li>
<li>
reproducible
</li>
<li>
applications that don't have an initial main window (e.g. Ink)
</li>
<li>
when started from a terminal, the terminal keeps focus, and the application's
menu may disappear (does not disappear for xfwm4)
<ul>
<li>
no longer a problem on xfwm4 with GNUstep gui/back 0.14.0.
</li>
</ul>
</li>
<li>
this is caused by "focus stealing prevention"
</li>
<li>
use <code>_NET_WM_USER_TIME</code>
</li>
<li>
works in default configuration of tested window managers
</li>
<li>
if other window managers pose a problem, look into using
<code>_NET_WM_ACTIVE_WINDOW</code>
</li>
</ul>
</div>

</div>

<div id="outline-container-5.2" class="outline-3">
<h3 id="sec-5.2">Menu disappears/appears in background while in use</h3>
<div id="text-5.2">

<ul>
<li>
window manager: WindowMaker (click to focus)
</li>
<li>
GNUstep versions: latest CVS, LiveCD
</li>
<li>
intermittent
</li>
<li>
"The problem, which I think is the same or in any case related, appears in two
ways:
<ul>
<li>
"while clicking and moving the mouse on the main application menu, the menu
may disappear (but it is sitll active, the submenus will show up and work
and unseen items do work).
</li>
<li>
"The second manifestation is similar, but involves two applications open. I
click on the menu of the current one and click-drag to show the submenus,
they will appear <b>behind</b> the other's application menu, which should be in
the background. Again they work."
</li>
</ul>
</li>
</ul>
</div>

</div>

<div id="outline-container-5.3" class="outline-3">
<h3 id="sec-5.3">Two windows are key</h3>
<div id="text-5.3">

<ul>
<li>
window manager: WindowMaker (click to focus)
</li>
<li>
GNUstep versions: latest CVS, LiveCD
</li>
<li>
intermittent (rare)
</li>
<li>
two windows are key (black border) or key window is ordered behind non-key
window
</li>
</ul>
</div>

</div>

<div id="outline-container-5.4" class="outline-3">
<h3 id="sec-5.4">Closing (unfocused) preferences window makes application lose focus</h3>
<div id="text-5.4">

<ul>
<li>
see <a href="https://savannah.gnu.org/bugs/?19100">Bug #19100: Application Focusing Issues</a>
</li>
<li>
doesn't seem to happen in current xfwm4, wmaker
</li>
</ul>
</div>

</div>

<div id="outline-container-5.5" class="outline-3">
<h3 id="sec-5.5">When <code>GSX11HandlesWindowDecorations</code> set to <code>NO</code>, clicking miniaturize button doesn't unmap window</h3>
<div id="text-5.5">

<ul>
<li>
window manager: xfwm4, none
</li>
<li>
works in: wmaker
</li>
</ul>
</div>

</div>

<div id="outline-container-5.6" class="outline-3">
<h3 id="sec-5.6"><span class="done">DONE</span> Create new document in Ink causes application to lose focus</h3>
<div id="text-5.6">

<ul>
<li>
window manager: wmaker
</li>
<li>
works in: xfwm4
</li>
<li>
GNUstep versions: 1.16.0/0.14.0
</li>
<li>
reproducible
</li>
<li>
Open Ink, and select Document | New: new document does not obtain focus
</li>
<li>
seems to be fixed by "focus stealing prevention prevention" fix from first
issue
</li>
</ul>
</div>

</div>

<div id="outline-container-5.7" class="outline-3">
<h3 id="sec-5.7"><span class="done">DONE</span> Miniaturizing from GNUstep different from miniaturizing from window manager</h3>
<div id="text-5.7">

<ul>
<li>
window manager: xfwm4
</li>
<li>
works in: wmaker
</li>
<li>
GNUstep versions: 1.16.0/0.14.0
</li>
<li>
reproducible
</li>
<li>
when miniaturizing from window manager, no miniwindow is produced.
</li>
<li>
when miniaturizing from GNUstep, then hiding, miniaturized windows show up in
task list as miniaturized, non-miniaturized ones do not
</li>
<li>
performance impact of responding to <code>PropertyNotify</code> XEvents shouldn't be too
bad.  (A bunch of events are generated, but no noticeable impact.)
</li>
<li>
only respond to <code>PropertyNotify</code> under EWMH window managers
</li>
</ul>
</div>

</div>

<div id="outline-container-5.8" class="outline-3">
<h3 id="sec-5.8">Double-click on appicon makes wrong window key</h3>
<div id="text-5.8">

<ul>
<li>
window manager: xfwm4
</li>
<li>
GNUstep versions: 1.16.0/0.14.0
</li>
<li>
application: Ink
</li>
<li>
If two windows open in Ink, double-clicking on appicon switches focus to the
other window.
<ul>
<li>
If app is unfocused, double-clicking on appicon switches focus to the
window that was <i>not</i> focused before.
</li>
</ul>
</li>
<li>
Looks like xfwm4 tries to give focus to windows when they are raised.
</li>
<li>
Maybe a window manager quirk.  Maybe not worth fixing.
</li>
</ul>
</div>

</div>

<div id="outline-container-5.9" class="outline-3">
<h3 id="sec-5.9">Menu gets "stuck"</h3>
<div id="text-5.9">

<ul>
<li>
window manager: openbox 3.4.7.2
</li>
<li>
works in: xfwm4
</li>
<li>
GNUstep versions: SVN 20080615

</li>
</ul>

<p>"If you close or iconify a window and the one to gain focus is not owned by the
same application, the app menu gets stuck. That is, at first the menu disappears
because another app got focus, but if you bring it up again, it won't go away
as easily. In the iconify case, the menu gets stuck right away, without first
disappearing, probably because GNUstep does not take any notice at all of the
action done by the window manager.
</p>
<p>
"The menu just sits there and does not receive keybord actions. Even if you
interact with the menu by opening and closing sub-menus it does not get in a
state where it reacts to menu shortcuts.
</p>
<p>
"It seems that opening a sub-menu and then clicking back and forth between the
appicon and a window belonging to some other app fixes the problem. Also notice
that when in the problematic state, double clicking the appicon does not unfocus
other windows like is normally the case. Opening or focusing one of the
application's own windows is another way to fix the situation."
</p></div>

</div>

<div id="outline-container-5.10" class="outline-3">
<h3 id="sec-5.10"><span class="todo">NEXT</span> Open window from hidden app</h3>
<div id="text-5.10">

<ul>
<li>
window manager: openbox 3.4.7.2, xfwm4
</li>
<li>
GNUstep versions: SVN 20080615

</li>
</ul>

<p>"When an application is hidden, you can still access its menu by right-clicking
the app icon. If you bring to front an existing window from the Window menu or
open a new one using Document-&gt;New or similar, the app stays hidden when the
window appears, which means the app menu does not show. The application as a
whole gets restored if you click anywhere inside the window, though."
</p><ul>
<li>
should call unhide in response to some event (Mapped?)
</li>
<li>
or unhide in response to <code>-[NSWindow makeKeyAndOrderFront:]</code> or
<code>-[NSWindow makeKeyWindow]</code>
</li>
</ul>
</div>

</div>

<div id="outline-container-5.11" class="outline-3">
<h3 id="sec-5.11"><span class="todo">NEXT</span> Hide + miniwindows</h3>
<div id="text-5.11">

<ul>
<li>
window manager: openbox 3.4.7.2, xfwm4
</li>
<li>
GNUstep versions: SVN 20080615

</li>
</ul>

<p>When you hide an application that has miniaturized windows, strange things
happen to those windows.
</p>
<ol>
<li>
When an application miniaturizes a window, Openbox marks the window as
iconified the same way it does when minimizing windows by itself.

</li>
<li>
When the application gets hidden, its miniwindows become invisible (!)

</li>
<li>
Windows that were visible before the app got hidden are now completely
inaccessible from the window manager - they are removed from the internal
list of windows as well as external panels and pagers. This is probably
correct behaviour since you're supposed to use the appicon to get the
application back. The strange thing, however, is that the <b>miniaturized</b>
windows are still in the window list (marked as iconified).

</li>
<li>
If you restore a window using window manager features while the app is hidden
(only possible with the miniaturized ones), the window appears without focus
and the menu is not shown. No amount of switching between windows or
iconifying/restoring the window will change this.

</li>
<li>
Restoring the application while in this state, brings back the miniwindow
even though the real window is now visible. Only when you focus the window
will the miniwindow disappear.

</li>
<li>
If instead of 4) you restore a miniaturized window by right-clicking the
hidden application's app icon, the miniwindow will stay around until you do
a new miniaturize/restore cycle on the window. If you close the window at
this point, there is probably no way to get rid of the miniwindow at all.

</li>
<li>
<code>-[NSApplication hide:]</code> skips windows that are not visible
<ul>
<li>
should not skip miniaturized windows (although not visible)
</li>
<li>
<code>-[NSApplication unhide]</code> should order in miniaturized windows, but don't
try to make them key (make sure they are still iconified)
</li>
</ul>
</li>
</ol>
</div>

</div>

<div id="outline-container-5.12" class="outline-3">
<h3 id="sec-5.12">Menu does not follow workspace</h3>
<div id="text-5.12">

<ul>
<li>
window manager: openbox 3.4.7.2, wmaker
</li>
<li>
works in: xfwm4
</li>
<li>
GNUstep versions: SVN 20080615
</li>
<li>
"When a window is moved to a different workspace, the menu does not follow.
Maybe it would be better to just make the menus omnipresent?"
</li>
<li>
probably belongs to the <a href="ewmh.html">ewmh</a> task
</li>
<li>
works for xfwm4: when changing desktops, xfwm4 sends <code>FocusOut</code> saying that
window 0 got focus.  I guess other WMs send <code>FocusOut</code> saying that the
application's other window got focus.
</li>
<li>
it looks like it's already supposed to be omnipresent
</li>
<li>
instead of making menu omnipresent, should store the current desktop.  When
we get a <code>FocusIn</code> event, check the current desktop.  If the desktop is
different, move menu (and other similar windows) to the desktop.
</li>
</ul>
</div>

</div>

<div id="outline-container-5.13" class="outline-3">
<h3 id="sec-5.13">GWorkspace desktop</h3>
<div id="text-5.13">

<ul>
<li>
window manager: openbox 3.4.7.2
</li>
<li>
GNUstep versions: SVN 20080615
</li>
<li>
"Using GWorkspace's desktop with Openbox is impossible because when you click
the dock or on the desktop itself, the desktop background is raised so that
it shadows other windows."
</li>
<li>
probably belongs to the <a href="ewmh.html">ewmh</a> task, or is GWorkspace-specific
</li>
</ul>
</div>

</div>

<div id="outline-container-5.14" class="outline-3">
<h3 id="sec-5.14"><span class="todo">NEXT</span> Window does not gain focus when selected from popup menu</h3>
<div id="text-5.14">

<ul>
<li>
window manager: xfwm4
</li>
<li>
GNUstep versions 1.16.0/0.14.0
</li>
<li>
when application is inactive, and you right-click on appicon and select a
window from the window menu, the window is raised to the top, but does not
obtain focus.  (main menu window does not appear)
</li>
<li>
call unhide in response to <code>-[NSWindow makeKeyAndOrderFront:]</code> or
<code>-[NSWindow makeKeyWindow]</code> (same as "<a href="#sec-5.10">Open window from hidden app</a>")
</li>
</ul>
</div>
</div>
</div>