行のコントロールを「⋯」メニューに統一する #44 - #46
Merged
Merged
Conversation
The ⋯ replaces the always-visible ✕ (#21) on every block row, and holds うえへ / したへ / けす plus whatever the row adds — the if block's そうでなければ, which used to be a button of its own on the header, and the else divider's own "remove", so けす means the same thing wherever it is found. Long-press still opens the same menu, so the macOS right-click is unchanged. Deleting had three ways in and this was the redundant one. Moving a row had none a child would find: the menu it lived in only opens on long-press, and nobody presses a block hoping for a hidden menu. A visible ⋯ costs けす one tap and buys the reorder commands their first real affordance — children press what looks pressable. That is also 52pt of the widest row in the app back, which is where #44 started: an if header nested one level deep broke onto two lines on iPad, and a recursive block puts it there by construction. The wrapping itself turned out not to be about width at all. Widening the column changed nothing — measured, the content stayed at 236–564pt, because the canvas column's own ideal outranks it — and the reason is visible in the screenshot: 60pt of empty space sat beside the label, waiting for the menu button. An HStack hands space to its flexible children together, and a wrapping Text loses to a growing Spacer. So the label takes layoutPriority(1), and the chips are pinned with fixedSize, because serving the label first made 0.6 break as "0." over "6" instead. A row now compresses in a fixed order: the spacer, then the label, never a chip. Two levels deep with a long name the label still wraps, and that is accepted — each level of nesting costs 18pt, and no column width wins that race. The column keeps #23's widths. なら / then stays: it reads as the block was written, and the row fits with it. Fixes #44
A `Menu` hit-tests what it was handed to draw, so `touchTarget()` wrapped around the outside of one grows the layout and leaves the tappable area the size of the glyph. Every `Button` on a row wore it that way and was fine — a filled ✕ circle is a large shape by itself — and the ⋯ that replaced them is three dots on a thin band, which is how it came out as a control that misses taps. Painting the target in and measuring it does not catch this: the 44pt square is there either way, and only the touch is different. The glyph also takes imageScale(.large). It is the one control on the row now, so it can afford to be the one thing easiest to hit.
The ⑂ button carried a VoiceOver hint explaining what an "otherwise" mouth is, and moving the action into the menu left the string with no call site — Xcode marked it stale on the next build. What it explains is still worth saying, so the menu entry carries it now. Xcode goes on marking it stale even so, through a clean build and whether the hint is written as a literal or as a Text; the string is referenced, so the flag is bookkeeping rather than truth, and it is cleared here by hand.
The ⋯ was enlarged along with the touch-target fix, on the theory that a bigger shape would be easier to hit. The 44pt label turned out to be enough on device, so the glyph goes back to the default: at `.large` the dots sat heavier than the words beside them, and a control that is easy to hit does not also need to be the loudest thing on the row.
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
1 participant
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.
#44 の折り返し対応。決めてもらった 4 点（なら残す / 2 段ネストの折り返しは許容 / そうでなければ も同じ操作系へ / アイコンは
ellipsis）で入れています。入れたもの
More→ メニュー）実測で分かった、報告と違う点 2 つ
1. issue に書いた列幅の変更（min 360 / ideal 400）は効きませんでした。
適用して測ったところ、ワークスペースの内容幅は 236–564pt → 236–566pt でほぼ不変。キャンバス列の ideal（420）が先に取るため、ワークスペースは min に落ちるだけでした。なので #23 の幅（300 / 360 / 440）はそのままにしています。
2. そもそも幅不足ではありませんでした。
スクリーンショットを見ると、折り返している「も／し」の右に 60pt の空白があってメニューボタンを待っている。
HStackは柔軟な子（折り返せるText、伸びるSpacer）に幅を同時に配るので、ラベルが Spacer に負けていただけです。そこで:
BlockLabelStyleに.layoutPriority(1)— ラベルが先に幅を取る0.6が「0.」「6」に割れました。チップは数値・名前・色という分割不可能なものなので、WorkspaceChipButtonStyleに.fixedSize(horizontal: true, vertical: false)結果、**行の圧縮順が「スペーサー → ラベル → チップは絶対に折らない」**に固定されます。ラベルに
fixedSizeではなく priority を使ったのは、本当に幅が足りない 2 段ネストではブロックからはみ出すより折り返すほうがマシだからです（そこは許容と決めたとおり）。確認
swift test118 tests green / 両ビルド green /swift format lint --strictclean補足
App/Views/CLAUDE.mdに「行の可視コントロールはメニュー」「行の圧縮順」の 2 段落を追加しました。特に後者は、症状（折り返し）から素直に手を出す先（列幅）が外れであることが分かる形で残しています。Fixes #44