skip menu and go to main content

body start

Nabi - the Easy Hangul XIM

Open  한글을 입력하는 도중, 즉 preedit상태의 한글이 있을 경우 마우스로 커서를 이동하면... 9 ]

04.05.20-19:56:35

300342

Submitted by 이노성

Assignee Choe Hwanjin

View0

Priority5

버그라기 보단 기능의 단순성에서 오는 불편함이 아닐까 생각해봤지만 좀더 좋은 플
그램이 될 수 있다고 보고 이렇게 글 올립니다.

요약에서 설명했듯이 한글을 입력하는 도중, 즉 preedit상태의 한글이 있을 경우 마
우스로 커서를 이동하면 preedit상태의 글자가 커서를 따라오는 현상이 있습니다. 특
히 웹브라우저의 입력폼에 입력시 하나의 텍스트박스에 입력하다 마우스로 다른 텍스
트 박스로 커서를 옮길 경우 preedit상태의 글자는 잔영을 남기며 이전의 텍스트 박
스에 있지만 유효하지 않고 결국 옮겨운 텍스트 박스에 추가되는 현상이 발생합니다.

제대로 설명했나 모르겠습니다..-.-;;

Comments on this artfact

9 Comments

이노성

"Assigned To" was changed from "Nobody" to "Choe Hwanjin"
"Priority" was changed from "5" to "5"
"resolution_id" was changed from "100" to "None"

04.05.20-19:59:34

이노성

로그인: YES
user_id=6398

아...저가 쓰는 건 nabi-0.13입니다.

04.05.20-20:13:13

Choe Hwanjin

로그인: YES
user_id=104

설명 제대로 하셨습니다.

이 문제는 아마 모질라나 firefox에서 발생하는 것이겠지요?
이 문제는 다른 나라의 입력기 사용 방식의 차이 때문에 발생하
는 것으로 해결하기 꽤 어려운 문제입니다.

일본 쪽의 경우 preedit 상태에서 마우스로 커서를 움직였을 때
preedit 상태의 글자가 커서를
따라가는 것을 기능으로 생각합니다. 그래서 현재 많은 수의 프
로그램들이 그 방식을 따라서 구현이
되어 있습니다. 그러다보니 우리나라에서는 마우스로 커서를 움
직였을때 그냥 그자리에 남아 있길 바라는
상황과 맞지 않아서 그런 현상이 발생합니다.

그리고 이것은 X 입력기에서 처리할수 없는 문제로 각 어플리케
이션 수준에서 처리방식을 결정해야 하는
문제입니다.

04.05.20-22:10:46

이노성

로그인: YES
user_id=6398

ㅠ.ㅠ..
윈도우처럼 마우스 이벤트를 캡쳐해서, 그러니깐 OnFocus비슷한
게 발생할 때 마다 preedit상태를 글자들을 flush하면 안될까요?

-.-;; 안되겠네요..OnFocus가 발생하면 이미 커서는 다른 폼에
가 있는거고 역시 그곳에 flush를 할테니깐요..웅-.-;;

이거 디따 어려운 문제였군요..-.-;;

각각의 응용프로그램들이 요청하는 방식이 아니라 나비가 적극적
으로 신호를 보내는 방식을 써야 될 것 같은데 그럴수 있나 모르
겠습니다..-.-;; 역시 짧은 지식이 무섭다고..-.-;

04.05.21-10:51:50

Choe Hwanjin

로그인: YES
user_id=104

아닙니다. 꽤 자세하게 알고 계시네요. Focus Out이 발생할때
commit하는 방법이 있습니다. 그런데 이렇게 구현해 보니 약간
문제가 발생했었습니다. focus가 없는 윈도우에 commit을 해야
하다보니 발생하는 것 같았습니다. 그래서 Focus Out의 경우
commit하지 않고 있습니다. (imhangul의 경우 focus out이 일어
나면 commit 합니다) 이러다 보니 이 문제를 쉽게 해결하지 못하
고 있습니다.

또한 이것만이 아니라 focus out이 발생하지 않는 경우도 문제가
됩니다. Textarea같은 곳에서 글을 쓰다가 preedit 상태에서 마
우스로 커서를 움직이는 경우는 focus관련 이벤트가 전혀 발생하
지 않습니다. 이런 경우는 어플리케이션에서 커서를 움직이기 전
에 XimReset 결과물을 commit 해줘야 하는데, 앞서 말한대로 보
통 commit 해주지 않는 것들이 있습니다. GtkEntry나
GtkTextView의 경우는 괜찮지만, Qt의 경우는 원하는 동작이 일
어나지 않습니다.
지금 확인해 보니 모질라의 경우는 커서가 움직이지 않는 군요.
움직인것처럼 보이다가 키 입력을 하는 순간 원래 자리로 가네요.

04.05.21-13:48:13

마잇

저도 Firefox 쓰면서 게시판 같은데 글을 남길때 뭔가 이상했는데 이런 문제가 있었네요.

글 올리기전에 nautilus, xchat, firefox 세군데서 테스트를 해봤습니다.

노틸러스 주소창에 글을 치다 마지막 글자가 flush(이 글타래서 보고 쓰는 표현인데 맞는지 모르겠네요)되지 않은 상태 - 마지막 글자가 검은 박스로 선택되어 있는 - 에서 xchat으로 포커스를 옮겨서 한글 입력
-> 양쪽 번갈아 가면서 입력해도 이상은 없습니다. 노틸러스 주소창에 '안녀' 까지 입력하고 xchat 챗창에 이런저런 글을 쓰고 다시 와서 'ㅇ'을 눌러주면 '안녕'으로 완성됩니다. flush되지 않고 양쪽다 preedit상태로 있다가 정상적으로 입력이 연결되는것 같습니다.

Firefox와 xchat(nautilus) 사이를 이동하면 입력
-> 이 경우에도 양쪽다 포커스를 움직여도 글자가 따라오지는 않고 preedit 상태를 유지하다 정상적으로 연결되서 입력

Firefox 내부에서 textarea나 주소표시줄을 이동하면서 입력
-> 마지막글자 입력이 flush되지 않은 상태에서 입력 포커스가 바뀌면 preedit상태의 글자들이 다 딸려와서 새로 포커스를 얻은쪽에 입력 됩니다. '아' 까지 치고 다른데로 옮겨서 'ㄴ'을 치면 새로 옮긴쪽에 '안'이 완성되어서 출력 - 이전의 입력창쪽은 여전히 '아' 상태에서 반전된채로 preedit 상태를 유지한것처럼 보이지만 다시 그쪽으로 가서 입력하면 '아'는 사라지고 이전의 입력중 preedit 상태인 글자들이 또 이쪽으로 옮겨져서 입력. 이게 왔다갔다 반복되면 꼭 다운된거 같이 preedit 상태가 풀리지를 않으면서 마우스로 빈공간을 클릭해줘도 여전히 글자가 반전상태를 유지하고 esc를 한번 눌러주면 풀립니다.

Gnome-2.8.2
xchat-2.4.1
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050127 Firefox/1.0

Firefox가 좀 처리 방식이 달라서 그런가 하고 짐작해 보네요.

05.01.31-16:43:09

마잇

nabi-0.14

nabi 버전을 빠트렸네요 ㅎㅎ

05.01.31-16:45:10

Choe Hwanjin

1. FireFox의 문제
제 생각에는 firefox의 한글 입력 기능 구현에 버그가 있는 것 같습니다.

2. gtk2 app의 문제
gtk2에서 마지막 글자가 커밋되지 않는 이유는 아래 링크를 참조하세요
http://bugzilla.gnome.org/show_bug.cgi?id=91216

05.02.01-10:27:03

Choe Hwanjin

이 문제는 어플리케이션의 버그로 어플리케이션에서 해결해야 할 문제입니다만, 입력기 개발하는 과정에서
계속해서 알고 있는 것이 좋은 문제이므로 버그를 닫지 않고 있습니다.

firefox의 경우 개발버젼에서 이 문제가 해결 되었습니다.
아래 링크를 참조하시기 바랍니다.

https://bugzilla.mozilla.org/show_bug.cgi?id=306212

07.12.19-11:49:37

Choe Hwanjin

[#301140] 문장의 끝글자가 다른 입력창의 첫번째에 입력되는 현상
버그도 이 버그와 같은 문제입니다.

07.12.19-11:52:40