ClickAble for Omarchy

If you can point, you should be able to click.

ClickAble turns a deliberate pointer pause into a click. It is built for people who can position a pointer with an eye tracker, head tracker, trackball, mouse, or other device but cannot press a button reliably or comfortably.

Release status: This branch is a release candidate, not a production-approved release. Portable validation is green, but the exact published commit must pass the real-desktop checklist on recorded Omarchy and Hyprland versions before production use or marketplace submission.

Arm it once with an accessible key, external switch, keyboard navigation, or a conventional click. After that, the pointer can click and can dwell on the ClickAble bar widget to Pause. Users who cannot produce any conventional click need the single-key or switch setup before ClickAble can be their click path.

Move to a target. Hold still. A ring shows the countdown. ClickAble clicks once, then waits for you to move away before it can click again.

What it does

• Performs an ordinary left click after a visible dwell countdown.
• Offers one-shot right and double clicks, then returns to left click.
• Cancels non-positional activity detected while the pointer is stationary and pointer movement beyond the selected tolerance; small involuntary motion can preserve progress, but a click still waits for a quiet input interval.
• Requires movement after arming and after every click, preventing click loops at a resting pointer.
• Suspends on observed Omarchy lock and desktop-scene changes and performs an immediate lock-state preflight before every dwell action.
• Pauses on helper, protocol, or uncertain click failures.
• Shows one unmistakable armed/paused state in the Omarchy bar.
• Works without administrator privileges, virtual input devices, a background daemon, or Hyprland configuration changes.

ClickAble starts paused every time it loads. It never remembers an armed state across a shell restart, plugin reload, or login.

Try it

Omarchy plugins run inside the long-lived shell without a sandbox, so review this repository before installing it.

omarchy plugin add https://github.com/josephbriones/omarchy-clickable.git --enable
omarchy-shell clickable demo

The deterministic demo exercises the same state machine and countdown without sending a click to Hyprland.

Use it

Open the ClickAble bar control and choose Arm ClickAble. The initial move-away guard is intentional: move the pointer once after arming, then settle over the target you want.

The control popup follows Omarchy's keyboard pattern: Tab or arrow keys move between controls, Enter or Space activates one, and Escape or Close controls dismisses the popup.

The normal cycle is deliberately short:

1. Move to a target.
2. Hold still while the ring completes.
3. ClickAble sends one click.
4. Move away before another dwell can begin.

Choose the next action before arming. Left stays selected. Right and double are one-shot actions: dwell on the target and ClickAble returns to left after the requested click succeeds. A safety fault also returns to left instead of silently retrying an uncertain action.

Dwell on the ClickAble bar widget while it is armed to pause it. Left, right, and double dwell modes all take this emergency-stop path before the bar considers opening its controls. A keyboard, switch, or script can use the same service directly:

omarchy-shell clickable toggle
omarchy-shell clickable arm
omarchy-shell clickable pause
omarchy-shell clickable left
omarchy-shell clickable right
omarchy-shell clickable double
omarchy-shell clickable state

These commands make it practical to bind Arm/Pause to one accessible key or external switch without requiring a chord.

Deliberately small

ClickAble is a dwell clicker, not a replacement input stack.

• No drag, scroll, hover menu, target snapping, or on-screen keyboard in the 0.1 candidate.
• No continuous desktop capture, accessibility-tree inspection, key logging, or text collection.
• No kernel input injection, device rule, elevated service, native Hyprland extension, or automatic configuration edit.
• No automatic arming, hidden autostart state, analytics, account, or network request.

The narrow scope is a safety decision. A simple click that users can predict is more useful than a long feature list they cannot trust.

Privacy

While armed, ClickAble asks the local Hyprland session for the pointer position and lock state. Omarchy's idle monitor reports only whether user input occurred; ClickAble does not receive the key, button, or text involved. Coordinates and countdown state remain in memory and are discarded when paused or stopped.

Only bounded presentation preferences are retained. ClickAble creates no click history, pointer trail, screenshot, recording, analytics event, or network request. Privacy documents the exact boundary.

Compatibility and limits

ClickAble targets current Omarchy Quattro and its Hyprland integration. The click is delivered to the Wayland surface currently under the real pointer. Native Wayland and XWayland behavior must be verified on the exact recorded target versions because compositor input semantics can change.

Lock protection is a best-effort immediate preflight, not an atomic compositor guarantee. The worker checks j/locked and then sends the fixed click in a separate local socket request. A lock transition can begin after the unlocked response and before Hyprland receives the dispatch; the shell guard and final pending-input check narrow that residual interval but cannot eliminate it. Acceptance on the exact recorded Omarchy and Hyprland versions must exercise this transition repeatedly, and ClickAble must not be the only safeguard for sensitive or safety-critical input.

Some protected surfaces or applications may reject synthetic clicks. Double click uses one lock preflight followed by two bounded, complete press/release click requests. A lock can begin before or between those requests; if the second dispatch cannot be confirmed, ClickAble fails closed and requires movement before another attempt. Do not rely on ClickAble as the only control for a safety-critical operation.

Omarchy's idle signal reports activity, not which device caused it. ClickAble infers stationary activity as a key or manual button and cancels the dwell. If that input coincides with small pointer jitter, it can be treated as tolerated pointer motion instead; dispatch still remains blocked until the input stream is quiet. This tradeoff needs calibration with the user's actual pointer source.

The testing guide separates portable evidence from real desktop acceptance. The repository does not claim that an unchecked hardware gate passed.

Remove it

Pause ClickAble, then use Omarchy's normal removal path:

omarchy plugin remove io.github.josephbriones.clickable

Removal leaves the small preference file alone. It contains no pointer coordinates or click history.

Development

Run the portable and repository suite:

bash scripts/validate.sh

CI also runs the official Omarchy manifest validator and qmllint against a pinned current Omarchy tree. Real pointer targeting, mixed-scale displays, assistive devices, lock transitions, and shell-reload cleanup remain explicit Omarchy acceptance gates.

The architecture explains the fail-closed state machine. Security describes the threat model and private reporting path.

License

MIT © 2026 Joseph Briones.