Input focus tests

Test cases

Source - application or window that was active focused before action occurs.

Target - application or window that becomes active or focused.

Window click

Desired behaviour

• Target application:
  • clicked window titlebar becomes black
  • clicked window ordered front (other app windows should at the old level)
  • main menu appeared
  • input focus stays on focused window (keyboard presses should go to this window)
  • WM’s `scr->focused_window` should point to this window
• Source application:
  • previously focused window titlebar becomes gray
  • main menu disappeared

Action calls

1. Click on window decorations (title and resize bars).
   • handleButtonPress() - event.c
     • *desc->handle_mousedown() - event.c
       • titlebarMouseDown() - window.c
         • wSetFocusTo() - actions.c
           • wWindowFocus() - window.c
           • wWindowUnfocus() - window.c
         • wRaiseFrame()
2. Click inside window (contents managed by the application).
   • handleButtonPress() - event.c
     • *desc->handle_mousedown() - event.c
       • frameMouseDown() - window.c
         • wSetFocusTo() - actions.c
           • wWindowFocus() - window.c
           • wWindowUnfocus() - window.c
         • wRaiseFrame()
3. Click inside GNUstep window Click inside GNUstep window is not handled by WM. The calls below is event handling of mapped or focused windows generated by GNUstep actions (main menu and hidden panels appearance).
   • handleMapRequest() - event.c
     • wSetFocusTo() - actions.c
       • wWindowFocus() - window.c
       • wWindowUnfocus() - window.c

Bugs

• If GNUstep app non-key window was clicked inside, previsous key window is raised. Possible cause of a problem: window click activates application (-activateIgnoringOtherApps:). This leads to ordering front all application windows. It is correct for appicon double-clicking but not for clicking inside window. Possible solution: send TAKE_FOCUS to clicked window and then pass click to window. Solution: [NSWindow makeKeyAndOrderFront:] calls [NSApp unhide:] without check if app is hidden.

Appicon double-click

Desired behaviour

• Target application
  • all windows of application ordered to front of other apps’ windows
  • main menu appeared
  • key window becomes focused (WApplication->last_focused)
• Source application
  • key window titlebar becomes gray
  • main menu disappeared

Action calls

1. Click on NOT docked app icon
   • processEvent: - XGServerEvent.m
     • handleButtonPress() - event.c
       • appIconMouseDown() - appicon.c
         • iconDblClick() - appicon.c
           • wUnhideApplication() - actions.c
2. Click on docked app icon
   • processEvent: - XGServerEvent.m
     • handleButtonPress() - event.c
       • iconMouseDown() - dock.c
         • iconDblClick() - dock.c
           • wUnhideApplication() - actions.c

Bugs

Window/panel open

Desired behaviour

Events: application start, windows creation, Open/Save dialogs, alert panels.

• opened window/panel becomes focused
• main menu appears

Action calls

• handleMapRequest() - event.c
  • wManageWindow - window.c
    • wSetFocusTo() - actions.c
      • wWindowFocus() - window.c
      • wWindowUnfocus() - window.c

Bugs

Window/panel close

Desired behaviour

• While other app window exists
  • next app window becomes focused
• Last window
  • GNUstep: main menu receives input focus
  • X11: previously focused window of other application becomes focused

Action calls

1. Closed by WM (titlebbar “Close”/”Kill” button click);
   • handleButtonPress() - event.c
     • buttonMouseDown() - framewin.c
       • windowCloseClick() - window.c
         • wClientSendProtocol() - window.c [sends DELETE_WINDOW atom to client window]
2. Closed by application (user selects menu item, use keyboard shortcuts, main menu and panels hiding).
   • handleUnmapNotify() - event.c
     • wUnmanageWindow() - window.c

Bugs

• For X11 applications: previously focused window becomes focused even if other app windows exist. Should focus next application window.

Appicon right-click menu

Desired behaviour

• GNUstep appicon
  • main menu appears without focus switch, app activation or unhiding.
• X11 appicon
  • Short menu (“Launch”, “Bring Here”, “Hide”, “Kill”) appears with app’s name in the title. No focus switch, app activation or unhiding.

Action calls

1. GNUstep appicon
2. X11 appicon
   • handleButtonPress() - event.c

Bugs

• Hidden GNUstep application activates with blacked “Hide” menu item.

Miniaturize/deminiaturize window (with mouse or keyboard).

Desired behaviour

The same as in “Window/panel close” test

Action calls

Bugs

• For X11 applications: previously focused window becomes focused even if other app windows exist. Should focus next application window.

Hide application (with mouse or keyboard)

Desired behaviour

• all windows are unmapped
• previously focused window of other application becomes focused

Action calls

1. Key press (Cmd-h)
   • handleKeyPress() - event.c
     • [GNUstep] XSendEvent(KeyPressMask)
     • [X11] wHideApplication() - actions.c
2. Left titlebar button right-click
   • windowIconifyClick() - window.c
     • [GNUstep] wClientSendProtocol(w_global.atom.gnustep.wm_hide_app)
     • [X11] wHideApplication() - actions.c
3. “Hide” menu item
   • hideApplication: - XGServerWindow.m
     • _sendRoot::::::: - XGServerWindow.m
       • XSendEvent() _WINDOWMAKER_WM_FUNCTION_ATOM, WMFHideApplication
   • handleClientMessage() - event.c
     • wHideApplication() - actions.c

Bugs

Switch between applications with ‘Cmd-Tab’ key equivalent

Desired behaviour

Identical to “Appicon double-click”

Action calls

Bugs

Application quit

Desired behaviour

1. Previously active app has opened window
2. Previously active app has minimized window
3. Previously active app is menu-only

Action calls

• handleDestroyNotify() - event.c [?]
  • wApplicationDestroy() - application.c

Workspace switch

Desired behaviour

Action calls