구글 지보드 작동 방식.

demand-on으로 작동한답니다.

daemon은 아니고요.

즉, 한마디로 입력 서비스 요구시 작동하는 데몬 같은 거랍니다.

사용이 끝나면 종료되고요.

서버 프로세스는 맞는데, 요구시에 작동, 끝나면 종료.

이렇게 작동한다네요.

그리고 고급 입력 기능은, 구글 클라우드 서버와 통신을 한다고 해요.

인터넷 끄고 오프라인에서는 구글 클라우드와 통신 못한다 하고요.

결론, 앱과 IPC로 구글 지보드랑 통신한답니다.

앱1, 앱2가 있다고 가정,

한국어, 중국어, 영어를 사용한다고 가정,

구글 지보드 측에서 한국어, 중국어, 영어 엔진 인스턴스가

각각 1개 생성되고, 세션을 지원하기 때문에,

앱1, 앱2에 대해서 각각의 입력 컨텍스트를 제공한다고 하네요.

후보창은 Anchor 정보가 있고, 그걸로 후보창 위치를 결정 가능하고,

안드로이드에서 앱은 절대 좌표를 알 수 있다고 하고요.

앱과 앱간의 절대 좌표는 보안상 공유 안 한데요.

그래서 앱1, 앱2의 절대 좌표를 입력기가 알 수 없고,

대신 텍스트 입력 부근 근처에 대한 Anchor 과 변환 매트릭스를 통하여

절대 좌표를 구해서 적절한 위치에 후보창을 그려주면 된다고 하네요.

리눅스에서는 GTK 앱에서 이런 건 불가하고요.

GTK 앱에서는 커서의 상대 좌표를 입력기에 전달합니다.

X11 환경이라면 입력기는 그 좌표를 절대 좌표로 변환 가능하고요.

Wayland 환경이라면 절대 좌표 변환 불가해요. 보안상의 이유로

절대 좌표를 알 수가 없어요. 대신, 후보창 그릴 수 있는 surface 를 제공한다는 것 같아요.

프로토콜 문서 봤는데, 글 쓰다가 내용 까먹었네요. 텍스트 입력 부근에

후보창 그리는게 가능하다는 얘기.

후보창은 입력기 프로스세에서 팝업 형태로 띄우는게 일반적입니다.

다국어 입력기는 서버 방식으로 싱글톤 방식으로 작동하고요,

각 언어 엔진이 입력 컨텍스트 세션을 지원한다면

1개의 엔진으로 여러 앱에 대해 각각의 입력 컨텍스트를 유지할 수 있어요.

그렇게 할 경우, 사전이 각 언어 당 1개만 로딩되므로 메모리 소비가 적어요.