Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add element-based navigation mode #1

Merged
merged 15 commits into from
Jan 1, 2022
Merged

Add element-based navigation mode #1

merged 15 commits into from
Jan 1, 2022

Conversation

mjrusso
Copy link
Owner

@mjrusso mjrusso commented Jan 1, 2022

This PR introduces "element-based" navigation. 🎉

When this element-based nav mode is active, Scoot will use MacOS accessibility APIs to find the user interface elements on the screen (specifically, those in the focused window of the frontmost app at the time that Scoot is invoked).

Here's what this looks like, in Safari on example.com:

Screen Shot 2022-01-01 at 10 14 11 AM

Scoot identifies the only link on the page ("More information..."), and assigns it the key sequence "aa". (As always, type "aa" to teleport the mouse cursor directly there.) Scoot doesn't just find the content on the web page though -- it also identifies the browser chrome/ UI elements. For example, type "k" to move the cursor to the "show tab overview" button.

Another example, on a web page with (a few) more links:

Screen Shot 2022-01-01 at 10 14 37 AM

Here's Music's MiniPlayer:

Screen Shot 2022-01-01 at 10 24 47 AM

The sandbox isn't compatible with the Carbon Accessibility API (so, for
example, you can't query for `AXUIElement`s from other apps).

Thanks to tmandry/AXSwift#16 for the tip.
(As well as GridWindowController and GridViewController to JumpWindowController and JumpViewController, respectively.)
(This complements the existing grid-based navigation functionality.)

Applicable elements are determined using the underlying accessibility APIs
provided by macOS (c/o AXSwift).
There's no benefit to drawing multiple copies of the same frame -- this just adds visual noise and clutters the decision tree.
(There are still legibility issues to work through, but this seems a bit better in most cases.)
@mjrusso
Copy link
Owner Author

mjrusso commented Jan 1, 2022

Legibility is usually OK-ish, but far from perfect. (Help making this better is appreciated!)

Here's what HN looks like, for example...

Screen Shot 2022-01-01 at 10 30 48 AM

The combination of a small font size, with many unique anchors in close proximity, is problematic. It might make sense to ignore elements that are clustered too closely together (using size as a proxy for importance).

@mjrusso
Copy link
Owner Author

mjrusso commented Jan 1, 2022

Another issue: if the focused window in the frontmost app has a scroll view, and you pull up Scoot (in element-based nav mode), and then start scrolling (either using Scoot's keyboard shortcuts, or using your physical mouse or trackpad), the regions that Scoot has drawn won't update.

In the case where you're scrolling with Scoot, it should be possible to properly handle this. However, the latter might be a problem: are there any accessibility-related hooks to detect if the user is scrolling?

@mjrusso mjrusso merged commit 885030f into main Jan 1, 2022
@mjrusso mjrusso deleted the ax branch January 1, 2022 17:09
mjrusso added a commit that referenced this pull request Jan 1, 2022
As per #1, `⇧⌘J` now activates Scoot in
the element-based nav mode. This particular demo uses grid-based nav, which has
a new keyboard shortcut: `⇧⌘K`.
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant