Expose live cursor state and remote cursor control for the Image Picker

What would you like to improve?

I would like Omarchy's Image Picker to expose a small, generic control and state interface for external input devices and automation.

I have a working prototype on a 2016 T1 MacBook Pro where the Touch Bar becomes a theme carousel while Omarchy's theme picker is open:

• Moving the cursor in the Omarchy theme picker moves the Touch Bar carousel to the same theme.
• Sliding the Touch Bar carousel moves the cursor in the Omarchy theme picker without applying the theme immediately.
• Confirming the centered Touch Bar item uses the picker's existing apply flow.
• Closing the theme picker restores the normal Touch Bar layout.

The prototype currently achieves this with a user-owned clone of omarchy.image-picker and a DFR-specific IPC/file bridge. It works, but that bridge is deliberately not suitable for upstream: it contains Touch Bar-specific target names, runtime filenames, and theme-path detection.

Rather than upstreaming that hardware-specific bridge, I would like to contribute a generic Image Picker contract that other integrations can reuse.

https://github.com/user-attachments/assets/d52129d8-e14c-4bd0-a21a-db726e2be9c0

Proposed generic contract

The existing image-selector IPC target could expose methods along these lines:

omarchy-shell image-selector state
omarchy-shell image-selector setCursor <path-or-name>
omarchy-shell image-selector apply

Example state response:

{
  "opened": true,
  "context": "theme",
  "cursorPath": "/home/user/.cache/omarchy/theme-selector/previews/kanagawa.png",
  "cursorName": "kanagawa"
}

Suggested behavior:

• state reports whether the picker is open and which item currently owns the cursor.
• setCursor performs an exact match against the currently loaded rows, moves the cursor, and does not apply or close the picker.
• apply reuses the existing applySelected() flow.
• Calls made while the picker is closed return a clear closed result.
• Unknown items return unknown and leave the current cursor unchanged.

An optional semantic context could be carried by the picker request, for example:

omarchy-menu-images --context theme ...
omarchy-menu-images --context background ...

This avoids external consumers identifying the picker type from cache-directory names. Third-party callers could use their own context values.

If the preferred architecture is to keep control on the plugin instead of extending the direct target, the same interface could be exposed through the existing plugin dispatcher:

omarchy-shell shell call omarchy.image-picker state ""
omarchy-shell shell call omarchy.image-picker setCursor "kanagawa"
omarchy-shell shell call omarchy.image-picker apply ""

I am happy to follow whichever IPC surface best fits the shell architecture.

Cursor change notifications

For external hardware, page-to-device updates should not require continuously launching polling processes. The local prototype atomically publishes the current cursor into $XDG_RUNTIME_DIR and the hardware daemon watches it.

For an upstream implementation, possible generic options are:

1. Expose only state first and let consumers poll it while the picker is open.
2. Atomically maintain a generic runtime state file such as $XDG_RUNTIME_DIR/omarchy/image-selector-state.json, which consumers can watch with inotify.
3. Use an existing Quickshell/Omarchy event mechanism if there is a preferred one I have missed.

I would appreciate guidance on which option maintainers prefer. The control methods are useful independently of the notification mechanism, so this could also be split into two small changes.

Why make this generic?

The Touch Bar is the first tested consumer, but the interface would also support:

• accessibility controllers;
• macro pads and programmable keyboards;
• touchscreen or mobile remote controls;
• hardware knobs and rotary encoders;
• shell extensions and local automation.

The Image Picker already has the necessary internal state and operations: opened, selectedIndex, currentPath(), select(), and applySelected(). This proposal would expose a narrow, validated surface around those existing behaviors rather than introduce a second selection model.

Scope and non-goals

This suggestion is only about the generic Omarchy Image Picker interface.

It would not add any of the following to the Omarchy repository:

• T1/T2 kernel drivers;
• a Touch Bar renderer or input daemon;
• systemd services;
• hardware detection or installation logic;
• DFR-specific runtime files or IPC names.

The hardware implementation would remain in its own GPL-licensed project. A future optional Omarchy installer integration could be discussed separately after packaging and broader hardware testing.

Prototype validation

The current local prototype has been tested with all 22 themes exposed by the Omarchy theme picker. The picker and Touch Bar use the same ordered theme set.

Verified interactions:

• keyboard/mouse picker changes update the centered Touch Bar item;
• Touch Bar drag changes update the picker cursor in both directions;
• rapid Touch Bar changes use latest-wins ordering;
• moving the cursor does not apply a theme;
• confirming the centered item uses the existing picker apply path;
• the Touch Bar theme layout is active only while the system theme picker is open;
• the background picker does not activate the theme layout.

A short demo recording and a public prototype branch can follow after the
hardware changes are split and the proposed upstream direction is confirmed.

Questions

1. Would maintainers be open to a generic live-state and cursor-control interface for omarchy.image-picker?
2. Should these methods live on the direct image-selector target or use shell call omarchy.image-picker ...?
3. Is polling state acceptable for the first PR, or would a generic runtime state file/event mechanism be preferred?
4. Would you prefer the optional picker context field in the same PR or as a separate follow-up?

If the direction sounds reasonable, I can prepare a focused PR with documentation, shell tests, and visual verification, without including any Touch Bar-specific code.