1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
# 035 — 한 네이티브 창에서 여러 문서를 선택하기
2026-09-24. 첫 공개 체크포인트의 문서 창은 CLI·HTTP·인증 피어와 같은
`editor.pure`를 실행했지만, 시작 인자로 받은 문서 키 하나에 묶여 있었다.
다른 작업물을 보려면 창을 새로 시작해야 했으므로 “작업물을 선택하고 편집하는
애플리케이션”의 사용 경험이 부족했다.
선택형 [`edit-window.c`](../../prototypes/connections/edit-window.c)에 문서 키 입력과
**Open · Ctrl+O**를 추가했다. 유효한 키를 열면 같은 `PureRuntime`과 작성된
`editor.pure` 경로로 읽는다. 없는 키는 빈 새 문서로 열고, 있으면 해당 버전과
본문을 채택한다. 읽기 결과를 확인하고 텍스트로 복사한 **뒤에만** 현재 키·
기준 본문·버전을 바꾼다. 따라서 잘못된 키, 읽기 실패, NUL/잘못된 UTF-8이
든 객체는 현재 문서를 대체하지 않는다. 문서 또는 `.pure` 정의의 초안이
수정된 상태라면 전환을 막아 둘 다 남긴다. 성공한 전환은 이전 문서의 출력
표시를 지우고 새 문서의 제목·상태를 갱신한다.
[실제 GTK 검사](../../prototypes/connections/results/2026-09-24-multi-document-window/gtk-flow-repeated.json)는
한 창에서 `first → second → third`를 열고 각 문서를 저장·복원한다.
두 번째 문서의 미저장 본문, 수정 중인 정의 초안, 잘못된 키, 바이너리 객체에서
현재 문서가 유지되는지 확인했다. 기존 외부 HTTP 충돌, 1 MiB 편집, 정의 적용·
실패·재시작 검사는 그대로 통과했다.
[ASan·UBSan 창 검사](../../prototypes/connections/results/2026-09-24-multi-document-window/gtk-asan-repeated.json)와
[선택형 혼합 저장소의 같은 UI 경로](../../prototypes/connections/results/2026-09-24-multi-document-window/hybrid-gtk-flow.json)도 확인했다.
## 비용과 배포
작업 접수·메모리 수명·효과 실행의 공통 코어는 바꾸지 않았다. 기본 CLI도
그대로다. 선택형 GTK 창의 링크된 `text`는 앞선 48,247 B에서 **49,882 B**로
1,635 B 증가했고, 기존 56 KiB 상한과 직접 의존성 검사를 통과했다.
[코드·의존성 결과](../../prototypes/connections/results/2026-09-24-multi-document-window/window-profile.json).
1 MiB 문서를 연 창의 단독 실행 RSS 표본은 **43,920 KiB**였다. 그러나 같은
창에서 두 개의 1 MiB 문서를 64회 번갈아 열자 RSS가
**58,752 KiB**까지 증가했다.
[8회 간격 원자료](../../prototypes/connections/results/2026-09-24-multi-document-window/switch-memory-initial.json).
이 증가는 이 작업에서 측정한 프로세스 RSS다. 후속
[메모리 분리 실험](036-gtk-memory-boundary.md)에서는 증가가 힙에 집중되고
텍스트 뷰 갱신을 생략한 진단 빌드에서 사라졌다. 정확한 GTK 내부 객체와
반환 시점은 아직 확인하지 못했다. GTK 문서에 따르면 `GtkTextBuffer.set_text()`는
[실행 취소 이력에 남지 않는 교체](https://docs.gtk.org/gtk4/method.TextBuffer.set_text.html)다.
이전 버퍼를 매번 새 것으로 바꾸는 실험도
[증가를 없애지 못해](../../prototypes/connections/results/2026-09-24-multi-document-window/switch-memory-fresh-buffer.json)
되돌렸다. `GtkTextView.set_buffer()`는 [이전 버퍼의 참조를 놓는다](https://docs.gtk.org/gtk4/method.TextView.set_buffer.html).
따라서 이 창을 저메모리 UI의 근거로 삼지 않는다. 기본 코어·CLI의 기존
크기·메모리·동작 검사 `make check-release`는 통과했다.
[창 선택 묶음](../../prototypes/connections/results/2026-09-24-multi-document-window/pure-document-window-final-linux-aarch64.tar.gz)은
49,746 B다. [다른 위치에 풀어 재검사한 결과](../../prototypes/connections/results/2026-09-24-multi-document-window/package-repeated.json)에는
문서 전환 검사도 포함된다. 패키지 매니페스트는 이 창 기능을 명시한다.
예전 창 묶음에는 해당 표시가 없으므로 현재 검사기는 그 묶음에 새 기능을
요구하지 않는다. [보관된 창 묶음 재검사](../../prototypes/connections/results/2026-09-24-multi-document-window/legacy-package-repeated.json)가
통과했다.
이것은 문서 탐색의 첫 경로다. 아직 키를 직접 입력해야 하고, 목록·검색·메타데이터
인덱스가 없다. 여러 문서의 원자적 변경도 제공하지 않는다. 현재 작성 언어는
`get`/`put`의 단일 저장 효과에 국한되고 동기 저장 작업은 GTK 이벤트 루프를
막을 수 있다. 이 상태를 큰 서비스용 애플리케이션 런타임이라고 부르지 않는다.
다음 구현은 위 실제 앱에서 필요한 다중 객체 탐색·갱신의 의미와 비용을 먼저
정하고, 그 요구를 실행 모델에 통합해야 한다. 선택형 창을 확장하기 전에는
[반복 텍스트 교체의 메모리 증가](036-gtk-memory-boundary.md)도 해결하거나
더 작은 UI 어댑터에서 같은 사용 경험을 검증해야 한다. 단순히 버튼을 더
붙이는 것은 그 빈칸을 채우지 못한다.
재현 명령은 `make -C prototypes/connections window check-window-profile`과
`xvfb-run -a python3 prototypes/connections/check_window.py --build
prototypes/connections/build --program prototypes/connections/examples/editor.pure`다.
64회 메모리 관찰에는 마지막 명령에 `--switch-rounds 64`를 추가한다.
|
