이번에는 으레 관례적으로 하던 중간 보고(다음 버전 개발 근황) 없이 곧장 새 버전 소식을 전하게 되었다. <날개셋> 한글 입력기 8.6이 나왔다.
이번에도 예외없이 왜 2016년이 다 돼서 인제야 도입됐나 싶은 새로운 기능들이 많이 도입되었다. <날개셋> 한글 입력기는 8.5 때보다 더욱 완전함을 향해 나아가게 되었다.
앞으로 최대 두세 번 정도 더 버전업 해서 9.0 정도는 갈 수 있을 듯하다. 무슨 작업을 더 할지 로드맵은 이미 다 잡혀 있다.
※ IME와 연결되는 키보드 드라이버를 변경하는 기능
<날개셋> 한글 입력기에서는 글쇠배열 편집을 통해 드보락이나 콜맥 같은 다른 외국어 글자판을 같이 쓸 수 있다.
그러나 외부 모듈의 경우, 이것은 IME 방식으로 글쇠를 인식하지 않는 환경에서는 무용지물이다. 단축키나 암호 입력을 그런 영문 글자판으로 할 수는 없으며, 잘 알다시피 IME가 동작하지 않는 모드로서 '쿼티 자판' 내지 '빈 입력 스키마'가 언제나 반드시 추가돼야 했다. 이것 때문에 불편하다고 지금까지 사용자로부터 문의도 많이 들어왔었다.
물론 외부 모듈은 IME로서 자기 영역만 책임지면 되지 굳이 키보드 드라이버의 영역까지 개입할 필요는 없다. 하지만 이번 8.6 버전에서는 한글 IME와 연결되는 키보드 드라이버를 간단하게 바꿀 수 있는 UI가 추가됐다. native 빈 입력 스키마 상태에서 드보락 내지 콜맥을 한글 글자판과 병용하는 사용자에게 굉장한 유용한 기능이 될 것으로 보인다.
이제 외부 모듈에서 제어판을 연 뒤 "시스템 계층 - 고급 시스템 옵션"을 가 보면, "한글 IME와 연결할 영문 키보드 드라이버"라는 콤보 상자가 나타나 있다.
디폴트는 한국어 키보드 드라이버인 kbdkor로, 맨 앞에 있다. 자주 사용하는 걸로 판단되는 드보락과 콜맥은 곧장 2~3순위이며, 나머지 외국어 드라이버들은 이름의 알파벳 순으로 등재돼 있다. 운영체제에 존재하는 모든 키보드 드라이버 DLL들을 자동으로 탐색한 것이다.
이걸 변경한 뒤 제어판을 '확인'으로 닫으면.. 외부 모듈이 직접 레지스트리를 고치는 게 아니라 운영체제의 레지스트리 편집기를 통해서 간접적으로 고친다. HKEY_LOCAL_MACHINE 레지스트리 값을 변경하기 위해서는 관리자 권한이 필요한데, 외부 모듈은 자기가 독립적인 프로그램이 아니라 DLL이기 때문이다. (권한이 없을 수도 있음)
확인 질문에 '예'로 대답한 뒤 운영체제 로그인만 다시 하면 바뀐 글자판이 적용된다. 단, 당장 로그인 암호를 입력하는 기준 영문 글자판부터 바뀌기 때문에 절대 주의해야 한다. 잠시 암호를 없애거나 숫자 기반으로 변경할 것을 권함.
한국어 이외의 다른 외국어 키보드 드라이버에서는 (1) 한국어 키보드에 존재하는 고유한 한영/한자 글쇠를 인식하지 못하므로 단축글쇠 차원에서 Shift+Space 같은 다른 방법을 써야 한다.
(2) 또한, Windows XP 이전의 운영체제에서는 <날개셋> 한글 입력기의 기반 드라이버만이 바뀌지만 Vista 이후부터는 모든 한글 IME들의 기반 드라이버가 이걸로 바뀌어 버린다. 내 프로그램은 문제가 없지만 MS 한글 IME의 경우 한글 글쇠배열까지 영문 글쇠배열을 기준으로 뒤죽박죽 바뀌어 버리기 때문에 타 한글 IME를 사실상 제대로 쓸 수 없게 된다는 점을 주의하기 바란다.
※ 키보드 드라이버의 글쇠를 UI에서도 유동적으로 인식
위의 작업은 그 자체만으로는 그냥 일부 매니아 유저가 손으로 레지스트리를 일일이 고쳐야 했던 것을 더 편하게 해 주는 UI 껍데기를 추가한 것에 불과하고..
더 중요한 건 이제부터다. 이 김에 키보드 드라이버와 관련된 추가적인 연구를 진행했다.
<날개셋> 변환기가 콜맥 키보드 드라이버 드라이버를 불러오려 하면 리가처(일명 dead key) 테이블 쪽에서 버퍼 overflow가 나서 죽던데 이 문제를 해결했다. 해당 드라이버가 리가처들을 이례적으로 잔뜩 갖고 있어 보이긴 했지만, 내 프로그램도 어떤 경우든 당장은 죽지 않아야 하므로.
그리고 획기적인 건.. 제어판 포함하여 내 프로그램에서 글쇠배열를 보여주는 부분에서 기준 글쇠배열이 단순 쿼티 고정이 아니라 지금 사용 중인 드라이버의 배열을 보여주게 했다.
다음 그림을 보면 확실하게 감이 올 것이다. 사용자가 배당한 검은 글자 말고 위의 흰 글자들.. <날개셋> 한글 입력기 1.0 이래로 지금까지 이건 무조건 쿼티 고정이었다. 그러나 현재 키보드 드라이버가 드보락과 연결돼 있으면 이제는 드보락 배열로 표시된다. 세벌식 최종 기준으로 초성 ㅇ은 쿼티의 J 자리에 있지만 드보락에서는 H 자리이다.
키보드 드라이버라는 게 그 본질은 스캔코드와 가상 키코드 사이의 대응 규칙에다가 각종 dead key 조합을 담고 있는 '테이블'이다. 실행 가능한 기계어 코드나 매크로· 스크립트가 들어있어서 보안 문제를 걱정해야 하고, 신뢰성 보장을 위해 디지털 서명이라도 받아야 하는 그런 물건은 아니다. 그래서 Windows 9x 시절에는 키보드 드라이버는 실제로 *.kbd라는 형태의 그냥 데이터 파일이었다.
그러나 NT 계열에서는 키보드 드라이버는 그냥 static한 구조체 포인터를 되돌리는 함수를 구현한 DLL 형태이다. 무슨 다국어 UI DLL처럼 리소스/데이터만 들어있는 DLL도 아니고 엄연히 함수 실행 부분이 일단은 있다. 같은 테이블을 되돌리더라도 각 아키텍처에서 메모리로 직통으로 올릴 수 있게 구조체 멤버 같은 건 적절히 align/padding이 처리돼 있어야 한다.
그리고 바로 이런 이유에서.. 같은 32비트 x86용 드라이버라 하더라도.. 순수 32비트 OS용과, x86-64 OS에서 64비트하고 같이 운용되는 32비트 드라이버는 서로 호환이 되지 않는다. 본인은 이걸 이제야 알게 됐다. 후자는 비록 포인터가 4바이트이더라도 구조체의 포인터들은 32비트가 아닌 64비트 단위로 듬성듬성 padding돼 있어야 하더라. 어쩐지 그래서 콜맥 드라이버도 받아 보면 i386, amd64뿐만 아니라 wow64가 따로 있었구나. 통상적인 DLL을 만들 때는 그걸 구분할 필요는 없었는데 굉장히 흥미로웠다.
※ 단항 연산자
다음 버전에서 추가하네 마네 하면서 떡밥만 날렸던 ++ -- 단항 연산자를 그냥 이 기회에 추가해 버렸다. 덕분에 손 놓은 지 꽤 오래 됐던 복잡한 수식 해석 코드들을 다시 실컷 복습했다. 하지만 작업은 생각만치 복잡하거나 어렵지 않았다.
++얘는 문자열로 표현할 때 +가 두 개 있는 것과 형태를 구분하기 위해, 우선순위 조정이 아닌 다른 사유로 괄호가 필요한 첫 사례가 되었다.
물론 공백만 삽입해 줘도 되긴 하지만, 괄호로 확실하게 구분하는 게 더 보기 좋아서 괄호를 사용하기로 했다.
2008년부터 현재까지 쓰이고 있는 5.0 방식 입력 설정 포맷은 구조 확장으로 인해 더 쓰이지 않는 데이터 청크라든가, 호환성 유지를 위해 누더기 땜질식으로 확장된 청크가 늘어나고 있다. 특히 5.0 이후로 backspace 동작 관련 옵션들은 판이하게 확장되었으며 저장 방식도 바뀌어 왔다. 거기에다 연산자의 추가는 레거시 파일 포맷의 무질서도(?)를 더욱 키웠다.
하지만 파일 포맷을 또 변경하는 건 유니코드에 한글 자모가 더 추가되는 정도의 이변이 발생하지 않는 한, 아직까지는 최대한 억제하고 있다. 이건 우리나라 경제로 치면 화폐 개혁을 하는 것과 같은 급의 파격적인 변화이기 때문이다.
<날개셋> 변환기가 이제 오랜만에 대공사를 해야 할 것이다. 지금처럼 3~4.x를 5.x 포맷으로 바꾸는 게 아니라 5~8.x 포맷을 새 포맷으로 바꾸는 일을 해야 할 것이다.
※ UI
사소한 UI 쪽으로 가면, 모든 대화상자들의 외형을 총체적으로 재검토해서 버튼들의 크기와 간격을 최대한 일관성 있게 재조정했다.
마소에서는 Windows 표준 GUI 가이드라인 차원에서 명령 버튼들의 크기(특히 '확인'과 '취소')를 50*14로 할 것을 권하고 있다. (단위는 픽셀이 아니라 dlu라고 대화상자 내부에서만 쓰이는 추상적인 단위임) 내 프로그램은 그건 준수하지 않고 45*16을 쓰고 있으며, 이번에 크기를 다 그걸로 통일시켰다.
달랑 '확인', '취소' 두 글자.. 영어로 표현해도 OK와 Cancel에 불과한 그 단어를 집어넣기에는 50*14는 너무 납작하기 때문이다. 가로만 너무 길고 세로는 짧다. '맑은 고딕'은 그나마 글꼴 metric의 종횡비가 좀 개선됐지만, 과거 굴림의 경우 그 정도가 더 심하다.
요건 내 프로그램이 의도적으로 Windows 표준 GUI와는 약간 다른 정책을 취하는 부분임을 밝힌다. 사실, 국내에 애초에 그런 것까지 일일이 다 신경쓰고 만들어지는 Windows용 프로그램 자체도 별로 없지만.
그리고 오랫동안 암묵적으로 남아 있는 버그라면 버그인데..
잔상이 생기는 문제를 두 군데 해결했다.
하나는 날개셋 제어판 창을 가로로 쭉 키웠을 때, 날개셋 에디트 컨트롤에만 non-client의 테두리 부분에 남는 성가신 잔상이다. (아래 그림에서 오른쪽을 보라)
난 그리라는 이벤트가 왔을 때 그린 잘못밖에 없는데 왜 이런 현상이 생기는지는 개인적으로 잘 모르겠다.
그리고 또 하나는 일단은 고전 테마에서만 존재하는 문제 같은데, 대화상자 우측 하단에 있는 크기 조절 손잡이가 인근의 버튼 영역을 덮어써서 생기는 잔상이다.
근본 원인을 해결했다기보다는 그냥 경험적으로 문제를 피해 간 것에 가깝긴 하지만, 그래도 예전보다는 UI 경험이 더 개선됐을 것이다. 이 두 잔상은 기술적으로 문제를 피해 간 방식도 서로 완전히 달랐다.
※ high-DPI 지원, 기타
그리고 모든 구현체 프로그램들에 내부적으로 high-DPI aware 플래그를 추가했다. 이건 마소가 제시하는 표준을 준수했다는 점에서 장점이 될 수 있지만 일부 사용자에게는 단점 및 악재가 될 수도 있다.
125% 같은 high-DPI에서 대화상자들이 뿌옇게 확대+보정된 저해상도로 나오는 게 아니라 깔끔한 고해상도로 나올 테니 그건 장점이다. 하지만 편집기의 경우 어떤 DPI에서도 본문 글꼴이 무조건 16*16 픽셀로 찍히기 때문에 고해상도 + 대형 모니터에서는 이제 글자가 너무 작아서 알아보기 어려울 수도 있다.
이건 자체 비트맵 글꼴을 사용하는 내 프로그램의 근본적이고 고질적인 문제이므로 당장 쉽게 해결 가능하지는 않다. 요 특정 윈도우만 확대+보정해서 출력하는 기능이라도 써야 하지 않나 싶다. 호환성의 왕중왕인 Windows API 중에 뭔가 있을 것 같으나.. 높은 우선순위로 살펴보겠다고는 장담을 못 하겠다. 앞서 얘기했듯이 <날개셋> 한글 입력기는 문자 입력 관련 기능만 연구하기도 갈 길이 너무 먼 상태여서 말이다.
저것들 말고도..
- 외부 모듈에서 문자표 대화상자가 가끔 제대로 동작하지 않던 것을 개선했다.
- 기본 입력 스키마의 추가 인식 글쇠를 수정하면 처음에 날개셋문자 값이 무식한 10진수로 찍혀 나오는 엄청난 버그를 왜 인제 발견했는지.. 당장 고쳤다.
- 제어판의 글쇠배열 편집 페이지에서 '상태변수' 수식은 문법이 틀려도 종료 시에 에러가 찍히지 않게 했다. (어차피 설정 파일에 저장되지도 않고.. 창을 닫는 마당에 에러 체크 따윈 전혀 필요하지 않음)
- 언제부터 이런 어처구니없는 버그가 들어갔는지 모르겠는데.. 편집기가 0바이트인 파일을 아예 열지 못하고 에러 처리하던 버그를 모 사용자로부터 제보 받아서 즉시 개선했다.
- 현재 편집기는 파일을 저장할 때는 원래 있는 파일의 날짜와 크기를 체크해서 내 프로그램이 아닌 외부에서 변경되었으면 그걸 사용자에게 확인시킨다. 그런데 그 다음으로, 열었던 파일을 아무 변경 없이 그냥 닫더라도 파일이 외부에서 변경되었으면(날짜 크기 변경, 삭제) 재저장할지 사용자에게 확인시키게 했다. 단, 애초부터 읽기 전용으로 열지 않았고 하드디스크에 있는 파일에 한해서이다. (네트웍, 이동식 드라이브에서 연 파일은 제외)
- Google 단모음 키보드를 예제 입력 방식으로 추가했다. 기존 두벌식에서 겹자음과 ㅑㅕㅛㅠ만을 제거한 간소화 버전인데 나름 모바일에서의 가성비가 좋다. '하꾜'는 연속 입력이 되지만 '학교'는 중간 딜레이가 필요하다. 천지인처럼 모든 종성에서 타이머를 줘야 하는 게 아니라 ㅂㅈㄷㄱㅅ 요 자음에 대해서만 주면 되는데, 그 값을 글쇠배열 수식에서 소문자 변수를 통해 지정하게 했다.
이렇게 사소하게 고치고 더한 아이템들이 더 있다.
두벌식에서 글쇠 수를 지금보다 더 늘리지 않고 shift도 쓰지 않고 쌍자음 음절 경계 구분 문제를 해결하는 방법은.. 어쩔 수 없이 (1) 타이머를 쓰거나, 아니면 (2) 초성은 다음에 이어지는 모음의 특성을 추가로 이용해서 쌍자음을 구현하는 것 정도가 전부인 듯하다.
※ 타자연습
끝으로 타자연습의 경우, 입력기 프로그램들과 마찬가지로 high-DPI 플래그를 넣었으며 이 외에도,
- 도움말의 '세벌식 만물상 → 운영체제에서 두세벌식 전환을 어떻게 하죠?'에.. Windows 8~10 기준으로 글자판을 전환하는 방법이 지금까지 너무 오랫동안 빠져 있는 것을 확인하여 설명을 추가했다. 확실히 운영체제의 버전이 올라갈수록 전환하는 방법이 더 복잡해져 왔다.
- 좀 심각한 문제이던데, 타자연습을 종료한 뒤에도 잔여 프로세스가 완전히 사라지지 않고 남아 있던 문제를 해결했다. 구형 운영체제에서는 이런 일이 없는 것 같던데 10에서는 문제가 있었다. Windows에서 프로세스는 단순히 실행을 끝내고 리턴만 하는 게 아니라 ExitProcess를 호출해 줘야 어디서나 확실하게 종료되는 듯하다.
- 문장/글 연습에서 사용자가 추가한 디렉터리에 있는 연습글들은 우클릭했을 때 해당 연습글을 (1) 바로 편집하거나 (2) 파일이 있는 곳을 탐색기로 열어서 바로 찍어 주는 명령을 메뉴에 추가했다.
지난 3.5부터는 사용자 연습글을 추가하는 방식이 XML 기반에서 디렉터리-파일 기반으로 확 바뀌었기 때문에 이제 사용자가 연습글 리스트 XML을 직접 고칠 일은 거의 없을 것이다. 그렇기 때문에 인제 와서 큰 의미는 없겠지만, 이번 버전에서는 연습글 경로에서 내부 압축 꾸러미 이름을 식별하는 구분자를 @에서 *로 전격 변경했다.
별표는 파일 시스템 차원에서 절대로 들어갈 수 없는 문자이기 때문에 이제 *.tc 파일 자체가 경로 중간에 @가 섞여 있더라도 이제는 아무 문제 없이 취급 가능하다.
※ 맺는 말
<날개셋> 한글 입력기에 대해 대외적으로 들어오는 의견은 크게 다음과 같은 것들이 있다.
- 일반 사용자: 타 플랫폼 포팅도 좀 해 달라.
- 일반 사용자: 요런 요런 상황에서 외부 모듈이 제대로 동작하지 않는다. 심하면 뻑나기까지 한다.
- 좀 컴덕후 기질이 있는 분들: 오픈소스화해 달라.
그런데 잘 알다시피 이것들은 모두 나로서는 전혀 현실성이 없으며, 예측 가능한 미래에 가능하지 않은 것들이다.
1. 리눅스, 맥 OS, 심지어 안드로이드까지 하나씩 골고루 다 요청을 받았었다. 특히 안드로이드는 그냥 화면 터치만 지원하는 게 아니라 외부 키보드를 연결할 수도 있다. 그렇기 때문에 PC 키보드 지향 입력 시스템인 내 프로그램도 이제 충분히 진입할 여지가 있다.
하지만 알다시피 <날개셋> 한글 입력기는 여러 플랫폼을 지원하는 프로그램이 아니라 반대로 단일 플랫폼에서 여러 구현체(편집기, 외부 모듈, 입력 패드)를 제공할 정도로 Windows에만 특화돼 있다. 한 플랫폼에 올인하면서 입력 기능 연구만 하기에도 본인은 시간이 부족하다. 포팅은 나 혼자서 할 수 있는 일이 아니다.
2. 이런 신고는 십중팔구가 내 자리에서 재연이 안 되는 것들이다. 내 프로그램도 외부 모듈의 짬밥이 이미 10년 가까이 돼 가는데, 기본적인 안정성은 이미 충분히 확보했다. 한글 입력이 전혀 안 되거나 아예 crash가 발생할 정도의 치명적인 문제는 내 프로그램 단독이 아니라 같이 돌아가는 백신이나 보안 프로그램과의 충돌 때문에 발생한다. 그리고 본인은 백신 같은 거 전혀 안 쓰는 사람이다.
내 프로그램이 디지털 서명이 된 채로 배포된다면 이런 문제가 더 줄어들 수 있겠지만 이 역시 아마추어 개인 개발자 차원에서 가능한 일은 아니다. 디지털 서명을 발급받으려면 돈이 드는 건 둘째치고라도 신원 보증을 위해 사업자 등록증 같은 것도 있어야 한다. =_=;;
3. 전에도 한번 입장을 밝힌 바 있지만, 무슨 전세계 오픈소스 진영의 해커 덕후들이 다 한글과 세벌식 자판을 쓰기라도 하지 않는 이상, 오픈소스화한다고 해서 누가 내 프로그램을 타 OS로 짠 포팅해 준다는 보장도 없다. 또한 내 노력에 대한 보상이 돌아오는 것도 아니다. 명예 보상쯤이야 지금 같은 클로우즈드 소스 체계에서도 이미 충분히 받고 있다.
내 프로그램은 심하게 갈라파고스화된 1인 독재 체제에서 폐쇄적으로 개발되고 있긴 하지만, 현실적으로는 이게 최선의 조치이다.
Posted by 사무엘
