Skip to content

tui: the mouse can do everything the keys can - #38

Merged
ralyodio merged 2 commits into
mainfrom
worktree-tui-mouse
Sep 12, 2026
Merged

tui: the mouse can do everything the keys can#38
ralyodio merged 2 commits into
mainfrom
worktree-tui-mouse

Conversation

@ralyodio

Copy link
Copy Markdown
Contributor

The TUI's panes registered click and wheel regions, and that was the whole of it: a click could move the cursor and nothing else. Every directory still had to be entered with a key, every key cap in the footer was a label, the picker's rows and the dialogs' buttons were pictures, and a directory could only be left with the left arrow.

Now, on hqtui 0.5.0 (profullstack/hqtui#86, released as v0.5.0 for this):

  • Double-click opens a directory, and a .. row sits above every listing that has a parent, so the way up is on screen. It stays there when a listing failed, because the way out of an unreadable directory must not be keyboard-only. A single click on .. does not move the cursor: there is nowhere on it for the cursor to rest.
  • Every key cap in the footer is a button for its action, and the header's direction switches panes while ? help opens the help. A click runs the same private method the key does, under the same rules: a dialog owns the input while it is up, and a running transfer takes nothing but cancel and quit, which is what the footer shows while one runs.
  • The endpoint picker chooses a server on one click; a click outside closes it, as it does the help, which also has a close button now. The host-key question answers from its two buttons and from nothing else.
  • A finished transfer is dismissed by clicking its panel. A running one is deliberately not cancelled that way; cancel stays on the key bar, spelled out.
  • A click on a pane's border, title or empty space focuses it, and a click clears the last message the way a key does.

The row-to-entry arithmetic moved out of the app into the frame: the view resolves a clicked screen row to an index into the visible entries (or -1 for ..) before the app hears about it, and the app's firstVisible bookkeeping is gone.

All of it is asserted by clicking on the rendered frame through hqtui's new test-screen click(), which runs the same hit-test the app does. The view tests click every key cap, both dialogs and ..; the interaction tests drive the real Tui from a click to a changed path, a pointed pane and a quit.

Verified: pnpm build, pnpm -r typecheck, pnpm test (619 tests, 78 in the TUI) against the published @profullstack/hqtui@0.5.0.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DWtLsmAescX4Nb8QiBJd37

ralyodio and others added 2 commits September 12, 2026 19:22
The panes registered click and wheel regions, and that was the whole of it: a
click could move the cursor and nothing else. Every directory still had to be
entered with a key, every key cap in the footer was a label, the picker's rows
and the dialogs' buttons were pictures, and a directory could only be left
with the left arrow. Someone with a hand on the mouse was stuck on the first
screen.

Now, on hqtui 0.5.0's click hooks:

- A double-click opens a directory, and a `..` row sits above every listing
  that has a parent, so the way up is on screen. It stays there when the
  listing failed, because the way out of an unreadable directory must not be
  keyboard-only. `..` is one frozen object that never enters a pane's entries,
  so sorting, filtering and the cursor index never see it, and a single click
  on it does not move the cursor: there is nowhere on `..` for it to rest.
- Every key cap in the footer is a button for its action, and the header's
  direction switches panes while `? help` opens the help. A click runs the
  same private method the key does, under the same rules: a dialog owns the
  input while it is up, and a running transfer takes nothing but cancel and
  quit, which is what the footer now shows while one runs.
- The endpoint picker chooses a server on one click, since it is a menu; a
  click outside closes it, as it does the help, which also has a close
  button now. The host-key question answers from its two buttons and from
  nothing else: a fingerprint is not something a stray click decides.
- A finished transfer is dismissed by clicking its panel. A running one is
  deliberately not cancelled that way; that stays on the key bar, spelled out.
- A click on a pane's border, title or empty space focuses it, and a click
  clears the last message the way a key does.

The row-to-entry arithmetic moved out of the app and into the frame: the
table reports the screen row a click landed on, and only the frame that drew
the table knows where its window started, so the view resolves it to an
index into the visible entries (or -1 for `..`) before the app hears about
it. The app's firstVisible bookkeeping is gone with it.

All of this is asserted by clicking on the rendered frame through hqtui's new
test-screen `click()`, which runs the same hit-test the app does: the view
tests click every key cap, both dialogs and `..`; the interaction tests drive
the real Tui from a click to a changed path, a pointed pane and a quit.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWtLsmAescX4Nb8QiBJd37
@ralyodio
ralyodio merged commit 543da6b into main Sep 12, 2026
4 checks passed
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