wayland 는 IME 관련해서는 강력한 군주 더 나가 폭군(?)이 되었으면 합니다.

emptynote의 이미지

wayland 는 IME 관련해서는 강력한 군주 더 나가 폭군(?)이 되었으면 합니다.

아래 첨부 파일 총 17페이지인데 12페이지에 나온 구조도를 보니

버그 구현 어렵겠다는 생각 부터 드네요.

14페이지에 나온 구조도를 보니 저는 이 구조도가 훨씬 좋다고 생각합니다.

3.28.1 내용은 그 구조도에 따른 내용인듯 보여지구요.

하여 저는 그 내용을 지지합니다.

리눅스 세상에서 강제하는것 어렵지만 wayland 의 IME 만큼은 폭군쯤 되는

강력한 전제 군주가 탄행하여 밀어 붙여주었으면 합니다.

클라이언트 한테 IME 이 해야 할 일을 주지 말았으면 합니다.

제가 IME에 한해서 폭군(?)을 원하는 이유는 그뿐입니다.

----------------- 부분 인용
https://www.slideshare.net/gnomekr/korean-input-overview-in-the-linux-desktop

3.28.1 부터 “gtk-text-input” 프로토콜 추가 ● 직접 ibus에 연결해서 받은 결과물을 클라이언트에 전달 ● gtk에 ibus immodule 필요없어지고 wayland “gtk-text-input” 지원 필요 ● 장점: GUI toolkit에서 입력기 의존 처리가 필요 없음. 스크린 키보드, 필기 입력, 음성 입력 등 데스크톱 연동이 쉬움. ● 단점: 표준화가 쉽지 않음. gtk-text-input은 gtk/gnome 전용

세벌의 이미지

클라이언트와 IM이 소통해야 되는 거 아닌가요?

X냐 wayland냐와 입력기는 어떤 관계가 있는지 모르겠네요...

폭군(?)이라는 단어는 왜 나오는지 모르겠네요...

emptynote의 이미지

자유소프트웨어 진영의 경우 자유를 중시하니

특정 API 사용 강제에 대해서 부정적입니다.

하지만 gtk/gnome 전용 gtk-text-input 로 통일 되지 않고

현재처럼 클라이언트 마다 중구 난방이라면

한글 끝문자 버그는 영원할 수 밖에 없습니다.

한글 끝문자 버그 gtk 응용 어플에서도 일어 나는지 한번 살펴 보세요.

저는 아직 본적이 없습니다.

그 이유가 무엇일까요?

gtk 는 이미 검증된 API 를 사용하고 있고

그 API 에 버그가 있다면

그것을 이용한 클라이언트 수정 없이

해당 API 만 수정하면 된다는것을 말합니다.

gtk/gnome 전용 gtk-text-input 와 같은 API 를 강제로 사용해야 하는것은 저항에 부딪힙니다.

당장 KDE 에서는 난리날 일입니다.

이 저항을 줄일려면 gtk/gnome 전용 gtk-text-input 을 spec 으로 만들어서 표준 인증 절차를 걸쳐야 합니다.

하지만 많은 사람들이 참여하면 좋겠지만 현실적인 문제로 어렵습니다.

하여 그 누군가가 총대 매고 이 일을 강력하게 추진해서 spec 을 공표를 하여 지키게 했으면 합니다.

특히 데비안같은 배포판에서 강력하게 이를 지지해 주어 이 spec 을 지키지 않은 프로그램을 배포판에서 배제하는 강력한 정책을 폈으면 합니다.

그런데 이런 모습은 독재자와 정말로 종이 한장 차이입니다.

하여 독재자를 좀더 과격하게 폭군(?) 으로 언급한 것 뿐입니다.

세벌의 이미지

질문. gedit 에서 한글 끝글자 버그 나타나던데... gtk 응용어플 아닌가요?

한글 끝문자 버그 gtk 응용 어플에서도 일어 나는지 한번 살펴 보세요. 저는 아직 본적이 없습니다.

라고 하시기에...
emptynote의 이미지

gedit gtk 응용 어플 맞습니다.

제가 끝 문자 버그로 다솜을 설치해서 해결한것을 착각한듯 합니다.

몇일전 포맷한 우분투 18.04 버전에서 다시 확인해 보니 끝문자 버그 그대로 이네요.

확인을 하고 글을 작성했어야 햇는데 죄송하게 되었습니다.

오류가 있지만 하나의 API 통합은 바른 방향이라는 생각하기에 수정 없이 글을 그냥 두겠습니다.

세벌의 이미지

잘못을 인정해주시니 고맙습니다.

몇일 며칠 헷갈리는데
http://www.korean.go.kr/front/faq/faqView.do;front=728A7003AEB50433C63A6DBC2B971C90?mn_id=&faq_seq=331&pageIndex=3
참고하세요.

다솜에서 님프로 이름 바꾸었다고 하네요.
https://cogniti-works.blogspot.com/2016/05/blog-post_18.html

끝글자 버그는 입력기의 버그일까요?
https://cogniti-works.blogspot.com/2016/05/blog-post.html

복잡하고 어려운 문제네요...

API 통합은 무슨 뜻인지 모르겠네요.

emptynote의 이미지

IME 관련 API 를 표준으로 정해 그것만 사용하도록 하는것 개발자라면 알아 들으실거니 너무 염려마세요.

쉽지 않습니다. 표준화도 어렵고 표준을 지키기는 더욱 어렵습니다.

만약 데비안 같은 메이저 배포판에서 이 기준에 합당하지 않은 응용 어플 제외하면

그 반발도 만만치 않구요.

당장 저는 이클립스-자바로 개발을 하는데 이클립스가 이것을 안 따라주면 제외한다는 정책에 의해서

데비안에서 이클립스 배제당하면 반발 할 수 밖에 없습니다.

저두 당장 불이익이 있을지 모르지만 그러함에도 한글 끝문자 버그 해결의 최선은

참고 주소의 슬라이더 14페이지 구조와 더불어 IME 관련 API 를 표준으로 정해 그것만 사용하도록 하는것뿐이라고 생각합니다.

왜냐하면 서버 클라이언트 구조하에서 클라이언트에서 IME 관련 부분이 중구 난방이면 버그 보고 하다 날밤 세기때문입니다.

문제가 된 부분 1 곳에서 버그 고치면 전체가 다 수정되어야지 100개 1000개 클라이언트 쫓아 다니며 수정할 수 없지 않습니까!

-----------
참고 주소 : https://www.slideshare.net/gnomekr/korean-input-overview-in-the-linux-desktop

Hodong Kim@Google의 이미지

강압적이고 폭압적인 방법으로 문제를 해결하는 것은 불법입니다.
자율 경쟁에 따른 점유율로 사실상 표준이 결정되는 것입니다.
표준이 있다고 하여 다른 방법을 못 쓰게 하는 것은 불공정 행위입니다.
두벌식이 표준이니 세벌식을 못 쓰게 하면 어떤가요?
MS윈도우만 쓰도록 하고 리눅스 못 쓰게 하면 어떤가요?

그리고 서버-클라이언트 구조랑 끝글자 버그랑은 무관합니다.
nimf 는 동기 방식이기 때문에 끝글자 버그가 없습니다.
nimf 를 사용하시면서 겪는 끝글자 버그는 응용 소프트웨어 버그입니다.

ibus 는 비동기 방식이기 때문에 끝글자 버그가 있습니다.
끝글자 버그가 없는 gedit 와 ibus 를 함께 사용하면 끝글자 버그가 나타납니다.
gedit 는 gtk 툴킷을 사용하였는데, gtk 툴킷에는 마우스로 클릭했을 때 리셋하는 코드가 들어있습니다.

ibus 끝글자 버그는 비동기 통신 때문에 발생합니다.
이에 대한 버그 리포트가 많이 있습니다.

데비안은 Debian Free Software Guidelines (DFSG) 라는 것이 있습니다.

https://www.debian.org/doc/debian-policy/ch-archive.html#the-debian-free-software-guidelines

오픈소스란 무엇인가
https://opensource.org/osd

emptynote 님께서 님이 겪는 문제이니 남들에게 이래라 저래라 하지 마시고
님께서 총대를 메시고 님의 시간과 님의 돈을 투입하여 해결하시면 되겠네요.
님의 활약을 기대해 보겠습니다.

emptynote의 이미지

하모리카 리눅스 사이트 'Ohnine' 님께서 호동님께서 gtk qt wayland im 통합되어야 한다고 말씀을 하셨다는데

단순히 Ohnine 님이 착각해서 글을 쓰신건가요?

아니면 자신이 말해 놓고 까맣게 잊은 호동님 이신가요?

제 주장 본질적으로 호동님께서 말한 "gtk qt wayland im 통합" 주장과 같습니다.

당위성이 있으니 강력하게 밀어 붙어야 한다는것만 차이가 있을뿐입니다.

끝문자 버그는 저만 겪는 문제 아니고 이렇쿵 저러쿵 이야기 못하게 니가 책임져 라고
상대방 말을 막는 폭력을 휘드리지 마세요.
특히 강압적으로 문제를 해결하는 방법이 불법이라고 지적질 하면서 말입니다.

저 개인적으로 준비중인 자바 프로젝트 오픈해야 하기에 바쁩니다.
베타판 수준이라도 곧 공개할 생각입니다.
"이렇게 멋지게 우분투에서 개발 환경을 구축하여 개발할 수 있습니다." 라고 홍보를 해야 하는 입장에서
우분투 끝문자 버그도 제가 껴 안아야 하는 아픔입니다.
그럼 건승하세요.
--------------------
http://hamonikr.org/Free_Board/53452#comment_53588

Profile
Ohnine
2018.08.24 00:01

한글을 떠나 리눅스 입력 문제는 기술적인 문제 보단 오픈소스의 이해관계 상충을 원인으로 말씀하시더라구요.
근본적인 문제가 안드로이드나 맥, 윈도우처럼 통합 입력 api 가 없는데서 비롯된다고....
라고 님프 개발자이신 호동님께서 구플에서 의견을 말씀해주신적이 있어요.
gtk qt wayland im 통합이 되야한다고.....

Hodong Kim@Google의 이미지

자율 경쟁에 의한 점유율로 인해 통합되는 것이랑
불법적이고 폭력적인 방법으로 통합하는 것은 분명 다르죠
님께서 예전에 이클립스 버그 가지고 입력기 탓하고 제 원망하건거 벌써 잊으셨나봐요?
이클립스 버그를 회피할 수 있는 옵션을 추가 했더니
땜빵 입력기라고 폄하하고 근본적으로 고치라고, 즉 이클립스 버그를 저보고 고치라고 한거 벌써 잊으셔나요?
섭섭하네요

emptynote의 이미지

그래도 통합 API 에 대한 당위성은 부정 안하시니 다행이네요.

자율 좋지요. 리눅스를 사용하는 분들 자유 매우 중시합니다.

그런데요. 자율로 하면 한글 끝문자 버그 해결 될것 같습니까?

앞으로도 x-client용 신규 응용 어플은 쏟아질것입니다.

그런데 무슨 재주로 한글 끝 문자 문제를 해결 하실건가요?

일일히 x-client 용 신규 응용 어플 쫒아 다니며 해결 하실건가요?

자율이라는 미명하에 x-client 응용 어플이 천개면 천개 만개면 만개 그거 다 쫒아 다니며

한글 끝문자 버그 뒷치닥거리 해야 한다 주장하십니까?

진정 개발자 맞으십니까?

호동님 프로그램은 하나 수정하면 전체 반영되지 않고 하나 하나 쫓아 다니며 수정하는 프로그램 인가 봅니다.

Hodong Kim@Google의 이미지

강제하는게 불법인데 어떻게 강제하시게요?
오픈소스가 헌법위에 있는줄로 착각하시면 곤란해요

emptynote의 이미지

호동님은 앞뒤 맥략 없이 인용 하시는군요.

왜 그런 말이 나오게 되었는지 알 수 있게

링크를 걸어 주던가 하는 친절은 하나도 없군요.

이런걸 악마의 편집이라고 합니다.

그럼 수고하세요.

Hodong Kim@Google의 이미지

응용 프로그램의 끝글자 버그 그거 굉장히 단순한 버그인데...
wine, 이클립스, 리브레오피스 끝글자 버그를 고쳐드리려고 해도
사용자분들이 음해, 허위사실 유포에 명예훼손을 일삼기 때문에 고쳐드릴 수가 없는 거에요.
고쳐드리면 다른 거 고쳐달라고 음해, 허위사실 유포하여 명예훼손할 것으로 예상되기 때문에 손을 못 대는 거죠.

emptynote의 이미지

제가 호동님께 바라는것은 호동님이 여유를 찾을 수 있는 휴식입니다.

단순한 버그? 라고 쉴드 칠 시간 있으시면 좀더 푹 쉬세요.

Hodong Kim@Google의 이미지

오픈소스 안티 활동 그만 좀 하셨으면 좋겠네요

emptynote의 이미지

호동님이 오픈 소스를 언급하십니까?

평소에도 개발할 수 록 손해다 라고 외치시다 아래 "2018년 5월 26일 토요일" 에 유료 선언하셨습니다.

오픈 소스라고 해도 서비스 지원 같은 것을 유료화 하는것이 무엇이 문제입니까?

하지만 여기서 중요한것은 자기 감정에 휘둘려 2018년 5월 11일 금요일에 이슈 페이지를 닫았다는 점입니다.

이슈 페이지는 버그 보고입니다. 이슈 이것도 유료 대상으로 생각하는것이 현재 호동님 아니십니까?

이슈에 올라오는 버그 수정을 무상 개발이라고 생각하는 마인드가 오픈 소스 마인드입니까?

과거 자신이 너무 힘들다며 다솜을 다솜 팀한테 인계를 했습니다.

그런데 그분들은 어디 계십니까?

저는 다솜 팀은 아예 존재 하지 않았다고 생각합니다.

그것은 아래 호동님께서 nimf 역사를 기술할때

다솜팀 언급 없이 님프(nimf)로 개명했다는 글속에 진실이 있다고 생각하기때문입니다.

거짓말을 아무렇지 않게 말씀을 하시고 버그 보고 올라와 수정하는 행위를 무상 개발이라고 생각하여 유료를 선언하신 분께서 오픈 소스를 언급하십니까?

----------- 부분 인용
님프의 역사 참고 주소 : https://cogniti-works.blogspot.com/2018/07/nimf-12-nimf.html

2015-01 모듈 방식으로 설계 착수
2015-02-02 모두(Modu) 입력기 개발 착수
클라이언트-서버 모듈 방식으로 재설계하여
2015-05-23 다솜(dasom) 으로 개명
2015-10-09 다솜 릴리즈
2015-12-29 님프(nimf)로 개명
2016-04-26 님프 릴리즈
(...중략...)
2018.07.20 버전까지 나온 상태입니다.

---------------------------
참고 주소 : https://cogniti-works.blogspot.com/2018/05/nimf_26.html

2018년 5월 26일 토요일
nimf 개발, 유지보수, 지술지원 유료화 안내

안녕하세요.
그동안 제가 2015년부터 약 3년간 무상으로 개발, 유지보수, 지술지원을 해왔는데, 더이상 장기적으로 누적 손실을 감당할 수 없어서 개발, 유지보수, 지술지원을 유료화하기로 했습니다.

nimf 는 오픈소스 라이선스로 배포되는 오픈소스 소프트웨어입니다.
사용자분께서 개발, 유지보수, 지술지원을 의뢰하면 유료로 개발 및 수정한 코드가 오픈소스 라이선스로 공개됩니다.
제 이메일 주소는 cogniti@gmail.com 입니다. 이메일로 문의하시면 되겠습니다.
감사합니다.

---------------

참고 주소 : https://cogniti-works.blogspot.com/2018/05/nimf_11.html

2018년 5월 11일 금요일
nimf 프로젝트 이슈 페이지를 닫습니다

안녕하세요.
그동안 저는 참 호구같은 인생을 살아온 것 같습니다. 예전부터 느끼고 있었던 건데 참 글로벌 호구답다는 것입니다. 참 바보같은 인생을 살아온 것이죠.
나이도 점점 먹어가고 요즘은 미래가 심각히 걱정이 됩니다. 그동안 무상으로 기술 지원을 해왔는데 앞으로 nimf 에 대해 무상 기술 지원을 하지 않겠습니다. 이에 따라 이슈 페이지를 닫습니다.

Hodong Kim@Google의 이미지

거짓말한 적 없고 오픈소스가 원래 개발 및 유지보수 책임이 없는 겁니다.
이슈 페이지를 고객센터로 여기시는 분들 계시는데 nimf 가 돈 받고 파는 상품이 아닙니다.
그래서 이슈 페이지를 운영하지 않아도 법적으로 도덕적으로 문제가 없는거죠.

그리고 그동안 무상 개발, 무상 유지보수 해온 건 사실입니다.
저는 나라에서 돈을 받지 않았고 기업으로부터 돈 받은게 없습니다. 노동의 대가로 돈을 받은게 없단 말입니다.

Nimf is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

Nimf is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.

구글 번역기로 번역해 보면

Nimf는 자유 소프트웨어입니다. 자유 소프트웨어 재단 (Free Software Foundation)이 발행 한 GNU 약소 일반 공중 사용 허가서 (버전 3 라이센스 또는 귀하의 선택에 따라)를 기준으로 이후 버전을 재배포 및 / 또는 수정할 수 있습니다.

Nimf는 유용 할 것이라는 희망으로 배포되었지만 어떠한 보증도하지 않습니다. 상품성 또는 특정 목적에의 적합성에 대한 묵시적 보증조차하지 않습니다. 자세한 내용은 GNU 약소 일반 공중 사용 허가서 (GNU Lesser General Public License)를 참조하십시오.

Hodong Kim@Google의 이미지

오픈소스 마인드가 뭔가요?
소스코드 공개되었고 수정 배포 가능하고 무보증, 책임없음이 오픈소스입니다.
이슈 페이지를 닫은 건 이슈를 받기 싫어서 그런 거고 돈을 벌기 위해 그런 것이 아닙니다.
이슈 페이지에는 버그 리포트만 올라오지 않습니다.
그리고 nimf가 사람들에게 알려지고 많은 사람들이 사용한다하더라고 제가 개발비, 후원금이나 월급을 받은 바 없고, 기여 받은 부분이 nimf의 전체 부분 중 1% 미만입니다. 저의 시간과 돈, 장소, 장비를 이용하여 개발하였습니다. 그래서 개인 프로젝트입니다.

제 입장은

https://cogniti-works.blogspot.com/2018/08/nimf-20.html?m=1

이 글에 상세히 나와 있으니 읽어보시기 바랍니다.

그리고 님처럼 오픈소스는 무상 보증 책임이 있다고 생각하시는 분들은 라이선스 위반이나 오픈소스를 사용하시면 안 됩니다.

Hodong Kim@Google의 이미지

그리고 다솜 프로젝트 주소는

https://github.com/dasom-im

입니다.

당시 개인 프로젝트에서 형식을 그룹(집단,단체)으로 변경하였습니다.
팀 형식으로 바꾼 후 개발을 계속한 것도 맞습니다.
저를 포함하여 다솜팀이 세 분 계셨습니다.
한명씩 탈퇴하여 한분 남으셨네요.
당시 세벌님은 개발자가 한국사람이고 다솜을 한국 사람이 제일 많이 사용할 텐데 설명이 영어로 되어 있다는 내용으로 음해시도를 하셨고
emptynote님께서는 한글 입력기 참 어려운 주제인 것 같습니다는 글을 작성하였는데 개발자에게 스토커짓 어쩌구 저쩌구 이러시면서 강압적인 방법을 말씀하셨지요.
이클립스 끝글자 버그를 dasom에 보고하셨고 dasom 버그가 아니라서 회피 코드를 만들어 드렸는데 땜빵 코드이니 근본적으로 해결하라고 하셨죠.
근본적인 해결은 이클립스를 고쳐야 하는데 그걸 제게 요구를 하셨습니다.
게다가 우분투 포럼에 땜빵 입력기라 폄하하고 저를 원망하는 등 다솜에 대한 부정적인 영향을 끼치는 글을 지속적으로 작성하셨습니다.
제가 다솜팀에 계속 있으면 이러한 일이 지속적으로 발생할 것이라 예상되어 팀에서 탈퇴했습니다.
그후 수개월간 고심하다가 다솜이라는 이름을 음해 공격으로부터 자유로워질 수 있으니 다솜과는 별도로 nimf 로 이름을 변경하여 개발을 해왔고
2015년 말, 2016년 초 dasom, nimf 라는 이름 두개를 동시에 모두 사용하려는 계획이었습니다.
다솜도 동시에 업데이트를 하다가 nimf 변경 사항이 너무 많아서 시간이 없어서 nimf 만 업데이트를 해오고 있는 것입니다.
저는 거짓말한 적이 없습니다.
저한테 왜 이러시는 겁니까?
님께서 작성하신 강압적이고 폭력적인 방법은 오픈소스 마인드에 맞지 않을 뿐더러 법률에 위배되는 것입니다.

chahoolee의 이미지

말은 좀 똑바로 합시다.

지난 역사를 보자고요. 님이 오픈소스 한다고 하다가 프로젝트 닫은 거 처음이 아니잖아요? 이슈 닫은 게 대수가 아니죠? 저장소 닫고, 홈페이지 닫고, 플레임하다가 블로그니 홈페이지니 게시판이니 지워버리고 탈퇴한 거 벌써 여러번이잖아요? 그게 다 사람들이 유독 특정 오픈소스 개발자를 주기적으로 괴롭혀서 그런 건가요?

문제는 님이 오픈소스 커뮤니케이션을 받아들이는 자세예요. 프로젝트 하다 보면 온갖 사람들이 있게 마련인데, 오픈소스 개발자들이 어떻게 할 것 같습니까? 그런 일들 있으면 알아서 받아들이고 적당히 무시하면서 진행하는 겁니다. 그걸 몇달동안 스트레스 쌓아놨다가 터뜨리면서 프로젝트 운영 수단을 다 차단하고, 프로젝트에 피드백했던 모든 사람들을 싸잡아서 개발자한테 "금전적 손실"을 주는 나쁜 사람들이라고 떠들고 다니는 게 호동님의 오픈소스인가요? 누가 누구의 명예를 훼손하고 있는 거죠? 이 짓을 대체 몇년 동안 몇번 반복하는 겁니까?

커뮤니케이션이 싫으면 입력기처럼 다른 소프트웨어와 연동하는 이런 거 만들지 말고 골방에 들어가서 OS랑 컴파일러부터 부트스트랩하고 공개하지 마세요.

Hodong Kim@Google의 이미지

개인 프로젝트, 개인 블로그 삭제한 게 무슨 문제라는 건가요? 수십번 생성, 삭제를 했습니다.
헌법상 보장되는 기본권입니다.
제가 GNOME,KDE 프로젝트를 삭제한게 아니잖아요.
프로젝트 운영 수단을 다 차단하셨다고 하는데..
PPA, 홈페이지 삭제 그건 제 자유입니다.
개인의 시간과 돈을 투입한거에요.
제가 남들 꺼를 삭제한게 아니잖아요.
개인이 운영하면서 손실을 감당하기 어려우면 무상 서비스를 축소하는게 무슨 문제라는 거에요?
도덕적, 윤리적, 법적으로 아무 문제 없습니다.
소스코드 라이선스를 바꾼 것도 아니고
소스코드 및 이슈를 다운 받을 수 있도록 안내하고 있고 제가 다운받는 거를 방해하는 것도 아니에요.
단, 님들이 무상 서비스를 못받으까 기분 나쁜건 이해합니다.
제가 본업이 따로 있는 사람이에요.
본업에 방해가 되면 어찌할 방법이 없어요.
그리고 현재의 nimf 는 제가 기여도가 좀 되기 때문에 개인 프로젝트라 부르기는 좀 그렇죠.
기여도가 점점 높아지면 단체 프로젝트의 형식을 띠게 될 것이고 그 때는 제 맘대로 하지를 못해요.

chahoolee의 이미지

합헌인지 따지시려면 헌법 공부하시든지 하시고요. 님은 님 프로젝트 주위 사람들이 정나미가 떨어질 만한 방법으로 프로젝트를 운영하고 있는 거에요. 입력기가 좋다 나쁘다의 문제도 아니고 다른 사람들 때문도 아니고 님이 프로젝트 관련해서 사람들을 대하는 방법 때문에 문제가 되고 있는 거라고요.

툭하면 기분 나빠져서 저장소 지우고 이슈 지우고 다운로드도 안 지우신 것처럼 하는데 지운 적 있어요. 여러 사람들 글이 들어 있던 구글그룹스도 기분 나빠서 예고도 안 하고 지우셨죠. 조용히 지우는 것도 아니고 기껏 자기 시간 써서 버그리포트하고 패치 만든 사람들까지 그놈의 "무상 서비스" 이용해 먹으려고 하면서 "금전적 손실" 끼치는 음모를 펼치고 있는 탐욕 가득한 사람들이라고 싸잡아서 공격하면서 지우죠? 그래 본인 성격이 이런 거 싫어하는 성격이라고 이해해 주겠는데. 그러면 좀 일관적으로 하라 이겁니다. 그냥 계속 안 하시면 되잖아요? 멘탈 회복되면 다시 나타나고 또 누군가를 비난하고 지우고, 이걸 반복하는데 다음에 비난할 사람 낚시질이라도 하시나요? 이걸 누가 곱게 봐줍니까?

자꾸 양손에 떡을 쥐고 프로젝트는 해야 되는데 금전전 손실이 있다 (기회비용을 손실이라고 말하는 거 자체도 웃기는) 이렇게 하시는데. 답은 간단해요. 뭐든 포기하시면 되는 거에요. 이슈 무시하고 코드 방치하면 되는 거에요. 근데 그렇게 못 하겠죠? 플레임이 열리면 댓글을 달아야 겠고 트롤이 낚시질을 해도 설명을 해 줘야 겠고, 댓글 달면서도 이 답글 다느라고 손실이 막심하다고 누군가 탓을 해야 겠죠? 누가 게시판에서 nimf 이상하다는 말만 하면 막 자기 본인 명예훼손으로 느껴져서 가입을 해서 위법이라고 경고 댓글을 달고 싶어지죠? 그런 마음가짐으로는 님이 돈과 시간이 얼마가 있든 풀타임 개발자이든 마찬가지에요. 본인 의사로 시작한 프로젝트이고 본인 의사로 결정할 수 있는 거 갖고 매번 갈등 유발을 하는데 본인을 좀 돌아보세요.

Hodong Kim@Google의 이미지

님께서 말씀하시는게 어떤 취지인지 알겠습니다.
그리고 싸잡아 욕하는 거는, 특정인을 거론하면 명예훼손이 될 수 있기 때문에 불특정 다수를 욕하는거고, 신경 끄고 살다보면 독촉 메일, 개인 이메일 오니 신경을 끌 수가 없어요.

커뮤니케이션 문제는 인정하는 바이고 오픈소스에서만 유독 중요한 것은 아니고 어디에서나 중요합니다. 커뮤니케이션 스킬 부족은 아니고 생업이 따로 있기 때문에 어쩔 수 없습니다.
예를 들어, 어떤 이슈에 대해서 nimf 버그가 아님을 확인 후 시간 없어서 "nimf 버그가 아닙니다." 그렇게 이슈를 닫으면
아... 커뮤니티 게시판에서 까이는 거 아닌가 불안하고,
상세 설명드리면 제가 잠을 못자고,
방치하면 독촉 메일 오는거 아닌가.
이런 식의 부정적인 글이 커뮤니티 게시판에 올라올거고...
응용 어플 끝글자 버그 고쳐드리면 여기저기서 고쳐달라고 문의와서 지옥문이 열리는거 아닌가.

이렇게 하면 이게 문제.
저렇게 하면 저게 문제.
nimf 로 밥먹고 사는게 아니라서 어쩔 수 없으니 이해 바랍니다.
서비스 유료화 한다고 하면 또 그게 문제.
밥먹고 사는게 바뻐서 저도 남들처럼 그냥 신경 끄기로 했습니다.
수고하세요.

Hodong Kim@Google의 이미지

취지 이해하고 변명의 여지가 없고
맞는 말씀입니다.
제 자신을 돌아보겠습니다.
감사합니다.

chahoolee의 이미지

님한테 기대 안 해요. 다 큰 사람 성격이 바뀌겠어요? 어차피 시간 지나면 또다른 남탓에 꽃혀갖고 또 프로젝트 접는 듯 하다가 다시 나타나고를 반복하시겠죠. 100%임. 그래서 주위에도 이 프로젝트는 이거 어떻게 될지 모르고 괜히 리포트 같은거 했다가 욕 먹으니까 관심 끄고 쓰지 말라고 합니다. 말해봐야 헛짓이니까 무관심이 약이라고 생각해서 언급을 안 했는데..

그런데 뉴비들은 이 반복된 역사를 잘 알지도 못하고 님 옹호하는 경우가 참 많아서 앞으로 같은 일이 다시 일어날 때에도 삭제되지 않을 만한 사이트에 이 댓글들을 쓴 거예요. 척박한 환경탓에 오픈소스 개발자가 유저들한테 갑질 당하고 있다 ㅎㅎㅎㅎㅎ 식으로 오픈소스판에 헬조선 스테레오타입 대입하는 선량한 문외한들 많거든요. 잘 하고 있는 다른 오픈소스 프로젝트와 개발자들까지 이상한 프레임에 대입하지 말고 이상하게 운영되는 오픈소스에 얽히지 않도록 다들 정신 차립시다.

Hodong Kim@Google의 이미지

이상하게 운영한 건 사실이고 잘 알겠습니다

Hodong Kim@Google의 이미지

잘 하셨고 주변에 널리 널리 알려주세요.
제가 하는 프로젝트에 참여하지 말라고 전파해주세요.
괜히 저 때문에 기분 감정 상하시면 안 되니까요.
이슈 올리신 분들께 정말 죄송합니만,
사실 이슈가 개발에 방해가 되서 2016년에 이슈 페이지(게시판)을 폐쇄했는데,
블로그에 댓글 달리고 이메일 오고 그러데요. 그래서 다시 열은 거에요.
이슈 게시판 폐쇄하면 그거 가지고 뭐라하시고,
열어 놓으면 해결해주지 않는다고 커뮤니티 게시판에 뭐라하시고.
사실 저도 어찌할지 모르겠네요.
제가 하는 프로젝트에 이슈 올리지 말고 참여하지 말라고 좀 꼭 전해주세요.
기분 나뻐서 하는 얘기는 아닙니다.
이슈 페이지만 읽기 전용으로 할 수 있는 옵션이 없어요.
그래서 전에 github 에 있을 때 프로젝트를 archive (읽기 전용)으로 해놓았던거죠.
솔직히 말씀드리면 이슈 올라오는게 싫습니다.
사실 님들 좋을려고 이슈 올리는거지 저 좋으라고 이슈 올리는 것은 아니잖아요.
하나하나 확인하려면 시간 많이 빼앗기고 버그가 아닌게 많고,
기능 요청이며 이런 거는 저 좋으라고 하는 것이 아니죠.
그런 거는 오픈소스의 특징이 아니라, 그냥 일반적인 소프트웨어 유지보수입니다.
코드를 주시는 것은 얘기가 다른데, 코드도 보내지 말라고 하세요.
그거 검토하려면 시간 빼앗기니까요.
이렇게 얘기해서 정말 죄송합니다.
끝글자 버그 10여년간 방치된 것 같은데 그냥 오픈소스 개나 줘 버릴 걸 그랬나봐요.
사람들마다 오픈소스에 대해 입장 차이가 있지만,
본인 스스로 아무리 생각해도 저는 오픈소스를 할 인간은 못 되는 것 같습니다.
컴퓨터 처분하고 신경 끄고 살다가 개인 이메일 오면 컴퓨터 구입해서 또 업데이트하고 그러고 나서 컴퓨터 또 팔고. 이걸 진짜 몇 번을 반복하는지... 감가상각 비용만 해도 상당합니다.
그게 제 입장입니다. 뭐 어차피 속으로 저를 또라이라고 생각하시는 분도 많으실 것 같고,
욕 하시려면 얼마든지 욕하시고, 이 글을 여기저기 전파하셔도 됩니다.
어차피 컴퓨터 직종도 아니고 nimf 업데이트할 때만 빼고는 컴퓨터 사용할 일도 없습니다.
컴퓨터 세계, 현실 세계 완전히 구분되어 있습니다.
그래서 욕 많이 하셔도 상관없습니다.
괜히 오픈소스 세계에 나타나서 폐를 끼친 것 같네요.
저 때문에 상처 받으신 많은 분들께 거듭 죄송하다는 말씀을 드립니다.
죄송합니다.
본인 스스로 아무리 생각해도 제가 또라이 같고, 많은 분들께 죄송합니다.
kldp 에도 본의 아니게 폐만 끼친 것 같네요.

chahoolee의 이미지

어찌할지 제가 알려드리죠. 앞에서도 간단히 포기하면 된다고 말했잖아요. 오픈소스 프로젝트가 그냥 남 좋은 일 하는 것 같으면 그냥 안 하면 되는 거에요. 조용히 그냥 헌법이 보장하는 권리대로 님 프로젝트 삭제하시든지 하시고 안 나타나시면 되는 거예요. 저도 멋모르고 님 옹호하는 뉴비들 만날 때마다 님이 상습범이라는 거 설명하는 거 참 피곤하거든요. 메일 받는 게 피곤하시면 한두번 삭제한 것도 아닌데 그냥 한 번 더 메일 계정도 삭제하시고 님 생활에 집중하시면 되요.

근데 그렇게 안 하죠. 결국 자기가 하겠다고 결정하고 나서 마치 누가 강제로 시켜서 하는 것 마냥 이거 때문에 건강이 망가지고 손실이 얼마나 났니 하면서 그게 프로젝트에 기여하는 사람들 탓이라고 공격하는 게 님의 오픈소스 방식이죠.

이런 말 아무리 해도 다시 반복될 거 잘 알고 있어요. 님이 지금처럼 자기 반성하는 듯 하면서 또 나타나서 반복한 적도 있었죠 ㅎㅎㅎㅎㅎ 하지만 이제는 님 기억하는 사람들도 많아졌고 지금 글 다 저장해 놓을테니 그 때 가서 보자고요.

chahoolee의 이미지

이 얘기를 하려고 했는데 이 말을 안 했네.

다솜 팀에서 님이 탈퇴해서 nimf 만든 거죠. 거기까진 좋습니다. 프로젝트 창립자가 의견이 안 맞아서 스스로 그만두고 fork하는 경우가 종종 있죠.

근데 님은 nimf를 만들면서 그걸 다솜에서 "이름을 바꿨다"고 선전하고 다니셨죠. 의미가 다르지 않습니까? 기존 프로젝트를 다 승계하면서 다른 이름의 프로젝트가 된 게 이름이 바뀌는 건데 이건 님이 탈퇴하면서 fork한 거잖아요. "이름 바꿨다"는 말은 그래서 잘못된 겁니다. 님이 스스로 팀을 떠났으면 남은 팀이 알아서 하게 놔둬야지 왜 자기 fork 판으로 바뀌었다고 선전하고 다닙니까?

emptynote의 이미지

다솜팀 없을 겁니다.

자기 힘들어서 인계를 해준 사람들한테 고마움을 느껴야 인간이지요.

그런데 님프 역사를 기술한 곳에서 그렇게 고마운 사람에 대해서 일언반구도 없지요.

원저작자가 자기 힘들어서 타인한테 인계를 했다가 고작 몇개월 후에

소스 포크하여 다른 이름으로 프로젝트 진행한다는 것 자체가 인계를 해 준 사람에 대한 예의가 아니지요.

상식이 있다면 다솜의 원 저작자가 새롭게 포크한 님프를 사용하지 구 다솜을 사용할리 없습니다.

즉 원 저작자의 새로운 포크는 인계 받은 다솜을 깔아 뭉개는 행위 그 자체입니다.

하여 새롭게 님프로 포크한것에 대해서 원 저작자는 고맙게 인수 인계를 해준 다솜 팀에 아주 많이 미안해 해야 하는것입니다.

그런데 호동님 글 어디에 이런 미안함이 있던가요?

자작쇼였기에 다솜 팀 자체가 없어 죄책감 느낄 대상이 없기에 글 어디에도 언급이 안된겁니다.

-------- 추가

만나서 인계 받은 다솜 개발자들과 호동님 그리고 저를 비롯한 kldp 분들
이렇게 3자 대면하면 모든 오해를 풀수있지요. 하지만 절대로 이것에 응하지 않을거라는데에 한표 던집니다.

Hodong Kim@Google의 이미지

추측성 글 자제하세요.
만난 적도 없습니다.
몇년전에 이미 개인 이메일 보냈어요.
자작쇼 아니에요.
3자 대면 응하려먼 시간, 장소는 누가 제공할 것이고 기회비용, 손해보는 비용은 누가 보상해줄건가요?
그냥 사람들은 모든 게 제 탓이죠!

Hodong Kim@Google의 이미지

그리고 당시 탈퇴가 의견이 안 맞아서가 아닙니다.
그리고 제가 님의 오해를 풀어드려할 의무가 없어요.
커밋 로그만 보더라도 알 수 있는데 보고도 믿지 않으면 어쩔 수 없죠

Hodong Kim@Google의 이미지

저는 님께서 말씀하시는 그런 사람이 아닙니다.
이미 수년 전에 양해를 구한 부분입니다.
수년 전의 일을 님께서 추측으로 비방해서는 안 되는 것입니다.
당시 다솜팀 분들 nimf 로 개명 후에 nimf 에 코드를 기여했습니다.
관련자, 당사자끼리 양해하고 상호 합의한 일입니다.
다솜팀분들 당시일에 대해 문제삼는 분 없습니다.
nimf 로 개명 후에도 협력을 해왔습니다.
nimf 문서도 작성해 주셨습니다.
고맙다는 얘기는 제가 님께 해야 하는게 아니라,
제가 그 분들께 이미 오래전에 고맙다고 말씀드렸습니다.

dasom 포크, nimf 개명 표현 방법에 대한 오해
https://kldp.org/node/160108

Hodong Kim@Google의 이미지

그 부분은 몇년 전에 양해를 구한 부분입니다.
당시 dasom, nimf 동시 수정해서 나아가는 걸로 그렇게 한 걸로 기억합니다.

emptynote의 이미지

오프라인에서 3 자 대면해서 오해를 풉시다.

이곳 KLDP 에서 인계한 다솜 개발자와 호동님 그리고 저를 비롯한 kldp 유저

이렇게 3자 대면 약속 장소와 시간을 정한후 만나 오해를 풉시다.

Hodong Kim@Google의 이미지

저는 님께서 말씀하시는 그런 사람이 아닙니다.
이미 수년 전에 양해를 구한 부분입니다.
수년 전의 일을 님께서 추측으로 비방해서는 안 되는 것입니다.
당시 다솜팀 분들 nimf 로 개명 후에 nimf 에 코드를 기여했습니다.
관련자, 당사자끼리 양해하고 상호 합의한 일입니다.
다솜팀분들 당시일에 대해 문제삼는 분 없습니다.
nimf 로 개명 후에도 협력을 해왔습니다.
nimf 문서도 작성해 주셨습니다.
고맙다는 얘기는 제가 님께 해야 하는게 아니라,
제가 그 분들께 이미 오래전에 고맙다고 말씀드렸습니다.

dasom 포크, nimf 개명 표현 방법에 대한 오해
https://kldp.org/node/160108

Hodong Kim@Google의 이미지

님께서 주장하신 불법적이고 폭력적인 방법과는 분명 차이가 있죠.
그리고 끝글자 버그는 단순한 버그가 맞아요.
마우스 클릭할 때 reset 하는 함수 하나만 추가하면 되거든요.
X 어플 경우 ftp://www.x.org/pub/X11R7.7/doc/man/man3/XOpenIM.3.xhtml
소스코드에서 XOpenIM 함수를 검색해보면 되고
GTK 응용 어플의 경우 소스코드에서 gtk_im_context 를 검색해 보면 됩니다.

이클립스, 리브레오피스의 자체 끝글자 버그를 어느 부분에 문제가 있는 건지 파악하고 있는데
못 고쳐드리는게 아니라 님같은 사람들 때문에 안 고쳐드리는 거에요.
님께서는 제가 한 얘기를 믿지를 않잖아요. 제가 개발자에요.
개발자를 업신여기는데 제가 고쳐드릴 이유가 없죠.
저를 인간 취급이나 해주시면 아주 고맙죠.

통합 입력 api 에 대한 글
https://cogniti-works.blogspot.com/2018/07/api.html

https://plus.google.com/+bagjunggyu/posts/DQXiJFmxr2z 에 댓글

통합 API 가 나오면 모두 해결됩니다.
입력 관련 api, 데스크탑 입력기 설정 관련 api, 데스크탑 입력 알림 관련 api 등이 있어야겠죠.
그러니까... 무슨 말이냐면...
nimf 사용하면 우분투에 인디케이터 나오잖아요.
telegram 사용해도 인디케이터 나오거든요.
그게 우분투 뿐만 아니라, 데비안, 우분투, 엘리멘터리OS, 아치, 레드햇 등 모든 리눅스 데스크탑에서 사용할 수 있는거에요.
그게 어떻게 가능하냐면, 옛날에 우분투에서 indicator 라이브러리를 발표를 했는데 그걸 다른 리눅스에서도 채택하여 사실상 표준이 된 겁니다.
그래서 입력기 개발자가 appindicator 하나만 지원하면 모든 리눅스 데스크탑에서 인디케이터를 사용할 수 있는거에요.
appindicator 나오기 전에는 gtk 용, kde 용 인디케이터를 각각 따로 만들어야 했었어요.
따라서 입력 관련 통합 api 가 나오고 모든 데스크탑에서 그 api를 채택하고, 입력기 개발자가 통합 api 만 지원하면 입력 관련 모든 문제가 해결됩니다.
그리고 당연히 api 에는 api 함수 이름만 있는게 아니라,
return 값, api 작동 순서, api 설명 등이 세부적으로 들어가죠.
수년전에 개발자들이 ibus를 GNOME 및 데스크탑에 통합하여 입력 문제를 해결하려는 시도를 했었는데, ibus 가 문제가 워냑 많아서 실현되지 않았습니다.
지금도 GNOME 를 보면 ibus 와 약간 통합되어 있습니다.
그 결과 fcitx 등의 입력기를 사용하는데 약간의 불편함이 따르지요. 그래서 fcitx 는 자신을 강제로 설정하는 코드가 있는데, 그것 때문에 nimf 설정하는데 애로사항이 생기고.

Hodong Kim@Google의 이미지

https://plus.google.com/+bagjunggyu/posts/DQXiJFmxr2z 에 통합 api 관련하여 써 놓은 댓글이 하나 더 있습니다. 깜박깜박하네요. ㅎㅎ

중국어, 일본어, 한국어는 조합해야 하기 때문에 키보드 레이아웃으로 해결할 수 없습니다.
키보드 레이아웃으로 해결할 수 있는 언어는 조합 규칙이 단순할 경우 테이블 방식으로 가능합니다. 독일어 같은게 그런 경우죠.
데스크탑 설치할 때 입력기를 선택한다고 하셨잖아요.
데스크탑이 입력기 정보를 알아야겠죠?

예를 들어서 linux_desktop_get_im_info() 이런 api 를 제정하고 GNOME, KDE 등에서 linux_desktop_get_im_info() 함수를 호출하면 linux_desktop_get_im_info () 함수를 구현한 입력기에서 입력기 정보를 돌려줍니다.
입력기 정보를 알아야 데스크탑이 입력기와 정보를 구조 받으며 설정할 수 있겠죠.
그러한 api 를 규정해야 한다는 것입니다.

linux_desktop_get_im_list ()
linux_desktop_get_im_info ()
linux_desktop_open_im ()
linux_desktop_close_im ()
linux_desktop_show_im_indicator ()
linux_desktop_hide_im_indicator ()
linux_desktop_im_filter ()
linux_desktop_set_keyboard ()
linux_desktop_set_keyboard_option ()
....
이러한 api 가 있어야 한다는 얘기입니다.
저런 api 가 옛날에 만들어졌는데 그게 XIM 입니다.
Xlib, XIM 이 현대적인 프로그래밍에 맞지 않기 때문에 사람들이 프로그래밍할 때 Xlib 대신에 Gtk, Qt 이런 걸 쓰는거고 Gtk, Qt 는 각각 자체적인 api 가 있습니다.
그러한 api 들이 통합되어야 한다는 의미입니다.
api 는 정보를 주고 받거나 일을 시키는 통로이고
실제 구현은 입력기에 구현이 되어 있습니다.

안드로이드 입력기를 보면,
그러한 명세가 있습니다.

developer.android.com - InputMethod | Android Developers

https://developer.android.com/guide/topics/text/creating-input-method

위의 api 는 안드로이드 통합 api 입니다.

리눅스에도 저러한 통합 api 가 있어야 된다는 얘기입니다.

아시겠지만 안드로이드에 엄청나게 많은 입력기가 있습니다.
그 입력기들이 위에 api 를 구현했기 때문에 동작하는 거에요.

안드로이드에서 무슨 어플을 쓰던 간에 한글 입력할 때 아무 문제도 없잖아요? 그쵸?

리눅스에도 저러한 통합 api 가 있어야 입력 문제가 근본적으로 해결이 되는거에요.

안드로이드 보면 LG 입력기, 구글 입력기, 중국어 입력기, 한국어 입력기 등 여러 입력기를 설치해 놓아도 사용자가 필요로 할 때 입력기 선택하는거 정말 쉽게 되어 있어요.

그게 어떻게 가능하냐면 통합 api 가 있기 때문에 가능한거에요.
그게 근본적인 해결책입니다.

그리고 만약에 nimf 가 안드로이드에서도 작동하려면 nimf 에 안드로이드 통합 api 를 구현해 놓으면 nimf 가 안드로이드에서 작동하게 되고,
마찬가지로 Mac, MS 도 각각 통합 api 가 있습니다.

요점:
안드로이드 입력 api 는 1개 있습니다.
Mac 입력 api 는 1개 있습니다.
MS 입력 api 는 1개 있습니다.

그러나,
리눅스 입력 api 는 gtkim, qt4im, qt5im, xim, wayland
이렇게 총 5개가 있습니다. 그게 하나로 통합되어야 한다는 말입니다.
keyborad 레이아웃을 GNOME, KDE, X 에서 만지고,
fcitx, ibus 에서 만지니까 그게 dvorak, us, fr, de 키보드 번갈아 가면서 사용할 때 문제가 발생하는 겁니다.
keyborad 레이아웃을 다루는 api 도 규정하고,
입력 관련 표시기 api 등 입력 관련 api 규정하여
하나로 통합해서 그걸 gtk, qt, x, wayland 에서 사용해야겠죠.
이해 되시죠?

gtk, qt im, wayland im 만 통합되도 참 좋을텐데...
서로의 이해관계 때문에 통합이 안 될거에요.
과거에는 유닉스 벤더들이 각자 이익이 맞아 떨어져서 함께 XIM 도 만들고 CDE 도 만들고 그랬었는데,

오픈소스 쪽도 각자 이해 관계 때문에 그게 쉽지 않을 거에요.
입력 문제는 기술적인 문제 때문이 아니라..
근본적인 문제가 안드로이드 입력 api 같은 통합 api 가 없는데서 비롯되는 겁니다.

joone의 이미지

제가 이해하는 한글의 끝문자 문제는 한글에서만 발생하며, 그 이유는 중국어와 일본어 글자 조합이 끝나면 enter를 눌러서 조합이 끝났다는 것을 IME가 애플리케이션에 아래 signal로 알려줍니다.
https://developer.gnome.org/gtk3/stable/GtkIMContext.html#GtkIMContext-commit

문제는 한글의 경우, 글자를 조합할 때, 다음에 어떤 자음이나 모음이 오느냐에 따라 글자 조합이 완성되거나 계속 조합상태에 머물 수가 있어서,
IME에서 그런 시그널을 발생하지 못하는 것입니다. 그래서 글자 조합중에 마우스 커서를 옮기면 마지막 글자가 복사되거나 그런 현상이 나타납니다.

저도 이 문제를 WebKitGtk+, Firefox에서 봤고 실제 버그를 수정해봤지만, 애플레케이션에서 flag를 넣어서 workaround수준으로 고칠 수 밖에 없습니다.
IME에서 조합이 자동적으로 끝날 때 마다 아래 signal를 app에 보내면 해결될 것 같습니다.
https://developer.gnome.org/gtk3/stable/GtkIMContext.html#GtkIMContext-preedit-end

오래전에 작업한 것이라 현재 IME 상황은 어떤지 잘 모릅니다. 혹시, 제가 잘못이해한 부분이 있으면 알려주시면 고맙겠습니다.

Hodong Kim@Google의 이미지

중국어나 일본어도 마찬가지 현상이 나타나는데
중국어나 일본어는 사용자가 스페이스키나 엔터키를 눌러서 명시적으로 커밋을 합니다.
그래서 끝글자 버그가 있던 말던 별상관이 없는거죠.
한글의 경우는 사용자가 명시적으로 커밋을 하지는 않죠.
컨트롤키가 명시적으로 커밋하기 위한 키는 아닌데 입력하다가 조합 중에 컨트롤키를 누르면 명시적으로 커밋이 되는데 우리가 그렇게 입력하지는 않죠.

끝글자 버그는 두가지 종류가 있습니다.

1. ibus, fcitx 등 비동기 통신 방식으로 인한 입력기 자체 버그

2. 응용 어플리케이션 자체 버그
2-1 마우스를 클릭할 때 입력 메소드를 리셋하지 않는 경우
2-2 포커스 아웃 신호를 발생하지 않아서 리셋되지 않는 경우

이클립스의 끝글자 버그는 원인이 2-1 입니다.
리브레오피스의 끝글자 버그는 원인이 2-1, 2-2 입니다.

그리고 gtk 라이브러리를 사용한 어플 gedit 에서 나타나는 끝글자 버그는 gedit 의 버그가 아니라 ibus 입력기 자체에 있는 끝글자 버그입니다. gtk 라이브러리에는 마우스를 클릭했을 때 입력 메소드를 리셋하는 코드가 들어 있습니다. 그게 동기적으로 처리되어야 하는데 ibus 는 비동기적으로 처리하고 있죠.

https://github.com/ibus/ibus/issues/1282

ibus 끝글자 버그가 왜 발생되는지 상세히 적어놓았습니다.

그리고 gtk 어플인 geany 에서 발생하는 끝글자 버그는 geany 버그입니다. 정확히는 Scintilla 버그입니다. 편집창에 Scintilla 를 사용합니다.

끝글자 버그가 없는 입력기 nimf + 끝글자 버그가 없는 어플 = 끝글자 버그 없음.

끝글자 버그가 있는 입력기 ibus + 끝글자 버그가 없는 어플 = 끝글자 버그 있음.

ibus 는 잘못 설계되어 ibus 구조상 그 버그를 고치기가 매우 어렵습니다. 그래서 새로 만든게 다솜 입력기. 안티 때문에 이름을 nimf 로 변경하여 지금에 이르고 있습니다.

Hodong Kim@Google의 이미지

아... 그리고
nimf 에는 끝글자 버그를 회피할 수 있는 기능이 있습니다.
gtk, qt im 은 클라이언트 모듈 방식으므로 클라이언트 포인터를 입력기가 알 수 있습니다.
그래서 gtk, qt 를 사용한 어플 중에 끝글자 버그가 있더라도 nimf 에서 마우스 클릭을 감지할 수 있어 끝글자 버그를 무력화시킬 수 있습니다.(nimf 에는 회피할 수 있는 옵션이 있습니다)

그러나 XIM 을 사용한 어플의 경우 마우스 클릭을 입력기가 알 수 있는 방법이 없는 것 같습니다. 그래서 XIM 을 사용한 어플에 끝글자 버그가 있는 경우 nimf 를 사용하더라도 그대로 노출됩니다.

Hodong Kim@Google의 이미지

끝글자 버그가 한 종류 더 있습니다.

2-3 응용 어플에서 preedit 를 그리지 않아서(또는 그리는 부분에 버그가 있어서) 끝글자 버그가 발생하는 경우, wine, krita, inkscape

2-3 의 경우 입력기에 작은 창을 띄어서 preedit 를 그려서 해결할 수 있습니다.
이미 nimf 에는 그러한 버그에 대한 기능이 옵션으로 있습니다.
그런데 사용자분들은 그게 또 불만이겠죠. 이러한 유형의 버그는 wine, krita, inkscape 프로젝트에 얘기해서 해결해야 할 문제죠.

joone의 이미지

자세한 설명 감사드립니다. 직접 IME도 개발하시고 버그 잡으셨네요.
저도 앞으로 nimf를 사용해야겠습니다.

chahoolee의 이미지

그 문제의 끝글자 버그의 상황에 대해 알고 있는 범위에서 한 마디 하면,

말만 들으면 nimf가 적어도 한국 사용자들은 평정해야 할 것 같은데 현실을 봅시다. 여러분 주위 한국 리눅스 사용자들 봐도 이런 거 쓰는 사람은 물론 아는 사람도 별로 안 보이는 게 현상황이죠. 왜 그럴까요? 그럴 수밖에 없는 이유가 있는데요.

첫째는 사용 패턴에서 이 버그가 문제가 안 되는 사용자가 꽤 있기 때문입니다. 한글 글자가 커밋되지 않은 상태에서 마우스 클릭을 하거나 포커스를 옮기는 상황이 문제인데 그렇게 안 쓰는 거죠. 바로 저 같은 사람인데 창을 옮기기 전에 저장 버튼을 누르든 저장 단축키를 누르든 그렇게 쓰거든요. 이런 경우가 절반 이상일 겁니다.

문제가 없다는 건 아니에요. 저와 다르게 문제가 되는 방식으로 많이 사용하는 불편한 사용자가 있죠. 그런데 그 중에서도 그냥 참고 쓰는 사람이 꽤 많습니다. 아니면 UIM이나 fcitx 정도로 갈아탔을 때 잘 돌아가는 케이스가 있어서 그냥 그걸 쓰기도 하죠. 널리 인정되는 안정된 입력기를 갈아탈 정도로, 그것도 변덕이 심하고 기여자들 공격하기로 악명 높은 개발자의 입력기로 갈아탈 정도로 불편하냐 고려해 봐야되는데 사람들이 저울질한 결과가 지금 상황인 겁니다.

그래서 저는 새로 프레임워크를 만들어서 브랜딩하고 마케팅하는 건 좋은 해법이 아니라고 생각해요. "그 버그 해결하려고 프레임워크를 새로 만드는 게 말이 되냐?" 라는 거죠. 기술적인 어려움 특히 ibus 비동기 어렵다는 거 다 이해하고 있는데요. 어려우면 어려운대로 고치는 게 낫지 다국어 구색만 갖춰놓은 한국 전용 입력기로 돌아가는 건 거부감이 듭니다. 네 물론 nimf 개발자님은 다른 입력기들 죄다 설계가 잘못돼서 다시 만들었다 그러는데 별로 공감이 안 가고, 그런 안티에 기반한 마케팅이 먹히겠어요? 프레임워크를 새로 만들었고 사용자들이 이걸 써서 문제가 해결되길 바라면 마케팅을 잘 하고 커뮤니케이션을 잘 해도 될까말까인데 이 쓰레드에서 보셨다시피 사람들한테 적대적으로 대응하는데 되겠냐고요.

정상적으로 돌아가는 오픈소스 프로젝트를 발전시키는 방향으로 갑시다.

onion의 이미지

1. 일단 저는 fcitx 씁니다. 다른 이유는 다 둘째치고라도 linux 용 telegram 하나 때문에요. telegram 소스를 받아서 nimf 등을 추가하는 patch 를 만들어서 새로 build 하는것보다는, 차라리 fcitx 를 쓰는게 더 경제적이라 생각하거든요.
2. ibus.. 미묘하게 쓸수록 뭔가 좀.. 여튼 어설퍼서...

nimf 에 대해서... 굳이 호동님은 많이 쓰기를 원하시는것도 아니고, 본인이 생각하고 쓰는대로 구현을 해 나가는것 뿐입니다. nimf 가 많이 쓰인다고 해서 의미도 없구요.

그리고 nimf 잘 보셨으리라 생각합니다만.. 지금은 여력이 안돼서 그렇지 일본어와 중국어 입력도 지원합니다. 말씀하신대로 한국어 전용 입력기는 아니라는 얘깁니다.

개인적으로는 nabi 등을 쓰고 싶지만... nabi 에 대한 지원도 꽤 오래전에 끊긴 상태에서 nimf 등의 시도는 충분히 좋다고 생각합니다. 굳이 문제라면 사용자와 개발자간의 커뮤니케이션 문제. 그리고 요청을 하면 당연히 들어줘야 한다는식의 사용자 request 정도가 되겠네요.

nimf 의 구현 방법 및 code 에 대한 기술적 논의라면 당연히 개발자분과 상관없이 논의되어야 하는 부분이라 생각하지만.. 글쎄요.. 이걸 사용자단의 감성문제로 끌어내리는건 올바른 방향이 아니라고 생각해서 첨언해봅니다.

-----새벽녘의 흡혈양파-----

chahoolee의 이미지

여기 뉴비 한 분. "요청을 하면 당연히 들어줘야 한다는식의 사용자 request"라는 말씀, 이게 바로 잘 알지도 못하고 옹호하는 겁니다. 사용자 중에 진짜 버릇 없는 사람도 있고 그거 때문에 맘상할 수도 있죠. 그런데 이 분은 그 정도가 아니에요. 기분 나빠지면 이슈 올리는 말 그대로 모든 분들을 공격하는 분입니다.

nimf는 한국어 전용 맞아요. 일본 사람이나 중국 사람 쓰는 사람 본 적 있어요? m17n 라이브러리 거기 대충 넘겨짚어서 만든 한국어 입력기가 한국어 입력에 못 쓰는 것처럼 실제로 못 씁니다. 사용하는 사전 부터 요즘에 거의 안 쓰는 것들.

onion의 이미지

1. 오픈소스 어디에도 개발자가 사용자의 request 에 일일히 반응해야 하는 의무는 없습니다.
2. 저는 윗 내용에서 개발자를 옹호한 적이 없습니다... 내용을 천천히 읽어보시죠.
3. 커피값 수준이지만 nimf 이전의 다솜때 아주 약간의 후원을 한 적이 있습니다. 일면식이 없어두요. 그게 개발자에 대한 제가 할 수 있는 참여방법이라 생각했습니다.
4. chahoolee 님이 한국어만으로 쓰신다고 해서 그 입력기가 한국어 전용이 되는건 아닙니다. 홍보가 부족하다고 해서, 사용자가 적다고 해서 nimf 의 구조 자체가 다국어 입력방법을 지원하지 않는건 아니거든요. 그거야말로 코드나 기술에 대한 논의 없이 chahoolee 님의 자의적인 판단이겠죠.

제가 telegram 에 대한 fcitx 의 문제를 어떻게 알게 되었냐면 바로 nimf 개발자의 답변덕분입니다. 답변을 보고 telegram 소스를 받아서 빌드해보고, 아 그 얘기가 맞구나... telegram 에서 제대로된 입력기 지원을 하지 않는게 문제이며, 그건 nimf 의 문제가 아니라 telegram 이 QT 를 뜯어서 쓰고있기 때문이구나.... 라고 검증했기 때문이죠. 적어도 그 과정에서 "지친 개발자의 신경질적인 느낌" 이 안들었다면 거짓말이겠습니다만, 그럼에도 얼마나 이런 얘기를 많이 들었겠나 싶어 이해할 수 있겠다 싶었습니다.

지금 제의하신 내용은 nimf 의 기술적인 부분에 대한 내용이 아니라 그냥 개발자가 내 상식에서 이해가 가지 않는다.. 수준의 내용에 지나지 않습니다. 적어도 그런 방향으로 놔두기에는 토의된 내용이 꽤 읽을만한 내용들이 있고, linux 등의 *nix 기반의 입력기에 대한 괜찮은 논의가 될 수 있기때문에 방향을 바로잡자는것에 불과합니다.

그리고 버그보고를 fix 하는거.... 그거 개발자가 당연히 해야하는거 아니에요. 필요하면 돈받고 해줘야 하는거 맞습니다. GPL 로 소스 license 를 풀었다고 해서 사용료가 "무료" 일 수는 있지만 기술지원까지 "무료" 라는 의미는 전혀 아닙니다.

이전글에서 적었다시피 저는 모종의 사용상의 이유로 nimf 대신 fcitx 를 사용하고 있습니다. 이거라고 문제가 없는건 아닙니다만, 그럼에도 telegram 이 제가 주로 하는 업무에서 중요한 부분을 차지하고 있으며 linux desktop 이 주 업무 환경이기 때문에 telegram 의 update 이슈를 생각해서 fcitx 를 그대로 쓰기로 했습니다. 혹시 필요하다면야 nimf 를 fork 받아서 할 수도 있겠습니다만... 지금은 개발자를 그만둔지도 오래돼서 취미로 하는것 외에는 그렇게 할만한 열정 및 필요를 느끼지 않는군요. 그래서 취미로 하고있는 pharo 등은 메일링리스트에도 필요한 report 및 feedback 을 받고 있습니다. 그러니 오픈소스 문화를 아예 모른다는 걱정은 접어두셔도 되겠네요 :D

이와는 별개로 GPL 자체는 원 저작자와 상관없이 코드를 보고 필요하면 fork 를 하면 될 일입니다. 최근의 카카오와 tadpole 의 경우에서도, 원 저작자가 도의를 넘어서 행사할 수 있는 권리가 생각보다 많지는 않아요. 다만 개인적인 입장에서 telegram 에서 공식적으로 nimf 를 지원하고, nimf 의 저작자가 이이상 개발을 진행하지 않으며, 제가 nimf 를 유용하게 사용한다면, 원 저작자에게 동의정도는 구하고 프로젝트를 fork 할 수는 있겠네요. 지금도 제 하드 안에는 HanX, KIMS, byeroo, HanIM 및 mac os X 용의 구름입력기 소스는 재워두고 있으니까요 :D

-----새벽녘의 흡혈양파-----

chahoolee의 이미지

반대로 제가 뉴비로 보이시는 모양인데 ㅎㅎㅎㅎㅎ 아 네 오픈소스 개발자 고쳐줘야 하는 의무 없죠. 거기에 대해 반대했나요? 고쳐줘야 하는 의무 없으니까 그냥 리젝하면 되는 거죠. nimf 개발자의 방식은 단순히 그게 아닙니다. 이 분은 거기에 대해 과잉대응하고 스스로 피해의식에 사로잡혀 공격하는 분입니다. 사용자들이 개발자한테 버릇없게 요청하고 있는 걸로 단정해서 말씀하시는데 그건 사실이 아니에요! 말만 그대로 믿으면 세상 트롤들이 특정 오픈소스 개발자한테 주기적으로 몰려가서 극딜하고 있는 기이한 생태 현상을 보이는 것 같은데 그럴리가 없죠. 양파님이 오래 되신 분인 것은 알고 있지만 개발자와 사용자의 입장을 그렇게 단정적으로만 바라보신다면 앞으로 세월이 더 지나더라도 뉴비 신세를 못 면하실 겁니다 ㅎㅎㅎㅎ 그리고 그런 소스는 이제 쓸데 없으니 지우세요. ^^

앞에서 말씀드렸다시피 저는 이 입력기를 만든 이유 자체부터 공감을 못하는 사람입니다. 즉 전 이 입력기에 대해 바라는 게 없고, 그래서 fork하면 된다는 말은 의미 없고요. 전 언급을 하고 싶지 않았고 무시가 답이라고 생각하는 사람이지만 최근 nimf 프로젝트에서 이슈 유료화 같은 걸 시도하다가 사람들이 다 떠나니까 공격 포인트를 여러 외부 사이트에서 찾고 계시는 모습에 한마디 했을 뿐입니다.

onion의 이미지

지극히 개인적인 취미로 irix 등을 가끔 켜거든요. 쓸만한 한글입력기가 없어서 나중에라도 빌드하려고 쟁여둔 소스입니다. 다른사람의 사정을 정확하게 모르면서 쓸모없으니 지우라고 하시는건 경우가 아닌듯 하네요.

-----새벽녘의 흡혈양파-----

chahoolee의 이미지

그리고 telegram은 그렇게 안 해도 되요. 아마 telegram 사이트에서 배포하는 바이너리 빌드할 때 qt 포함해서 빌드하는 거 보고 말하는 것 같은데 그거 말고 그냥 배포판에서 예쁘장하게 빌드한 telegram 패키지 쓰면 됩니다.

onion의 이미지

한글입력 fcitx 아니면 안됩니다. telegarm 에서는 QT5 를 자체적으로 빌드해서 씁니다. 텔레그램 내부에서 사용하는 코드때문에 QT5 자체를 patch 해서 별도로 사용하는데요, 덕분에 QT5_IM_MODULE 환경변수를 잡아도 linux 용 telegram 에서는 작동을 안합니다. 나중에 telegram 개발자가 자신이 사용하는 QT5 안에 fcitx 관련 코드를 넣었어요. 그것때문에 linux 용 telegram 은 fcitx 밖에 한글 입력이 안됩니다.

제가 ubuntu 18.04 를 쓰고 있는데.. 이걸 설치할 시점까지만 해도 ibus 와 nimf 로는 한글입력이 안됐었으니.. 별 차이는 없을거같은데 최근의 우분투에서는 변동이 있는건가요? 지금의 우분투를 설치한 시점에는 안됐던걸로 기억합니다만.... 된다면 fcitx 에서 다시 ibus 로 옮겨갈 수도 있겠군요 :D

제가 chahoolee 님을 뉴비 취급한적은 없는거 같습니다만? 저를 뉴비취급하시길래 제가 생각하는 바를 오해없이 정확하게 전달되게 적었을 뿐입니다. :D

-----새벽녘의 흡혈양파-----

chahoolee의 이미지

잘만 쓰고 있습니다..라고 말하기에는 버그가 있기는 한데 하여간 ibus로 되요. 말씀하시는 건 telegram 사이트에서 배포하는 바이너리에요. 텔레그램 사이트 보지 말고 그냥 배포판에서 만든 버전 깔아 쓰면 되고 nimf도 안 될 이유가 없어요.

onion의 이미지

해당되는 부분 참고해두도록 하겠습니다. 감사합니다 :D

-----새벽녘의 흡혈양파-----

chahoolee의 이미지

아마 이런 파일 보고 넘겨 짚고 얘기한 것 같은데요. ㅎㅎㅎㅎ 패치에도 떡하니 써 있듯이 "static build"용으로 쓸 때만 필요한 겁니다.

https://github.com/telegramdesktop/tdesktop/blob/f68cefbdc1f5131b930c2acf3c2dc0ede07f538e/Telegram/Patches/qtbase_5_6_2.diff#L524

static build하기 위해 포함한 것일 뿐 대단한 qt 수정이 아니라는 거죠. 배포판에서 빌드한 버전에서는 다 shlib으로 링크되어 있습니다. 결론적으로 nimf 개발자가 양파님한테 잘못된 사실을 알려주고 삽질을 시켰던 거니까 좋아하실 것도 없습니다.

onion의 이미지

fcitx 와는 별개로 gentoo 에서 빌드를 해본적이 있습니다. 1년전의 얘기기는 합니다만 gentoo 에 기본적으로 들어있는 QT 로는 빌드가 정상적으로 안되더라구요 QT 에서 뭔가 없다고 하면서 말이죠.

이 건과는 별개로 OS 에 포함된 QT 로 빌드를 한번 더 시도해봐야 겠군요 :D

-----새벽녘의 흡혈양파-----

Hodong Kim@Google의 이미지

사실 관계 정정 차원에서 말씀드립니다.
제가 잘못된 사실을 알려드린 것이 아닙니다.
nimf telegram 이슈는 다음 링크에서 확인하실 수 있습니다.

https://gitlab.com/nimf-i18n/nimf/issues/16

https://github.com/5HARK/im-nimf-qt5/issues/1

https://github.com/telegramdesktop/tdesktop/pull/5050

telegram 은 qt 를 스태틱 링크하고 있습니다.
그래서 입력 관련 모듈을 스태틱으로 포함해야 입력기가 작동합니다.
ibus qt 모듈의 경우는 qt 공식 소스에 이미 들어가 있습니다.
그래서 별다른 작업 없이 telegram 에서 동작하는 거고,
fcitx 는 telegram qt 소스에 넣어서 컴파일(입력 모듈을 스태틱 링킹)해야 작동하는 것입니다.

Work with official QT
https://github.com/telegramdesktop/tdesktop/issues/1815
여기 보시면 Qt 를 스태틱으로 링킹한 이유를 짐작할 수 있습니다.
Qt 에 자체 패치를 가해서 사용하고 있습니다.

Can you support these input method ( gcin and hime) just like fcitx ?
https://github.com/telegramdesktop/tdesktop/issues/3129

telegram 에서 nimf 를 사용하려면 아래처럼 누군가가 작업을 해야 하는 것입니다.

Add hime inputcontext plugin for linux version
https://github.com/telegramdesktop/tdesktop/commit/60c84bbf51db184bfe01e35b0948edf6f49b2e76

위는 telegram 공식 소스, 공식 바이너리를 기준으로 말씀드렸습니다.
개인이 변경한 telegram 소스를 기준으로 말씀드린 것이 아니고,
개인이 telegram 에 qt 를 동적 링크(dynamic linking)해서 배포하는 것이 있는지 없는지 그것까지는 모르겠고, 그런게 있다면 별다른 작업을 하지 않아도 nimf 가 작동할 것입니다.

소스코드 또는 사실에 입각하여 글을 작성해주시면 좋겠고,
개발자의 의견을 존중해주시기 바랍니다.
ibus 는 잘못 설계된 것이 맞고 비동기 방식의 입력기는 그 자체가 버그인 것입니다.
이거는 노이즈 마케팅 이런게 아니고 사람들이 ibus, fcitx 개발자한테는 안 그러면서 저를 자꾸 탓하고 욕을 하니, 왜 나한테만 이러냐는 의도로 사실(팩트)에 입각하여 ibus 가 잘못 설계되었다는 말씀을 드리는 겁니다.

제가 처음에는 ibus 를 어떻게든 수정하려 했었습니다.

2015년 1월에 작성한 이슈입니다.
clients can choose whether to commit preedit text before resetting im or not
https://github.com/ibus/ibus/pull/15

https://github.com/ibus/ibus/pull/15/commits/1eb236a0989c56b6dc47aac4516c0acf406edc68

When clicking mouse, last preedit text is not committed and it follows mouse cursor.
https://code.google.com/p/ibus/issues/detail?id=1264
 
Cause 1:
ibus_im_context_filter_keypress() with --enable-key-snooper always returns FALSE, so GtkTextView doesn't reset input method properly.
 
Cause 2:
If there is commit() in reset(), reset() doesn't wait commit(), so last preedit text is committed after reset().
 
If you compile with --disable-key-snooper, this approach using ibus property(CommitPreeditTextBeforeResettingIM) can solve the bug.
Clients can choose whether to commit preedit text before resetting im or not, checking ibus_bus_get_ibus_property (bus, "CommitPreeditTextBeforeResettingIM")
 
diff --git a/bus/ibusimpl.c b/bus/ibusimpl.c
index f99307ad..829834e4 100644
--- a/bus/ibusimpl.c
+++ b/bus/ibusimpl.c
@@ -61,6 +61,8 @@ struct _BusIBusImpl {
 
     gboolean embed_preedit_text;
 
+    gboolean commit_preedit_text_before_resetting_im;
+
     IBusRegistry    *registry;
 
     /* a list of BusComponent objects that are created from component XML
@@ -194,6 +196,11 @@ static const gchar introspection_xml[] =
     "          name='org.freedesktop.DBus.Property.EmitsChangedSignal'\n"
     "          value='true' />\n"
     "    </property>\n"
+    "    <property name='CommitPreeditTextBeforeResettingIM' type='b' access='readwrite'>\n"
+    "      <annotation\n"
+    "          name='org.freedesktop.DBus.Property.EmitsChangedSignal'\n"
+    "          value='true' />\n"
+    "    </property>\n"
     "    <method name='CreateInputContext'>\n"
     "      <arg direction='in'  type='s' name='client_name' />\n"
     "      <arg direction='out' type='o' name='object_path' />\n"
@@ -408,6 +415,7 @@ bus_ibus_impl_init (BusIBusImpl *ibus)
 
     ibus->use_sys_layout = TRUE;
     ibus->embed_preedit_text = TRUE;
+    ibus->commit_preedit_text_before_resetting_im = TRUE;
     ibus->use_global_engine = TRUE;
     ibus->global_engine_name = NULL;
     ibus->global_previous_engine_name = NULL;
@@ -1640,6 +1648,49 @@ _ibus_set_embed_preedit_text (BusIBusImpl     *ibus,
     return TRUE;
 }
 
+/**
+ * _ibus_get_commit_preedit_text_before_resetting_im:
+ *
+ * Implement the "CommitPreeditTextBeforeResettingIM" method call of the
+ * org.freedesktop.IBus interface.
+ */
+static GVariant *
+_ibus_get_commit_preedit_text_before_resetting_im (BusIBusImpl     *ibus,
+                                                   GDBusConnection *connection,
+                                                   GError         **error)
+{
+    if (error) {
+        *error = NULL;
+    }
+
+    return g_variant_new_boolean (ibus->commit_preedit_text_before_resetting_im);
+}
+
+/**
+ * _ibus_set_commit_preedit_text_before_resetting_im:
+ *
+ * Implement the "CommitPreeditTextBeforeResettingIM" method call of
+ * the org.freedesktop.IBus interface.
+ */
+static gboolean
+_ibus_set_commit_preedit_text_before_resetting_im (BusIBusImpl      *ibus,
+                                                   GDBusConnection  *connection,
+                                                   GVariant         *value,
+                                                   GError          **error)
+{
+    if (error) {
+        *error = NULL;
+    }
+
+    gboolean commit_preedit_text_before_resetting_im = g_variant_get_boolean (value);
+    if (commit_preedit_text_before_resetting_im != ibus->commit_preedit_text_before_resetting_im) {
+        ibus->commit_preedit_text_before_resetting_im = commit_preedit_text_before_resetting_im;
+        bus_ibus_impl_property_changed (ibus, "CommitPreeditTextBeforeResettingIM", value);
+    }
+
+    return TRUE;
+}
+
 /**
  * bus_ibus_impl_service_method_call:
  *
@@ -1732,6 +1783,8 @@ bus_ibus_impl_service_get_property (IBusService     *service,
         { "ActiveEngines",         _ibus_get_active_engines },
         { "GlobalEngine",          _ibus_get_global_engine },
         { "EmbedPreeditText",      _ibus_get_embed_preedit_text },
+        { "CommitPreeditTextBeforeResettingIM",
+                                   _ibus_get_commit_preedit_text_before_resetting_im },
     };
 
     if (g_strcmp0 (interface_name, IBUS_INTERFACE_IBUS) != 0) {
@@ -1781,6 +1834,8 @@ bus_ibus_impl_service_set_property (IBusService     *service,
     } methods [] =  {
         { "PreloadEngines",        _ibus_set_preload_engines },
         { "EmbedPreeditText",      _ibus_set_embed_preedit_text },
+        { "CommitPreeditTextBeforeResettingIM",
+                                   _ibus_se