kile+fcitx 끝글자 버그 수정법. (kile 코드들 고치는 방식을 시도함)

https://cogniti-works.blogspot.com/2018/09/blog-post_4.html

위 블로그 포스팅을 보고 힌트를 얻어서 하기로 한다. 

한글입력기 끝글자 관련해서 검색해보면, ibus는 문제가 많아서 fcitx로 간다느니 뭐 그런글들이 많다. 하지만 중요한건 내가 fcitx를 쓰고 있는데도 이런문제가 생겼다는거다. 

많은 입력기들은 cjk외에는 ime입력기 같은거 없어도, compose키나 alt_gr키 같은거 이용하면, 되서그런지 중국,일본, 한국 말고는 관심이 없는 듯 하다.  

그러다 보니, 끝글자 버그 이슈는 20년이 넘는 아주 오래된 이슈, 한국인 기준으로는 버그이지만, x-window qt gtk 개발자도 기반 어플리케이션 개발자들도 무관심한 버그이다. 뭐 자기들은 영어나 영어기반 언어 쓴다 이거다. 

여기저기 보면, 코드 고쳐서 입에다 떠먹여줘도 그거 버그 아니라서 이슈 닫는다는 반응을 겪었다는 사람들이 보인다. 

뭐 어쩌겠는가, 목마른 사람이 우물을 파야지. 끝글자 버그는 초성중성종성을 조합해서 글자가 나가기 전에 ime가 조립을 하면서도 화면에는 보여줘야하고 다른 글자를 누르면 수정도 해야하는 복잡한 한글 같은 언어에서만 나타난다. 뭐 로만자(??)를 사용하는 일본, 중국애들도 겪을 것 같은데도 2022년 오늘 내게도 똑같이 일어나는거 보면 , 한글만의 문제인건가 싶기도 하다. 

뭐 이제 더 이야기할 것은 없고, 저 블로그에서, qt, gtk, X11 어떤 gui프레임웍을 쓰는지에 따라 검색해야할 키워드를 주었기에, 반신반의 하고, 검색을 해서 답을 얻었다. 

kde는 qt위에다가 올린 것이니, 

grep -i qinput -R . 이라는 

검색으로 찾았다. eventfilter.cpp라는 파일에 해당하는 부분이 있다. 

kile은 위젯이 워낙많기에 modal dialog가 아닌 widget도 아주 많이 화면상에 비친다. 그렇지만 우리의 텍스트 입력은 당연히 text input 위젯에 바로바로 적용이 되어야 한다. 그러다보니 중앙에서 키보드 event를 감시한다. 

kile은 또 그리스어 특수문자 입력 때문인지, ime event도 감시한다. unicode text가 나올 때, tex format으로 할지 unicode문자를 그대로 보여줄지 뭐 이런걸 하려고 하는거 같은데, qimeevent라는거에... 잠시 속아서 헛짓을 좀 했다. 

다시 돌아와서, 마우스 더블클릭 이벤트 위에서 마우스 press 이벤트를 가져오자. 

 11 +#include <QInputMethod>

 19 +static void  reset_im()  

20 +{

21 +  QInputMethod* ime =   QGuiApplication::inputMethod();

22 +  ime->reset();

23 +}

 31 +    else if(e->type() == QEvent::MouseButtonPress) {

32 +      reset_im();

33 +    }

 34      else if(e->type() == QEvent::MouseButtonDblClick) {
]

QInputMethod 를 Include한다. 

reset_im함수를 static하게 만든다. (네임스페이스 오염방지)

mouse press 이벤트를 받으면 reset_im 함수를 호출한다. 

원래의 마우스 입력 이벤트가 그대로 사용되어야 하므로 return을 하지 않는다. 

(결국은 맨 뒤로가서 return false가 되어 해당 qwidget에 이벤트가 전달)

빌드해서 설치한다. 

결과적으로 끝글자 버그는 사라졌다. 

kate에 이버그가 있언는지 기억이 안나는데 그거 확인하고 고쳐야겠다. 

chrome에는 이 버그가 없는데, 대신, 강제로 조합을 중간에 깨뜨리는 미친 짓거리가 일어난다. 

요거 아무래도, 이벌식 사용자 기준으로 끝글자 버그 해결하려고... 뭐 하다가 이렇게 된거 같은데, 

요건 고칠 엄두가 안나므로, 주소표시줄에서 글자를 만들어서 복붙을 하고 있다. 

아무래도, chrome 에서 EDITOR를 불러서 강제로 텍스트 편집기를 띄우는 플러그인을 찾아봐야겠다. 어차피 짜증나는거, vim이나 emacs라도 올려서 써봐야지.

X-Modmap 사용기 - 중분내용물 1. shift-insert -> dead_greek

 

한동안 alt. intl. 영문 키보드를 쓰다가 한글 설정이랑 충돌이 일어나서, 

그냥 basic us 키보드로 돌아온 상태... 그리고 원래 dead_greek은 지원하지 않았음. 

뭐 수정은 쉽게 하지만, 아예 level3를 사용하지 않는 키보드에다가 저런거 설정하기 빡세서,

compose key setup에서 dead_greek 조합은 있으므로 dead_greek만 만들면 되서 

구글링을 하니, StackExchage에서 Shift+Insert로 사용하고 싶다는 사람이 있어서 대충 보고 따라함. 

먼저 

$ xmodmap -pke|grep -i 118

keycode 118 = Insert dead_greek Insert dead_greek

로 입력해서 상태를 보면, 보통은 Insert No_Symbol Insert 이렇게 보면, 근데 나는 이렇게 셋팅되었음

하는 방법은 간단함

$ xmodmap -e "keycode 118 = Insert dead_greek"

이제 완성되었음. 이제 당신은 아주 쉽게 alpha등을 입력 할 수 있음

αβ shift+insert, a   shift+insert, b 로 쉽게 입력 가능함. 

근데 이게 맥에서 붙여넣기 명령이라... 몇군데서 충돌이 있는 것을 방금 발견함. 키를 바꿔야 겠음

$ xmodmap -e "keycode 42 = g G g G dead_greek dead_greek "

3번째 부터는, lock키와 관련되어 있는거 같고, 일단 5개를 입력했을 경우는 적용이 안되므로 다음처럼 하기를 바람.

음. 이건또 적용이 안되네... 보류다. shift insert로는 잘되니 뭐. 

생각을 넓히자. X-Touch mini Hack. Story.

서문

  예전에, USB Snooping, MIDI Snooping 등을 알게 되어서, Windows에서만 버튼 셋업을 바꿀 수 있는 X-Touch Mini의 설정 프로토콜을 확인해 보려 하였다. 뭐랄까 뻔하다고 생각했다. USB 드라이버를 따로 구성해서 할 것 같지는 않았고, USB MIDI 드라이버 상에서 sysex로으로 구현했을거라 생각했다. 

  그리고서는 바로 snooping을 시도했으나, 

 

Beringer X-Touch Editor v1.21은 미디 연결을 독점적으로 연결하도록 강제되어, snooping 툴에서는 입출력 내용을 볼 수가 없어서 이것 저것을 시도해보다 안되었다. 

뭐 대신, Mackie Control 모드가 어떤 식으로 Endless knob의 신호를 보내고 받을 수 있는지에 대해서 알게 되는 순에서 마무리가 되었다. X-touch는 마키모드가 아니더라도 이런식의 신호를 주고 받을 수 있도록, 노브설정을 할 수 있다. (3가지의 모드가 있음. )

아 그렇다. 계획은 실패였다. 

변화

정말 사고 싶어서 장비를 샀지만, 내가 전문 음악하는 사람도 아니고, gimp에 사용하려고 해도 gimp의 미디입력 플러그인이 너무 허접해서 사용이 어려울 뿐아니라, 내 프로그래밍 실력이 허접하다보니 모딩도 시도하다가 시간이 부족해 못한 관계로, 장비가 혼자 구석에서 놀고 있었다. 

그래도, 시간이 날 때마다 새로운 드라이버가 올라왔을까봐, 홈페이지를 찾아가 구경해보고(이제는 그만해야함 너무 오랜시간 동안 업데이트가 없음)

누군가는(중덕, 양덕 !!) 은 해낼거라 믿고, github에서 X-touch mini를 한번씩 검색해 보는데 이번에 누군가가 해냈음을 발견 했다.   

perl 사용법. (

 perl -lane    "/^Time/ and print $F[2] 

l은 맨 끝이 개행으로 끝나게 해서 실행 이후도 터미널이 깔끔하게 하는것.

a는 자동으로 chopt를 수행해 라인 검색하면 자동으로 $F[0..n]으로 담김. awk의 대안 사용

 cat text   |perl -ne 's/Time/Melong/g'  

text의 Time 을 Melong으로 변환 줄의 끝까지 여러번 수행 (g)

perl -i.bak -ne 's/Time/Melong/g' file           sed -i 와 같은 방식 내용을 바꿈.

full line strings --> $_

current loop number -->>>> $.

이것 들을 이용하여, 출력도 가능.

startline=1

endline=2

'while(<>) {

    /^Time/ and startline=$.

    /^Loop/ and endline=$.

}    

seek(<STDIN>, 0,0);

while( $.>startline and $.<endline) {

print $_;

};

'

sca.coffee 25.13 - 새로운 브루잉 차트를 향하여를 보고.

https://sca.coffee/sca-news/25/issue-13/towards-a-new-brewing-chart

원본은 위 주소로가서 보세요.

인터넷에 검색하면, 핸드드립에 물을 얼마나 써야하나요라고 검색하면, 

다음과 같은 차트를 많이 만납니다. 영국기준이 어떻고, 미국기준이 어떻고 하고 말이죠.

 사실 저 중간에 선안에서  조절하는 방법이 궁금해서 찾아본건데 아무래도 안나옵니다. 뭘 의미하는지가 궁금했는데 아쉽습니다. 

얼마나 볶았는지 어떤 크기로 분쇄했는지 얼마나 천천히 했는지 이런것과 관련된 것일까요 저는 잘모르겠네요. 당연히 안다고 생각하는건지 그것이 무엇인지 설명하는 사이트가 안나오네요. 일단은 추출시간과 관련있다고 생각하기로 했습니다. 뭐 시간이 무한대로 가면 저렇게 선형이지는 않겠죠. 천천히 우리면 당연히 더 많은 성분들이 녹을 것이고 종류에 따라 녹아드는 시간이 다르다보니 다른 변화율을 가질 것이니까요.

저 차트가 나타내는 것은 다음과 같습니다. 적절한 물1L당 커피의 비율이 어떻게 될 때, 사람들이 선호하는 커피가될 것인가에 대한 이야기입니다. 일단 저 중간을 관통하는 선은 55g으로 18:1 정도를 말합니다. 

그러나, 핸드드립을 하고나면, 커피가 머금는 물의 양이 두배의 무게 정도로 생각을 하기 때문에, 18:1이지만, 16:1이 본인이 섭취하는 양과 관련이 있습니다. 160ml(물은 160g이니까) 의 커피를 먹으려면, 커피를 10g 정도를 사용해서 하라는거죠. 

저 X축은 수율이라고 표현하는데, 커피 고형분중 유용(?)성분비를 말하는듯 합니다. 18~22%

정도를 선호하는걸로 나와있습니다. y축은 물속에 얼마만큼 들어갔는지를 나타냅니다. 저 concentration은 용액의 농도와는 달리, 분산액속(화합물이 아닌 혼합물..설탕물,흙탕물 중학교 과학책에 나옴)  부유물의 비율을 말하는데, 폴리머 피직스에서 쓰는 그 값이 맞는지는 잘 모르겠네요. 고형분의 비율은 1.15-1.35정도를 선호한다고 합니다. 

제가 제대로 이해했다면, 추출이후에 커피에 물을 섞는 행위는 y축 값만 변화시키는 행동일까요. 근데 당연히 물타면, 커피도 연해지지만 덜 쓰기도 할텐데 이해가 참으로 어렵네요.