試験運用中なLinux備忘録

2011/06/13

GObject introspectionとPyGIの概要について

GObject introspection

C言語で書かれたライブラリが提供する関数やGObjectライブラリのオブジェクトシステムに基づいたクラスなどを高レベルのオブジェクト指向言語から容易に利用するための新しい仕組みがここ数年で作られた。これが「GObject introspection」と呼ばれるもので

  • CPU負荷のかかる処理や低レベルな処理に向いているC言語の世界
  • 複雑なプログラムを記述しやすい高レベルのオブジェクト指向言語の世界

の間の有用な架け橋として機能することを1つの目的としている。

もう1つの目的として、言語バインディングとの親和性の高さがある。既存の言語バインディングはC言語での呼び出し方をもとに手動で同等の(バインディング側の)呼び出し方式を作成してメンテナンスしてきているが、この「もとのライブラリとはのところで手動で言語バインディングに対する作業を行う」という部分が原因となって問題を引き起こすケースが過去に色々とあったようだ。GObject introspectionを用いると、各言語とGObject introspectionの間さえうまくつなぐことができれば、GObject introspectionに対応したライブラリを全て利用できることになり、「手動の作業による静的な言語バインディング」が必要なくなるので、上記問題に対処するためにも役に立つ仕組みとなっている。

ツール群

GObject introspectionに関連したファイルを操作するためのツール群(Debian/Ubuntuでのパッケージ名は「gobject-introspection」)が存在する。具体的なものについては後述。

.girファイルと.typelibファイル

C言語ライブラリの世界と高レベルオブジェクト指向言語の世界をつなぐために、専用のファイルをシステムに配置する。ここには、高レベルオブジェクト指向言語からGObject introspectionを用いる際にどの共有オブジェクトを読み込んでどのようにC言語ライブラリを扱うかが記述されており、C言語のライブラリ側が個別に用意する。

このファイルはg-ir-scannerというツールによりC言語のソース/ヘッダファイルから自動生成され、.girという拡張子のXML文書として保存される。配置場所は/usr/share/gir-[バージョン]/以下。ビルドシステムに統合することもできるようだ

このXMLファイルを機械から処理しやすくしたものが.typelibファイルで、GObject introspectionのバインディングからは.girファイルではなく、こちらが用いられる。配置場所は/usr/lib(32や64)/girepository-[バージョン]/以下。gettextのメッセージ国際化で用いられるカタログファイルに.po(テキスト)形式と.mo(バイナリ)形式があるが、.gir(テキスト)形式と.typelib(バイナリ)形式の関係はこの2つの関係に近い。

これらの形式の間の変換にはg-ir-compiler(.girファイルから.typelibファイル)とg-ir-generate(.typelibファイルから.girファイル)が用いられる。

注意が必要なのは、後述のPyGIのような言語バインディングからあるライブラリを用いたい場合にそのライブラリ自身の他に.typelibファイルが必要な点。このファイルはDebian/Ubuntuでは「gir1.2-gtk-3.0」のような形式の名前のパッケージにてライブラリ本体とは別に提供されるので、作成したソフトウェアの依存パッケージには注意が必要となる。

PyGI

PyGIはPyGObject(GObject,GLib,GIOのライブラリに対するPythonの言語バインディング)の一部で、Pythonの世界とGObject introspection対応ライブラリとの間の架け橋となる。これにより、GTK+(バージョン3系含む)やGStreamerはもちろん、GUdevやlibnotifyなど、多数のライブラリをPythonから利用可能となる。もちろん、PyGTKなどと同様、GObjectベースのライブラリのクラスを継承して用いることも可能。

一方で、静的な言語バインディングであるPyGTKはバージョン2.24系を最後に今後は更新されなくなるようだ。

PyGIの詳しい使い方はここでは扱わない(今後扱うとしてもおそらくはメールマガジン上となる予定)。

問題点

2011年6月時点の最新版であるバージョン2.28系の時点では機能が未実装な部分が色々とあり、ライブラリによっては特定の関数などが全く動作しないということもある。

例えば、PyGObjectのバージョン2.28.4の時点ではGdkPixbuf.Pixbuf.new_from_xpm_data()でメモリ上のXPM画像データからPixbufオブジェクトを作成しようとしてもPyGTKと同様には動かなかった(文字列で構成されたリストを受け付けない)。この件については個人的にバグ報告済みだが、いつ頃に動作するようになるかは分からない(「おそらくは、文字列のリストを処理できるように改善する必要があるだろう」という趣旨のコメントは開発者の一人から頂いている)。

(2012/7/30)この件については、gdk-pixbufのライブラリ側で関数の引数を正しく処理するための修正が開発版に入ったことで、自動生成される.girファイルとこれを変換した.typelibファイル(PyGIなどで用いられる形式)が正常動作可能なものになるようになった。gdk-pixbufの次期リリース(具体的なバージョンは不明)ではこの修正の入った.typelibファイルが利用でき、PyGIでのGdkPixbuf.Pixbuf.new_from_xpm_data()も正常に動作するようになる。PyGObject側には問題の原因はないため、修正は行われない(今回バグ報告したものはgdk-pixbufライブラリにおけるバグに対する重複として処理された)。以下、以前の内容の続きとなる。

また、利用可能な関数やクラスなどを調べにくいというのも問題で、専用のリファレンスが用意されていたPyGTKとは異なり、PyGIでGTK+を用いる際には.girファイルとC言語のGTK+のリファレンスを組み合わせるなどの工夫が必要。ただ、.girファイルには関数やその引数などの説明が書かれており、しかも自動生成されたものであることを考えると、今後のツールの整備状況によってはリファレンスの参照がしやすくなっていく望みはある。

はてなユーザーのみコメントできます。はてなへログインもしくは新規登録をおこなってください。

(C) 2007-2015 kakurasan
本ウェブログの表示につきましては、横幅1,000ピクセル以上を推奨します。