From cec73010d34937d75c01d37a5c50b4cf603a6791 Mon Sep 17 00:00:00 2001 From: Jaap-Jan de Wit | DodoTech Date: Wed, 12 Aug 2026 10:43:37 +0200 Subject: [PATCH] Colour the window's frame, inset Hosts like its neighbours, drop Pins MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Three things one pass over the shell's chrome turned up, none of them related to the others beyond having been looked at together. ◆ A PALE STRIP ACROSS THE TOP OF THE WINDOW ON WINDOWS, and it is not this application's titlebar. Avalonia's Win32 backend gives a BorderOnly window WS_BORDER | WS_THICKFRAME and then calls DwmExtendFrameIntoClientArea with one-pixel margins on all four sides — read out of WindowImpl.UpdateWindowProperties in 12.1.1 rather than guessed at. So DWM owns a hairline of every edge and fills it with the system's caption and border colours, which follow the user's personalisation settings: with "show accent colour on title bars and window borders" on, that is blue against a near-black shell. Nothing in the visual tree painted those pixels, which is why nothing in the visual tree could cover them. NativeWindowFrame sets DWMWA_BORDER_COLOR and DWMWA_CAPTION_COLOR to the window's own Background, so the hairline still exists — the resize grip is on it, the drop shadow hangs off it — and cannot be seen. Deliberately not DWMWA_COLOR_NONE, which removes the border outright and leaves a near-black window with no edge at all on a dark desktop. Windows 10 gets the dark-mode attribute and nothing else, because the two colour attributes are Windows 11 and DwmSetWindowAttribute simply answers E_INVALIDARG there. Called from OnOpened, not the constructor: there is no platform handle until the window is shown, and calling early is a silent no-op — which looks exactly like a fix that does not work. Verified on screen on Windows 11. ◆ THE HOSTS HEADER SAT A STEP LEFT OF AND ABOVE EVERY OTHER SCREEN'S. Keychain, Snips, Logs and Pins all frame their content with Margin="26"; Hosts was on 16 a side and 20 on top. It is 26 all round now, stated per row rather than once on the root, because the board's ScrollViewer is deliberately full-bleed so that its scrollbar rides the pane's edge, and because a root margin would also inset the drawer, which draws its own. That cost the cards ten pixels, and the layout suite is what said so: TheHostsGridKeepsTwoColumnsAtTheMinimumWithTheDrawerOpen failed, because Border.tile's 224 was derived from the board's old 16-pixel margins and the grid quietly collapses to one column at exactly the size this application guarantees. 224 becomes 214, with the arithmetic in App.axaml rewritten — it had also gone stale in a way that hid itself, still citing the 1016 minimum and 190 rail from before v5b, whose two changes happened to cancel. ◆ PINS LEAVES THE RAIL, and only the rail. KnownHostsScreen is still built and still one click away, from "Host keys" on the Keys screen's own header, which was always the second way in. The row was kept through v5b on the grounds that the mock has no screen for approved host keys — a reason for the screen to exist, and never a reason for a rail entry once the keychain had a door to the same place. Two rows landing on one screen is a rail that has to be read twice. MainWindowViewModel.IsKnownHostsShowing stays: it names a real shell state and ShellFlowTests still asserts on it. design-import-gaps.md recorded that row as a deliberate deviation and manual-checks.md Phase 1.1 walked the rail entry by entry; both are corrected, and the manual check now reaches the screen the way a user would. The layout suite's rail row count moves from six to five with it. 153 layout tests and 446 shell tests pass. The frame is confirmed by eye; the Hosts inset and the rail are covered by the layout suite but were not seen running, because the instance launched to check them came up locked. --- docs/design-import-gaps.md | 2 +- docs/manual-checks.md | 5 +- src/DodoSSH.Client.App/App.axaml | 36 +++-- .../Views/HostsScreen.axaml | 20 ++- .../Views/MainWindow.axaml.cs | 15 ++ .../Views/NativeWindowFrame.cs | 133 ++++++++++++++++++ src/DodoSSH.Client.App/Views/NavRail.axaml | 30 ++-- .../ScreenLayoutTests.cs | 13 +- 8 files changed, 212 insertions(+), 42 deletions(-) create mode 100644 src/DodoSSH.Client.App/Views/NativeWindowFrame.cs diff --git a/docs/design-import-gaps.md b/docs/design-import-gaps.md index c497ccc..cf20d6c 100644 --- a/docs/design-import-gaps.md +++ b/docs/design-import-gaps.md @@ -300,7 +300,7 @@ the chrome, hosts and terminals, file transfer, the vault, teams, and preference > | The status bar's negotiated cipher, host-key algorithm and key/credential name | ◆ **Shipped, on both surfaces, with three honest deviations.** `ISshConnection` and `ISftpSession` now both carry `Cipher` — the server-to-client algorithm off SSH.NET's own `ConnectionInfo.CurrentServerEncryption`, captured once at construction because a rekey is not an event SSH.NET raises — and `TerminalWorkspace.GetSessionFacts` hands the cipher and the host key's algorithm back to the shell the moment a session opens; `VaultViewModel.TryBuildAuthentication` now threads the authenticating key's or credential's own `Label` into `HostAuthentication.IdentityLabel`, all the way to `MainWindowViewModel`'s surface-aware `SessionCipher`, `SessionHostKeyAlgorithm` and `SessionIdentityLabel`, composed into one `SessionIdentityText` run for the status bar. Three deviations from the mock, not omissions: the algorithm prints exactly as negotiated (`ssh-ed25519`), not the design's shortened `ed25519`, because trimming it would be an edit to a string this client did not choose; the run is plain text rather than the design's clickable element, because there is no pin-details modal for a session that is already open, and drawing a click target for a screen that does not exist would itself be a fabrication; and a typed-password session — nothing filed in the keychain to name — shows the host-key algorithm alone, with no `·` after it, because there is no item behind the dot. | > | S3 dimmed in the design's own switcher | **Enabled.** The mock leaves S3 as future work; this application already has bucket browsing, so SSH, SFTP and S3 are a true three-way segment, wired to `IsSshShowing`, `IsTransfersShowing` and `IsBucketsShowing` exactly alike. | > | The S3/Buckets screen | **Did not get the session shell in v5b.** `TransfersScreen` serves both SFTP and S3 today and only the SFTP usage in `MainWindow.axaml` sat inside the new tab row/header/status bar/sidebar; the S3 usage was unchanged at the time. **v5c gives it the shell's own look without the machinery** — a 26-pixel padded, bordered, radius-12 container and nothing past that, since a bucket has no tab to close, no host to head a card with and no pin for a sidebar to show; see the v5c section, below. | -> | No pins destination in the design at all | **Kept anyway.** The rail still carries Pins — `KnownHostsScreen` — because the mock has no screen for approved host keys and this application's has to stay reachable. | +> | No pins destination in the design at all | **The rail agrees with the design now.** `KnownHostsScreen` is still built and still reachable — from **Host keys** on the Keys screen's own header, which was always the second way in — but the rail's Pins row is gone. It was kept through v5b on the grounds that the mock has no screen for approved host keys, which is a reason for the screen to exist and was never a reason for a rail entry once the keychain had a door to the same place. Two rail rows landing on one screen is a rail that has to be read twice. | > | The popover's Settings and Preferences rows, and the design's own Settings-* family of screens | **Landed in v5c.** What was two doors to one room in v5b — Settings and Preferences both opening the same bare `Preferences` screen — is now two of three doors onto their own settings pages: Settings opens General, Preferences opens Preferences, and a third row, Vaults, opens Vaults. All three are real, distinct pages inside one settings mode; see the v5c section, below. | > | `· Org` after the user chip's name, and a `Primary` tag on a vault row in the popover | Neither. There is no organisation concept behind a vault — only the vault itself — and no vault is distinguished as primary; the popover's vault rows are the existing shown-vaults toggles, restyled. | > | The design's titlebar, which has nowhere for a sync indicator | `SYNCED` stays, on the titlebar's right side, ahead of the window's own minimise/maximise/close buttons — the one thing this titlebar keeps that the design's own does not draw at all. | diff --git a/docs/manual-checks.md b/docs/manual-checks.md index ea206ea..79d1c21 100644 --- a/docs/manual-checks.md +++ b/docs/manual-checks.md @@ -28,8 +28,9 @@ a phase had nothing left for a person to do, which is the good outcome rather th ### 1.1 No screen is sliced at the WebView's left edge · **the important one** -Open two terminals, then visit every nav rail entry in turn — Hosts, Keys, Pins, Snips, Logs — and both of -the switcher's other two segments, SFTP and S3, at the rail's own head. +Open two terminals, then visit every nav rail entry in turn — Hosts, Keys, Snips, Logs — and both of +the switcher's other two segments, SFTP and S3, at the rail's own head. The pins screen is no longer a rail +entry; reach it from **Host keys** on the Keys screen's header and check it the same way. **Pass:** each screen draws whole, its buttons all clickable, and the nav rail stays up the left edge for every one of them. Since v5b's chrome pass the rail is permanent furniture — it no longer collapses for diff --git a/src/DodoSSH.Client.App/App.axaml b/src/DodoSSH.Client.App/App.axaml index 68240a2..cd07129 100644 --- a/src/DodoSSH.Client.App/App.axaml +++ b/src/DodoSSH.Client.App/App.axaml @@ -913,18 +913,30 @@ into a grid: equal columns, and a card that grew a third line of tags is taller than its neighbours rather than narrower. - ◆ 224 IS DERIVED, and the arithmetic is written out because getting it wrong is invisible. The grid's - column at the window's minimum is 1016 less the rail's 190 and the drawer's 320, which is 506. The - scrolling stack inside it takes 16 of margin on each side, and the vertical scrollbar takes its own — - call the usable width 474. A WrapPanel fits floor(474 / (Width + 10)) per row, so two columns needs - Width no more than 227. + ◆ 214 IS DERIVED, and the arithmetic is written out because getting it wrong is invisible. The grid's + column at the window's minimum is 1081 less the rail's 255 and the drawer's 320, which is 506. The + scrolling stack inside it takes 26 of margin on each side, and the vertical scrollbar takes its own — + call the usable width 454. A WrapPanel fits floor(454 / (Width + 10)) per row, so two columns needs + Width no more than 217, and 214 is that with the same few pixels of slack the previous number kept. - The first number here was 248, from the same reasoning with the two margins left out. It laid out - cleanly and the layout harness passed it, because the harness asks whether a control is inside the - window and not how many of them fit on a line — so the grid quietly became one column wide at exactly - the size this application guarantees, which is the shape the cards exist to avoid. The second was 232, - derived the same way against the drawer's own 304; v5 widened the drawer to 320 for the ADDRESS field's - breathing room, which narrowed the budget this number is drawn from and had to move it down in step. + Every number here has moved at least once, and always because something beside the cards did: + + · 248, from this reasoning with the two margins left out. It laid out cleanly and the layout harness + passed it, because the harness asks whether a control is inside the window and not how many of them + fit on a line — so the grid quietly became one column wide at exactly the size this application + guarantees, which is the shape the cards exist to avoid. + · 232, derived against the drawer's own 304, which v5 widened to 320 for the ADDRESS field's breathing + room — narrowing the budget this number is drawn from and moving it down in step. + · 224, which is what that gave. The stated arithmetic still said 1016 and 190 by then: v5b's rail took + 190 to 255 and the window's minimum 1016 to 1081 in the same pass, so the two changes cancelled and + the answer stayed right while the working went stale. + · 214, now that HostsScreen's board is inset 26 a side rather than 16 — see that file's own remark on + why every screen frames its content the same way. Twenty pixels of board is twenty pixels the cards + no longer have, and this is where they come from. + + ◆ THE TEST THAT CATCHES THIS IS NOT THE HARNESS. See + ScreenLayoutTests.TheHostsGridKeepsTwoColumnsAtTheMinimumWithTheDrawerOpen, which counts columns + because that is the thing this number exists to buy and the thing no fit assertion can see. -->