Skip to content

snap/absolute의 .workAreaEdges 앵커가 단방향 — 앱이 목표보다 작으면 모서리에 안 붙음 #100

Description

@pignuante

#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 허용오차 안에 들어가 보이지 않지만, 최대 크기가 제한된 앱에서는 여백이 임의로 커질 수 있다.

판단 필요

  1. .right/.bottom처럼 양방향으로 바꾼다 — "Right 1/2"면 앱이 작아도 오른쪽에 붙는 게 사용자 기대에 가깝다. 단 스냅 동작 변경이라 제약 앱으로 make run 라이브 검증이 필요하다.
  2. 의도된 동작으로 두고 코드 주석/문서에 명시한다.

현재 WindowFrameWriter의 해당 주석은 "제약 앱이 목표보다 크게 머물면"이라고 단방향임을 이미 밝히고 있어, 최소한 의도는 문서화되어 있다.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions