feat(app): 활성 창 캡쳐·캡쳐 목적지 선택·단축키 Ctrl+Alt 재배치 + UX 손질
- Ctrl+Alt+A/Z 맨 앞 창 통째 캡쳐(DWM 확장 프레임 경계), S/X 드래그 캡쳐. A/S 새 대화, Z/X 마지막 대화 - 캡쳐 후 창을 확실히 앞으로(AttachThreadInput), capture.image 에 목적지 path 실어 그 Composer 만 소비 - 드래그 선택영역 원본 밝기·더블버퍼(번쩍임) — code-assistant-v2 복사본에서 이식 - 단축키 Ctrl+Alt+Q/W: Eclipse·ADT·SAP GUI 바인딩 목록 대조해 비어 있는 조합으로 - 버튼 cursor:pointer(Tailwind v4), 가운데 스피너, 스니펫→챗 버튼, 스니펫 검색창 높이 84→88 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Fable 5.1
parent
2869985139
commit
47d31dbe06
@@ -0,0 +1,20 @@
|
||||
# 2026-09-17 단축키는 왼손 한손으로
|
||||
|
||||
## 원문
|
||||
|
||||
> 단축키를 숫자로 하지말고 왼손 한손으로 끝내고 싶음. 지금은 컨트롤 쉬프트는 왼손 숫자는 오른손이라 불편함
|
||||
|
||||
## 왜 틀렸나
|
||||
|
||||
`Ctrl+Shift+7/8/9` 는 왼손으로 modifier 잡고 오른손으로 숫자 눌러야 해서 두 손이 필요함. SAP GUI·Eclipse 에서 마우스 잡은 채로 호출하는 게 이 앱의 핵심 흐름이라, 한손(왼손)으로 끝나야 함.
|
||||
|
||||
## 앞으로
|
||||
|
||||
- 전역 단축키는 **왼손 범위 글자**(Q W E R A S D F Z X C V)만 씀. 숫자·오른손 글자 금지.
|
||||
- modifier 는 `Ctrl+Alt`. 2026-09-17 실제 목록으로 확인한 결과:
|
||||
- `Ctrl+Shift+글자`: Eclipse/ADT 가 거의 다 씀(A 오브젝트 열기, R/E/W/F/L/G…).
|
||||
- `Alt+Shift+글자`: 역시 Eclipse 가 씀 — A 블록선택, S Source, W Show In, Z Surround With, X Run As, D Debug As, R Rename, T Refactor, Q Show View. SAP GUI 도 Alt+Shift+V(디버거 변수).
|
||||
- `Ctrl+Alt+글자`: Eclipse 는 G/H/M/N/B 만, SAP GUI 는 L/M/P 만 씀 → Q/W/A/S/Z/X 는 비어 있음.
|
||||
- 새 키 잡을 땐 Eclipse 에서 `Ctrl+Shift+L` 로 실제 바인딩 목록 보고 겹치는지 확인할 것. 기억으로 판단 금지.
|
||||
- 현재 배정: `Ctrl+Alt+Q` 스니펫 / `Ctrl+Alt+W` 챗 토글 / `Ctrl+Alt+A` 맨 앞 창 캡쳐→새 대화 / `Ctrl+Alt+S` 드래그 캡쳐→새 대화 / `Ctrl+Alt+Z` 맨 앞 창 캡쳐→마지막 대화 / `Ctrl+Alt+X` 드래그 캡쳐→마지막 대화. 윗줄 = 여는 것, A/S = 새 대화에 찍기, Z/X = 기존 대화에 찍기.
|
||||
- 진실원천은 `4_rust_tauri/src-tauri/src/lib.rs` 의 `HOTKEYS`. 새 단축키 추가할 때도 이 규칙 따름.
|
||||
@@ -0,0 +1,25 @@
|
||||
# 캡처가 뒤쪽 창에 붙고 대상 대화를 고를 수 없음
|
||||
|
||||
## 증상
|
||||
|
||||
- 새 대화 화면이 이미 열려 있어도 캡처 완료 뒤 CodeAssist가 앞으로 오지 않고 뒤에서 이미지만 첨부됐음.
|
||||
- 캡처 이미지는 항상 새 대화로 보내져 기존 대화에 붙일 방법이 없었음.
|
||||
|
||||
## 원인
|
||||
|
||||
- 캡처 완료 흐름이 `window.show()`와 Tauri `set_focus()` 결과에만 기대고 있었음. Win32 캡처 오버레이가 닫힌 뒤 외부 앱이 다시 foreground를 가져가면 이미 보이는 CodeAssist 창의 활성화가 보장되지 않았음.
|
||||
- native 흐름이 대상 route를 무조건 `/snap/new`로 보냈음.
|
||||
- 프론트의 pending 캡처는 대상 route 정보가 없어 `NewChatPage`만 소비하도록 막아둔 상태였음.
|
||||
|
||||
## 수정
|
||||
|
||||
- 창을 소환할 때 현재 입력 thread를 foreground 입력 thread에 잠시 연결하고 Win32 `BringWindowToTop`, `SetForegroundWindow`, `SetFocus`로 메인 창을 직접 활성화함.
|
||||
- `Ctrl+Shift+9`는 새 대화, `Ctrl+Shift+0`은 마지막 기존 대화를 대상으로 함. 기존 대화가 없으면 새 대화로 대체함.
|
||||
- `capture.image`에 대상 `path`를 추가하고, path가 같은 Composer만 pending 이미지를 소비하게 바꿈.
|
||||
|
||||
## 확인
|
||||
|
||||
- 대상 route 선택과 route별 pending 소비 회귀 테스트를 RED→GREEN으로 확인함.
|
||||
- frontend 전체 217개 테스트, lint, build와 Rust 13개 테스트, build를 실행함.
|
||||
- 데스크톱 앱에서 `/snap/new` 도착과 캡처 첨부 노출을 확인함.
|
||||
- 자동화 환경이 Windows 창 focus 전환을 지원하지 않아 외부 앱 위로 실제 foreground가 바뀌는 장면은 자동 확인하지 못했음. 해당 한 항목은 실제 단축키 수동 확인이 남음.
|
||||
@@ -0,0 +1,25 @@
|
||||
# 캡처 선택 영역이 드래그 중 번쩍임
|
||||
|
||||
## 증상
|
||||
|
||||
- 캡처 범위를 드래그하면 원래 화면으로 보이는 선택 영역이 계속 번쩍였음.
|
||||
- 캡처 결과가 아니라 드래그 중 오버레이 표시에서만 발생했음.
|
||||
|
||||
## 원인
|
||||
|
||||
- `WM_MOUSEMOVE`마다 `InvalidateRect`에 영역을 주지 않아 전체 가상 화면을 다시 그렸음.
|
||||
- `WM_PAINT`가 실제 화면 DC에 검정 배경, 투명 color key, 테두리를 차례로 직접 그려 중간 상태가 노출됐음.
|
||||
- 멀티모니터 전체 면적을 매번 다시 칠해 불필요한 GDI 작업도 컸음.
|
||||
|
||||
## 수정
|
||||
|
||||
- 이전 선택 사각형과 새 선택 사각형의 합집합만 무효화함.
|
||||
- 오버레이 크기의 호환 bitmap과 memory DC를 한 번 만들고 창이 닫힐 때 해제함.
|
||||
- memory DC에서 배경·투명 영역·테두리를 완성한 뒤 dirty 영역만 `BitBlt` 한 번으로 화면에 복사함.
|
||||
- memory DC를 만들지 못하면 기존 화면 DC 그리기로 대체함.
|
||||
|
||||
## 확인
|
||||
|
||||
- 역방향 드래그를 포함한 선택 영역 합집합 계산 회귀 테스트를 추가함.
|
||||
- Rust 테스트 14개와 build를 통과함.
|
||||
- 요청에 따라 computer-use는 사용하지 않았고, 실제 드래그 화면 확인은 사용자 수동 확인으로 남김.
|
||||
Reference in New Issue
Block a user