tui: the mouse can do everything the keys can - #38
Merged
Conversation
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
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DWtLsmAescX4Nb8QiBJd37
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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):
..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.? helpopens 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 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
-1for..) before the app hears about it, and the app'sfirstVisiblebookkeeping 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 realTuifrom 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