Changwoo's Hacks

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에서 옮겨올 수 있을까? 많은 사람들이 어려움을 호소하는 걸 보면, 얼핏 보면 깔끔하고 좋아 보이지만 실제 적용하기는 쉽지 않은 모양이다.

hangul-hackers 리스트와 수동 CC

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

요즘 Pango 1.15.x 개발버전이 한창 진행되고 있고 해서, 한글 렌더링 모듈을 좀 손대려고 합니다..  발전적인 의견 있으면 주세요.

여담이지만 Pango의 한글 렌더링 모듈의 장기적인 발전 방향은, 아이러니하게도 글꼴이 다 알아서 하고 전용 모듈이 사라지는 것입니다.  현재까지는 (사실상 특수한 문서를 작성하지 않는한 사용하지 않는) 첫가끗이나 방점 등 렌더링 모듈이 일부러 신경을 써야 하는 기능들을 지원하는 글꼴은 소수입니다.  아마도 그런 글꼴이 널리 쓰이게 될때까지는 한글 모듈은 과도기적으로 그 글꼴을 구분하고 기능 조절을 하는 역할을 해야 할 것입니다.

어쨌든, 현재로선 거기까진 무리이고, 몇가지 최적화정도만 해야 겠네요:

1. 한글음절을 일부러 초/중/종으로 나눴다가 다시 합치는 동작 제거 - 일반화하기 위해 이렇게 했었지만, 일단 한글음절일 경우에 CPU 낭비인 데다가, 첫가끗으로 구성되어 있는 경우에도 나눠져 있는 걸 다시 합치면서 글꼴이 가진 능력을 활용하지 못하는 경우가 있습니다.

2. 동적 버퍼 제거 - L+V+T*M 이렇게 이론상 길이가 n인 1개 음절이 될 수 있기 때문에 realloc을 하는 버퍼를 두었는데 만들 때부터 신경쓰이는 부분이었습니다.  가능하면 버퍼없이 utf8 string에서 ucs4로 변환하지 않고 처리하도록 해 보지요.  :D

3. 그리고 안에 감춰져 있지만, pango_string_set_size()로 야금야금 크기를 늘려나가는 것도 내부적으로는 끊임없는 realloc()을 수행하게 해서 속도 저하 요인이 되는데요.  결과 글리프의 개수를 쉽게 알아낼 수 있을 것도 같은데, 이 부분은 좀 생각해 봐야 겠구요...

자, 여기까지 읽어보시고 "아! 내 그놈 데스크탑의 속도가 빨라지겠구나"라고 생각하신다면 그건 아니구요.  텍스트 렌더링의 대부분의 로드는 래스터라이징 자체와 래스터된 결과 데이터를 옮기는 데 있습니다. Pango 한글 모듈이 하는 일이라곤 유니코드 스트링을 보고 글꼴에서 어떤 글리프를 사용할까를 선택하는 정도이기 때문에 전체 텍스트 렌더링은 큰 향상을 기대하기 어려울 겁니다.  그냥 개발자의 결벽증인듯?

4. 2/3은 사실 그렇게 최적화 결벽증이고..  일단 1정도만 하고 슬슬 글꼴을 구분하는 능력을 부여할 수 있습니다.  렌더링 모듈에서 어떤 기능이 있냐 없냐를 테스트하는 건 확실하지 않지만 안 될 것 같고..  글꼴 이름으로 구분해서 앞에서 말씀드린 과도기적 역할을 할 수는 있죠. 

방점은 알아서 해 주는 글꼴을 본 적이 없고..  일단 첫가끗이 되냐 안되냐로 구분해서 음절을 자체적으로 합치려고 시도하느냐 아니냐를 결정할 수 있겠죠.  (그런데 한글음절로 표현할 수 있는데 일부러 첫가끗코드로 쓰는 그런 경우가 제가 테스트할 때 빼고 있는지 모르겠습니다.  :-)