Changwoo's Hacks

fontconfig 2.6부터 기본 글꼴이 은글꼴로 바뀐다. 2.6 RC를 사용하는 데비안 등 배포판에는 이미 적용되었다.

버그 13569

이제 특정 배포판 패치는 그만..

2.22에서 특히 바뀐 점


원문은 팬그램(pangram)으로 유명한 The quick brown fox jumps over the lazy dog 문장이다. 그놈 2.20 이전에는 MS 윈도우즈가 했던 것처럼 "무궁화꽃이 피었습니다"라고 했었다. 그런데 알고 보니까 MS는 "무궁화꽃이 활짝 피었습니다"라고 쓰고 있었는데 "활짝"을 빼먹었다는 것... 약간 실망(?)을 하고 바꾸는 김에 다른 대안이 없을까 하다가 마침 "스폰지" TV 프로그램에서 팬그램에 대해 소개를 하다가 한글 자모별로 한번씩 사용한 이 팬그램 문장이 나오길래 쓰게 되었다. (무궁화꽃이 피었습니다 놀이가 일본 전래 놀이인 건 둘째치고라도...  요즘 애들은 길에서 많이 놀질 않아서 그래서인지 잘 알지도 못하는 것 같다.)

GTK+ 2.12에 포함된 GtkBuilder 기능에 대해 탐험해 보면,

GtkBuilder는 libglade의 대체품이라고 말할 수 있다. GUI의 구성을 코드 내에서 하지 않고 XML 파일로 기술하고 런타임에 그 XML을 읽어들여서 UI를 구성한다. libglade를 써 봤다면 별로 새로운 건 아니겠지만, 일단 GTK+에 포함되어 버렸으니까 추가로 libglade를 링크할 필요가 없다는 장점이 있다. 또 일부 glade가 커버하지 못하고 있는 TreeView 따위의 복잡한 위젯도 쓸 수 있다. 요즘에 하드코딩으로 GTK+ 코딩하는 사람들이 거의 없다는 걸 생각해 보면 충분히 GTK+에 포함될 만한 기능이다. (GTK+가 너무 커진다 싶으면 언젠가 메이저 버전 뒤엎겠지.)

간단히 맛보기 필요한 소프트웨어: GTK+ 2.12 이상, pygtk (컴파일이 귀찮으므로)

import gtk
builder = gtk.Builder()
xml = '''
<interface>
  <object class="GtkWindow" id="cwwindow">
    <child>
      <object class="GtkButton" id="cwbutton">
        <property name="label">Build Me</property>
      </object>
    </child>
  </object>
</interface>
'''
builder.add_from_string(xml, len(xml))
win = builder.get_object('cwwindow')
win.show_all()
gtk.main()

위 파이썬 코드를 실행하면 이런 창이 나온다.

libglade를 사용해 봤다면 XML 문법만 다르지 별 다른 점을 느끼지 못할 것이다. 또 대부분의 glade 파일은 gtk 2.12에 포함되어 있는 gtk-builder-convert 프로그램을 이용해 GtkBuilder용 XML 파일로 변환할 수 있다. ui.glade라는 파일로 저장을 했다고 하면,

$ /usr/bin/gtk-builder-convert ui.glade ui.xml
$ python
Python 2.4.4 (#2, Aug 16 2007, 02:03:40)
[GCC 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gtk
>>> builder = gtk.Builder()
>>> builder.add_from_file('ui.xml')
>>> builder.get_object('window1').show_all()
>>> gtk.main()

GtkBuilder의 장점은 "눈에 보이지 않는 오브젝트"를 정의할 떄 나온다. 특히 libglade를 사용할 때는 UI 디자인에서 지정하지 못하고 코딩으로 해결해야 했던 복잡한 위젯, 특히 모델/뷰/컨트롤러 개념이 필요한 TreeView, ComboBox 따위의 "모델"을 XML 파일에 집어 넣을 수 있다. 이 부분때문에 디자인과 프로그램이 완전히 분리하지 못했던 많은 코드를 분리할 수 있다.

<interface>
  <object class="GtkListStore" id="treemodel">
    <columns>
      <column type="gchararray"/>
      <column type="gint"/>
    </columns>
    <data>
      <row>
        <col id="0">cwryu</col>
        <col id="1">2</col>
      </row>
      <row>
        <col id="0">crew</col>
        <col id="1">1</col>
      </row>
      <row>
        <col id="0">clue</col>
        <col id="1">3</col>
      </row>
      <row>
        <col id="0">None of the Above</col>
        <col id="1">4</col>
      </row>
    </data>
  </object>
  <object class="GtkWindow" id="window1">
    <child>
      <object class="GtkTreeView" id="cwbutton">
        <property name="model">treemodel</property>
        <child>
          <object class="GtkTreeViewColumn" id="column0">
            <property name="title">Name</property>
            <child>
              <object class="GtkCellRendererText" id="r0"/>
          <attributes>
        <attribute name="text">0</attribute>
          </attributes>
        </child>
      </object>
    </child>
    <child>
          <object class="GtkTreeViewColumn" id="column1">
            <property name="title">Number</property>
            <child>
              <object class="GtkCellRendererText" id="r1"/>
          <attributes>
        <attribute name="text">1</attribute>
          </attributes>
        </child>
      </object>
        </child>
      </object>
    </child>
  </object>
</interface>

위의 XML 파일을 마찬가지의 python 코드로 돌리면,

이렇게 스트링-숫자 형식의 "모델"과 cwryu/crew/... 따위의 데이터를 포함할 수 있다.

현재 그놈 프로그램은 거의 glade만을 사용하고 있다. 내년 3월이나 9월 릴리스에서 libglade에서 옮겨올 수 있을까? 많은 사람들이 어려움을 호소하는 걸 보면, 얼핏 보면 깔끔하고 좋아 보이지만 실제 적용하기는 쉽지 않은 모양이다.

한메일Express라는 것에 당첨되었다...라고 하는 메일이 한메일에 쌓였길래, 보려고 했더니 왠일인지 똑같다. 뭔가 이상해서 환경설정에서 Express 사용여부를 설정하면서 자세히 관찰해 보니까 뭔가 다른 페이지를 들어가려고 하다가 나가는 현상이 보였다. 그 순간에 나왔다 사라지는 한마디, "IE, Firefox 1.5, ... 이상에서만 사용할 수 있습니다."

"지금 iceweasel 무시하나요?"를 머리속에 대뇌이면서 about:config 에서 user-agent 값을 firefox로 고쳐버렸다. 그러니까 무리 없이 한메일Express로 잘 전환되었다.

그런데 머리 속을 스치고 지나가는 생각. "지금까지 티스토리의 에디터가 epiphany에서만 동작하고 iceweasel에서 동작하지 않은 원인이 설마 이것일까?" 지체없이 티스토리로 로그인, 에디터를 써 본 결과 맞았다. 얄밉게 잘 동작하는 에디터...  (epiphany에서도 찾아보니까 예전에 user-agent를 고친 설정이 남아 있었다.) 한메일은 그렇다 쳐도, 태터툴즈 에디터가 user-agent를 보고 다르게 동작할 줄은 꿈에도 몰랐다.


PS. "어쩔 수가 없이 이렇게 만들었다"라고 하기엔 iceweasel이라는 user-agent로 잘 동작한 웹용 에디터들이 너무 많다.

그놈 에볼루션은 비교적 최근에 만들어진 메일 프로그램이라서 그런지 인터넷 메일의 표준에는 맞지만 현실과는 동떨어진 방식으로 동작하기도 한다. 슬프게도 한글과 관련된 부분에서 그런 모습이 많이 보인다.

예를 들어 좀 구버전의 MS-Outlook 혹은 MS-Outlook Express에는 헤더를 RFC2047 인코딩할 때 UTF-8로 인코딩하면 제대로 읽지를 못했다. 멀티바이트 인코딩은 본문 인코딩과 관계없이 대충 UTF-8로 보내는 정책을 사용했기 때문이다. 이렇게 동작하는 게 틀린 건 전혀 아니고, RFC2047을 지원하면서 UTF-8 인코딩이 지원되는 환경이므로 당연히 MS-Outlook의 잘못이고, 이 제목이 제대로 읽히도록 MS가 Outlook을 고쳐야 하는 게 맞다. 하지만 현실적으로 MS-Outlook은 사용자가 많아서 무시하기 힘든데다가 상업용 소프트웨어는 이러한 버그가 수정되려면 너무 오래 걸린다. (최근 버전에 고쳐질 때까지 2-3년은 걸린 듯)  표준을 지키는 다른 방법이 있으면서, 많이 사용하는 프로그램의 버그를 피해가는 방법이 있다면 꼭 에볼루션이 맞다고 고집할 필요는 없지 않을까? 하지만 게으른 개발자의 속성상 자기 잘못도 아닌데 귀찮게 고치기도 힘들 노릇이어서 결국 아직까지도 그렇게 동작한다. 내가 직접 본문이 EUC-KR일 때 제목이 EUC-KR 인코딩되도록 패치까지 만들었지만, 적용될 수는 없었다. (기술적인 이유도 있었다. 에볼루션의 코드의 메일 처리 라이브러리쪽에서 헤더를 독립적으로 UTF-8 인코딩해 버리는 구조였는데, 메일 설정이 넘어가도록 고치려면 상당히 귀찮은 작업이 필요하다.)

오히려 이런 문제는 MS-Outlook같은 데스크탑 프로그램보다는 각종 웹메일들에서 특히 잘 드러난다.  (아무래도 웹메일들이 데스크탑용 프로그램보다는 메일 표준을 구현한 완성도가 비교적 떨어지는 게 사실이다.)  마침 한메일이 개선사항을 모집한다고 하니 에볼루션과 한메일이 메일을 주고받을 때 생기는 버그 및 기타 리눅스 환경에서 생기는 문제를 짚어본다.

(1) Q 인코드된 제목의 디코딩

이 문제는 보고를 했는데 고객센터에서도 전달되었다고 하고, 다른 경로(?)로도 전달되었는데 우선순위가 밀렸는지 아직 버그가 남아 있는 상태이다.

위의 예에서와 같이 에볼루션에서 보내는 메일의 한글 제목은 UTF-8 인코딩하게 되는데, 그것도 Quoted Printable 인코딩이다. 그런데 에볼루션에서 메일을 이렇게 보내면,


한메일에서는 이렇게 공백이 밑줄로 나온다..


그런데 이상하게도 클릭해서 본문을 읽어보면 제대로 나와 있다.

Subject: =?UTF-8?Q?=EC=A0=9C=EB=AA=A9?=
        =?UTF-8?Q?_=ED=85=8C=EC=8A=A4=ED=8A=B8?=

"제목 테스트"라는 제목을 UTF-8 QP 인코딩하면 위와 같이 된다. RFC2047에 따르면 Quoted Printable을 디코딩할 때 밑줄(_)을 공백으로 해석해야 하는데 실수를 한 것 같다. 그런데 대체 왜? 메일 본문을 읽어보면 제대로 나오는 걸까? 메일 목록과 메일 본문의 QP 디코드 코드가 다른 걸까?


(2) 첨부파일 내용 인코딩

에볼루션이 아니라 (이제 거의 모두 UTF-8환경인) 리눅스 환경과의 호환성 문제이지만, 첨부 파일의 Content-Type의 charset 정보를 제대로 인식하지 않는다.


Content-Type의 charset 정보를 무시하고 EUC-KR로 해석하는 듯?
 

--=-ObVHrT1mp3C0HEttZi/U
Content-Disposition: attachment; filename*=UTF-8''%EC%97%90%EB%B3%BC%20%EB%A7%8C%EC%84%B8.txt
Content-Type: text/plain; name*=UTF-8''%EC%97%90%EB%B3%BC%20%EB%A7%8C%EC%84%B8.txt; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
 
=EC=97=90=EB=B3=BC =EB=A7=8C=EC=84=B8
 
 
--=-ObVHrT1mp3C0HEttZi/U--

(3) EUC-KR 페이지의 한계

다음이 많은 부분에서 UTF-8 페이지로 변환하고 있지만, 아직 한메일은 그렇지 못하다. 그래서 아무래도 해외 메일을 받는 용도로는 한계가 있을 수밖에 없다. 일본어 메일만 해도 많은 한자가 물음표 투성이가 된다.



(4) 보너스#1 - 빈 파일을 첨부하면

이 글을 쓰면서 발견한 건데...  사이즈가 0인 파일을 첨부한 다음에 첨부한 파일을 열려고 하면 오류가 발생한다.

--=-Jc22aP0z5j1kvSIVKmG+
Content-Description: =?UTF-8?Q?=EC=97=90=EB=B3=BC?=
    =?UTF-8?Q?_=EB=A7=8C=EC=84=B8=EC=97=AC?=
Content-Disposition: attachment; filename*=UTF-8''%EC%97%90%EB%B3%BC%20%EB%A7%8C%EC%84%B8.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
 
 
--=-Jc22aP0z5j1kvSIVKmG+--

(5) 보너스#2 - HTML 메일이 싫어요~

또 찾아낸 명백한 버그, 보낼때 하단에 있는 옵션을 어떻게 하든 항상 HTML 메일만 날아온다.

debconf6 동영상에서 keith packard가 말한 xorg 관련 비디오를 보다가 (대충 기억나는 대로 재구성 번역):

X 스펙은 렌더링 방법을 픽셀 단위로 정확하게 기술하고 있습니다. 이게 좋다고 생각하는 분?  한 분인가요?  틀렸습니다.  사람들은 모두 그 의견에 반대합니다.  정확한 픽셀 렌더링을 규정하면 구현하기도 쉽고 테스트할 때는 특히 좋습니다. 정확히 어떤 픽셀에 렌더링됐는지 검사하면 되니까요.  하지만 사용자는 더 빠른 걸 원하고 정확한 픽셀에는 신경쓰지 않습니다.
...
일례로 대부분의 그래픽 하드웨어는 선을 그릴때 정확한 Bresenham 알고리즘을 사용하지 않고 feedback이 필요없기 때문에 더 빠른 DDA 알고리즘을 사용하지만 X spec에는 Bresenham을 사용한다고 정해져 있습니다.
...
결과적으로, X implementation이 선과 폴리곤을 그릴때 느려 터졌었습니다. spec에 있는 그대로 구현해야 했거든요.

(X는 시대를 잘못 타고났다?)

며칠에 걸쳐서 잠깐 잠깐씩, 재미가 없으면 내버려뒀다가 다시 생각나면 좀 만져보고 하는 일을 반복한 끝에...

lifepod openAPI의 인증 부분을 짰습니다.  며칠에 걸쳐서 lifepod API 서버의 버그로 잠깐 헤매다가, open ID에 http://를 넣었다가 뺐다가, 해시 부분을 소문자로 써야 하는 API의 숨겨진 사실을 깨닫기도 하다가, gnutls_fingerprint() 함수의 버그성 동작에 헷갈리다가 하면서 인증 부분만 완료.

• 상단의 openid, userkey, appid, appkey는 자기에 맞게 바꾸세요.
  
• 컴파일은 gcc -o example-lifepod `pkg-config --cflags libsoup-2.2` example-lifepod.c `pkg-config --libs libsoup-2.2`
• 스프(libsoup)는 GObject를 이용해서 만든 것이라서, synchronous하게 쓰려면 상관없지만 asynchronous하게 사용하려면 glib main loop가 필요합니다.

사실 인증보다 더 어려운 건 response로 날아온 XML을 파싱하는 거지만 그건 다른 종류의 내공이니까요. evolution frontend를 만드려고 했지만, evolution이 내부 데이터로 ical을 쓰고 있기 때문에 이건 lifepod xml to/from ical 변환 프로그램 만드는 꼴이 될 듯 합니다. 또 잠시 접어뒀다가 생각나면 조금씩 해 봐야죠.

"Just works"의 UI 철학에 따라(?) 패널에 배경 이미지를 씌울 수 있는 기능이 왜 있는지 잘 이해가 되지 않았다.  마침 그놈 사용자 안내서를 읽다가 드래그로 그놈 패널의 배경을 설정할 수 있다는 걸 발견, 노틸러스에서 "바탕색 및 꼬리표" 대화 창을 띄웠다.



얼마전 예비군 훈련을 갔다와서 빨아 놓은 군복을 정리하지 않은 지금...  "위장" 색을 패널에 끌어 놓아 보기로 했다.  (예비군 군복보다는 자이툰 부대 군복이랑 비슷한 것 같지만..)

앗!  정말 "위장" 효과가 있다.  패널이 눈에 잘 안 들어온다.


이렇게 하면 오히려 시야가 애플리케이션 창에 집중되서 패널에서 아무리 CPU 로드 그래프를 그려대고 깜박이는 거에 상관없이 집중할 수 있다. 

단, 패널을 볼 때도 패널이 눈에 잘 안 들어온다...

Tomboy를 실행하다가 날짜와 시간이 한국 포맷으로 나오지 않는 것을 발견해서 예전의 퍼키옹이 한 경로를 그대로 추적을 해 봤습니다. 막상 이걸 봐도 실제로 문제점을 추적하기는 힘들더군요.  그래서 일단 버그부터 지른다음에 조금 기다려봤는데...  역시 그냥 버그 현상만 써 놓으니까 메인테이너도 고쳐주질 않을 것 같고 퍼키씨도 당장은 손 안 대는 것 같고 해서 직접 찾아봤습니다.

결국 퍼키옹이 따라갔던 경로를 하나하나 다 반복해 보고서는 문제를 파악했는데..  문제는 헤더 파일을 제너레이트하는 C# 프로그램이 소팅을 하면서 "ko-kr"을 "kok" (콘칸어) 뒤에 배치하는 바람에 C 코드에서 strcmp로 바이너리 서치를 할 때 못 찾는 문제였습니다.  String.CompareTo()를 간단히 String.CompareOrdinal()로 교체해서 해결.

그런데 여기서 끝나지 않은 게, 빌드를 잘못했는지 이제 각각의 "1월", "2월", "월요일" 따위의 이름은 한글로 나오는데 포맷이 어떤 부분은 제대로 나오고, 어떤 부분은 "12월 6 2006"과 같이 나오네요.

(업데이트) 나머지 문제는 C# culture info와 상관없이 tomboy에서 자체적으로 사용한 날짜 포맷을 번역할 때 고려하지 않은 사항.  tomboy 번역을 바로잡았으니 다음 릴리즈에는 제대로 나오겠네요.

심심풀이 구글 SoC2007 그놈 포스터 번역

http://live.gnome.org/SummerOfCode2007/Poster