Per-app profiles

Per-app profiles let OpenLogi swap a device's button bindings automatically based on the target app. Mouse profiles follow the app under the pointer by default; keyboard profiles follow the focused app. The target app's sparse overlay is layered on top of the device's global bindings, with per-app entries winning and any unlisted button falling through to the global map. The Actions Ring follows the focused app and selects a complete layout rather than an overlay. DPI presets, scrolling, and lighting stay device-wide.

Choosing the mouse target

In Settings → General → Mouse button profiles, choose Mouse pointer (the default) or Focused application. The same preference is stored in config.toml:

[app_settings]
mouse_profile_target = "pointer" # Or "focused".

Pointer targeting works on macOS, Windows, and X11. When the pointer is over the desktop, OpenLogi uses the device's global bindings. Unsupported sessions, including Wayland, use the focused app. Existing configs that omit this preference also use pointer.

OpenLogi does not focus a background window to send a shortcut. With pointer targeting, mouse bindings that produce keystrokes or run workflows are skipped unless the window under the pointer has focus. Global actions, such as switching desktops, can run without changing focus. A temporary failure to identify the pointer target is not treated as hovering over the desktop.

App identifiers

The identifier is whatever the platform reports for the target app, and it must match a config key exactly except for the documented Windows exe: fallback; there is no wildcard or pattern matching.

On Windows an exact path entry wins when both forms exist, so exe: is the stable fallback for Store apps and self-updating installs whose path moves.

From the GUI

Select a mouse, open Buttons, and use the Profile bar above the editor:

1. Default edits the device-wide bindings.
2. Add App first offers applications the agent has recently observed in the foreground. All Applications expands a searchable installed-app catalog. An observed identifier is the safest choice because it is exactly what the runtime will match; an installed-app identifier is a platform-specific best effort, particularly on Linux.
3. Pick an app and change only the buttons that should differ. Inherited buttons are marked as inherited from Default. Use the Default profile removes an override for that button; removing the whole profile restores every inherited binding.

Selecting an app does not create an empty profile on disk. Its first changed button creates the sparse overlay. Runtime switching remains automatic and does not depend on which profile the editor has open.

Authoring overlays

Add a table under [devices.<key>.per_app_bindings."<app-id>"] holding a partial button → action map. Buttons you list override the global binding while that app is the selected mouse or keyboard target; buttons you omit keep their global value.

[devices."unit:6be9d300".bindings]
Back = "BrowserBack"
Forward = "BrowserForward"

# While VS Code is the target app, Back becomes Undo and Forward becomes Redo.
[devices."unit:6be9d300".per_app_bindings."com.microsoft.VSCode"]
Back = "Undo"
Forward = "Redo"

Values are action names written verbatim. The overlay only adds or overrides keys; it never removes one, so to make a button do nothing in a given app set it to None rather than omitting it. A per-app overlay always maps a button to a single action; per-direction gesture maps and short/long pairs stay device-wide. Overriding a gesture-capable button with one action disables its swipe directions in that app; clear the override to inherit the global gesture map again. The per-app editor therefore offers the single-action picker, not gesture-mode controls.

Status: macOS, Linux, and Windows. On Linux the identifier depends on the session backend (X11 / XWayland, GNOME Shell, or a wlroots compositor); a session with none of those available reports no app and everything falls back to the Default profile. App detection uses operating-system APIs, not a HID++ feature; the same sparse tables remain editable in config.toml.