#97·#99 사후 리뷰에서 나온 항목. 기존 동작이며 회귀가 아니다 — 다만 M-4가 도입한 .right/.bottom의 양방향 앵커와 일관성이 없다.
현상
WindowFrameWriter.anchoredOrigin의 .workAreaEdges 분기는 FrameCalculator.isConstrained로 게이트되는데, 이 술어는 앱이 목표보다 클 때만 true다. 따라서 앱이 목표보다 작게 잡히면 앵커 보정이 걸리지 않고 target.origin이 그대로 쓰인다.
작업영역 (0,25,1920,1055)에서 "Right 1/2" → target (960,25,960,1055), 앱이 너비를 700으로 제한하는 경우:
isConstrained(700x1055 vs 960x1055, tol 8) = false
→ origin은 target.origin (960,25) 그대로
→ 오른쪽 끝이 1660. 작업영역 오른쪽 1920에 붙지 않고 260pt 여백이 남는다
(anchorOrigin을 태웠다면 (1220,25) = flush right)
verify 후 재시도 패스도 크기를 다시 읽고 같은 else 분기를 타므로 여백이 그대로 유지된다.
영향 범위
.workAreaEdges를 쓰는 명령 — 스냅(snapThrow), 절대 배치, 최대화. 크기증분 앱은 한 셀 미만이라 8pt 허용오차 안에 들어가 보이지 않지만, 최대 크기가 제한된 앱에서는 여백이 임의로 커질 수 있다.
판단 필요
.right/.bottom처럼 양방향으로 바꾼다 — "Right 1/2"면 앱이 작아도 오른쪽에 붙는 게 사용자 기대에 가깝다. 단 스냅 동작 변경이라 제약 앱으로 make run 라이브 검증이 필요하다.
- 의도된 동작으로 두고 코드 주석/문서에 명시한다.
현재 WindowFrameWriter의 해당 주석은 "제약 앱이 목표보다 크게 머물면"이라고 단방향임을 이미 밝히고 있어, 최소한 의도는 문서화되어 있다.
#97·#99 사후 리뷰에서 나온 항목. 기존 동작이며 회귀가 아니다 — 다만 M-4가 도입한
.right/.bottom의 양방향 앵커와 일관성이 없다.현상
WindowFrameWriter.anchoredOrigin의.workAreaEdges분기는FrameCalculator.isConstrained로 게이트되는데, 이 술어는 앱이 목표보다 클 때만 true다. 따라서 앱이 목표보다 작게 잡히면 앵커 보정이 걸리지 않고target.origin이 그대로 쓰인다.작업영역
(0,25,1920,1055)에서 "Right 1/2" → target(960,25,960,1055), 앱이 너비를 700으로 제한하는 경우:verify 후 재시도 패스도 크기를 다시 읽고 같은
else분기를 타므로 여백이 그대로 유지된다.영향 범위
.workAreaEdges를 쓰는 명령 — 스냅(snapThrow), 절대 배치, 최대화. 크기증분 앱은 한 셀 미만이라 8pt 허용오차 안에 들어가 보이지 않지만, 최대 크기가 제한된 앱에서는 여백이 임의로 커질 수 있다.판단 필요
.right/.bottom처럼 양방향으로 바꾼다 — "Right 1/2"면 앱이 작아도 오른쪽에 붙는 게 사용자 기대에 가깝다. 단 스냅 동작 변경이라 제약 앱으로make run라이브 검증이 필요하다.현재
WindowFrameWriter의 해당 주석은 "제약 앱이 목표보다 크게 머물면"이라고 단방향임을 이미 밝히고 있어, 최소한 의도는 문서화되어 있다.