mjrusso / scoot

Keyboard-driven MacOS cursor actuator
BSD 3-Clause "New" or "Revised" License
333 stars 14 forks source link

Scoot cannot use element-based navigation to interact with its own windows #24

Open mjrusso opened 2 years ago

mjrusso commented 2 years ago

(Alternative title: Meta-Scoot: Scoot cannot "scoot" its own windows)

It isn't possible to interact with Scoot's windows (e.g., the Settings screen: #21, the About screen: a0fb6c2cad42e986762a5247eb8b234e5e391ecf, etc.), using element-based navigation.

This is because of the following code, which prevents Scoot from "seeing" its own windows:

    /// The frontmost application at the moment when Scoot was most recently
    /// invoked. (If Scoot happens to be the frontmost app when it is invoked,
    /// the previous frontmost app is returned.)
    var currentApp: NSRunningApplication? {
        didSet {
            // Don't allow Scoot to be set as the current app; instead, retain
            // the previous value. (This behaviour provides a simple mechanism
            // for recomputing available elements when using element-based
            // navigation: simply re-invoke Scoot, even if it is frontmost.)
            guard currentApp != .current else {
                currentApp = oldValue
                return
            }
        }
    }

To fix this, we'll need to only ignore Scoot if NSApp.keyWindow (and NSApp.mainWindow?) is currently inputWindow.

I quickly prototyped this, and the technique itself mostly works, however when I click on a tab in the Settings screen, or pull up the color picker, etc., Scoot stops accepting any keyboard input. The commands are being received, however, because if I use my mouse to click, all the queued keyboard commands are immediately replayed.