Nautilus Renames Extension 3.2 RC1 supports GSettings.

先日翻訳した移行ガイドを参考に GConf から GSetting に変更してみた。概ねこのガイドに従っていけば移行はできるけど、GSettings の API を使って設定情報を保管したり取得するコードは別途追加が必要。このあたりを中心に気づいた点などをまとめてみる。あと、前バージョンでは Deprecated なウィジェット (コンテナ) を残したまま GTK+ 3 をサポートしていたのだけれど、GTK+ 3.6 系の環境で使用するとウィジェットの配置が崩れてくるのが目に付いたので、それらを新しいコンテナらで置き換えておいた
今回の移行対象となるスキーマはアプリケーションの設定情報とかオプションとか呼ばれる類のもので、いわゆる Microsoft Windows のレジストリみたいなもの。詳細はこちらのドキュメントを参照のこと。以下、前者が GConf のスキーマ XML で、後者が (GConf スキーマを変換し修正した結果でもある) GSettings のスキーマ XML の一部である:

(nautilus-renames.schemas)
<gconfschemafile>
<schemalist>
<schema>
<key>/schemas/apps/nautilus-renames/last_template</key>
<applyto>/apps/nautilus-renames/last_template</applyto>
<owner>nautilus-renames</owner>
<type>string</type>
<default></default>
<locale name="C">
<short>Last template used to rename</short>
<long>
Used to store which a template used for renaming filenames
or folder names with some special character in pattern.
</long>
</locale>
</schema>
...
(org.gnome.nautilus-renames.command-history.gschema.xml)
<?xml version="1.0" encoding="UTF-8"?>
<schemalist>
<schema path="/org/gnome/nautilus-renames/command-history/" id="org.gnome.nautilus-renames.command-history" gettext-domain="nautilus
-renames">
<key type="s" name="last-template">
<default>''</default>
<summary>Last template used to rename</summary>
<description>Used to store which a template used for renaming filenames or folder names with some special character in pattern.<
/description>
</key>
...

上の例では両者共にちょうど1個のキーとその値の定義をスキーマで記述してある。移行ガイドにもあるけど、両者の大きな違いはキーの名前が GConf では絶対パス名で、GSettings では名称になっている点。あとで両者の違いを吸収するコンバータについて説明する。
で、その移行作業としては:

  1. configure.ac に専用の m4 マクロを追加する移行ガイドにあるように GLIB_GSETTINGS を追加し pkg-config を使った検出では古い GConf 向けの条件を外して、代わりに gsettings-desktop-schemas を利用するための条件を追加する。
    @@ -66,6 +66,7 @@ AC_HEADER_STDC
    GNOME_COMMON_INIT
    GNOME_MAINTAINER_MODE_DEFINES
    GNOME_COMPILE_WARNINGS([maximum])
    +GLIB_GSETTINGS
    
    @@ -84,8 +84,8 @@ PKG_CHECK_MODULES([DEPENDENCIES], [
    gmodule-2.0
    gio-2.0
    gtk+-3.0 >= $GTK_REQUIRED
    -    gconf-2.0 >= $GCONF_REQUIRED
    libnautilus-extension >= $NAUTILUS_EXTENSION
    +    gsettings-desktop-schemas
    ])
    

    gconftool も不要なので configure スクリプトから外す:

    @@ -161,16 +161,6 @@ else
    -AC_PATH_PROG(GCONFTOOL, gconftool-2, no)
    -if test x"$GCONFTOOL" = xno; then
    -        AC_MSG_ERROR([gconftool-2 executable not found in your path - should be installed with GConf])
    -fi
    -AM_GCONF_SOURCE_2
    

    GSettings は GLib バージョン 2.26 以降から利用できるので、それをビルド条件として追加しても構わない:

    @@ -75,7 +76,6 @@ PKG_PROG_PKG_CONFIG
    GLIB_REQUIRED=2.28.0     // >= 2.26 であることを明示する
    GTK_REQUIRED=3.4.0       // Deprecated なコンテナを使わないようにするため
    NAUTILUS_EXTENSION=3.0.0
    
  2. Makefile.am に専用のルールを追加するこのアプリでは GConf のスキーマを $(topdir)/data に格納しているので、このディレクトリの Makefile.am を修正する。まず GConf 向けのルールを GSettings のルールで置き換える。ここにあるとおり GSettings のスキーマ XML ファイルの名前は org.gnome.nautilus-renames.command-history.gschema.xml で、後で説明するけど <summary> (サマリ) と <description> (説明) は l10n 向けに翻訳カタログにエキスポートするため、実際には *.gschema.xml.in というファイルを作成して、その後の @INTLTOOL_XML_NOMERGE_RULE@ というルールを介して *.gschema.xml に変換している:
    @@ -14,24 +14,27 @@ icon_DATA =                                 \
    ## Man page
    man_MANS = nautilus-renames.1
    -## Schemas and about.ini
    -schemadir = @GCONF_SCHEMA_FILE_DIR@
    -schema_in_files = nautilus-renames.schemas.in
    -schema_DATA = $(schema_in_files:.schemas.in=.schemas)
    +## GSettings schemas
    +gsettings_schema_in_files =                                            \
    +       org.gnome.nautilus-renames.command-history.gschema.xml.in       \
    +       $(NULL)
    +gsettings_SCHEMAS = $(gsettings_schema_in_files:.xml.in=.xml)
    -@INTLTOOL_SCHEMAS_RULE@
    +@INTLTOOL_XML_NOMERGE_RULE@
    +@GSETTINGS_RULES@
    

    ちなみに dconf-editor といった GUI の類でスキーマのサマリや説明を参照しても日本語になっていない理由は、この @INTLTOOL_XML_NOMERGE_RULE@ ルールがあるため。このルールを外せば日本語のままスキーマに埋め込まれるのだけれどバイナリに変換する際にエラーが出る。単純にせっかく翻訳した日本語の文章が表示されないのはそれが原因。

  3. GConf/GSettings のスキーマ変換一覧のファイルを作成し、
    Makefile.am に専用のルールを追加する
    つづいて、移行ガイドのここにあるように、GConf/GSettings のスキーマを相互に自動変換してデータを保存できるようにするために、GSettings のスキーマにあるキーと GConf のパス名の対応づけを記述したファイル (コンバータ) を nautilus-renames.convert なる名前で作成しておき、これを /usr/share/GConf/gsettings というディレクトリにインストールするルールを書いておく:

    +## About informations
    +convertdir = $(datadir)/GConf/gsettings
    +convert_DATA = nautilus-renames.convert
    

    次がコンバータの中身。GSettings のスキーマ毎にキーを左辺に、それに対応する GConf のキー (/schemas を除いた絶対パス) を右辺に記述する:

    [org.gnome.nautilus-renames.command-history]
    last-template = /apps/nautilus-renames/last_template
    last-start-at = /apps/nautilus-renames/last_start_at
    last-sort-by = /apps/nautilus-renames/last_sort_by
    last-reverseorder = /apps/nautilus-renames/last_reverseorder
    last-change-case = /apps/nautilus-renames/last_change_case
    last-leave-original = /apps/nautilus-renames/last_leave_original
    

    最後にソース・アーカイブを配布するためのお決まりのターゲットでも、GConf スキーマファイルを削除して GSettings のスキーマとコンバータを追加しておく:

    EXTRA_DIST =                           \
    -       nautilus-renames.schemas        \
    -       nautilus-renames.schemas.in     \
    +       $(gsettings_schema_in_files)    \
    +       nautilus-renames.convert        \
    $(icon_DATA)                    \
    $(man_MANS)                     \
    $(aboutdialog_DATA)             \
    @@ -42,9 +45,18 @@ DISTCLEANFILES =     \
    $(NULL)
    CLEANFILES =                           \
    -       $(schema_DATA)                  \
    +       $(gsettings_SCHEMAS)            \
    $(NULL)
    
  4. GConf スキーマの XML ファイルを
    GSettings スキーマの XML ファイルに変換する
    次は、移行ガイドのここにあるように、GConf のパッケージに付属している gsettings-schema-convert なるツールを使って実際に GConf から GSettings のスキーマ XML に変換する。GSettings の場合、スキーマ名「イコール」ファイル名が慣例らしく名前空間みたいにドットで区切った名称にし、拡張子はこれも慣例に従い .gschema.xml にする。ということで、GSettings のスキーマ XML のファイル名は org.gnome.nautilus-renames.command-history.gschema.xml になる。とはいえ、GConf / GSettings 共に実際の XML ファイルは l10n 対応ということで intltool のマクロを介して展開されるようにしておくため *.in という拡張子になっており、移行ガイドに従って実行するコマンドラインは次のようになる:

    $ gsettings-schema-convert \
    --gconf --xml   \
    --schema-id "org.gnome.nautilus-renames.command-history"           \
    --output org.gnome.nautilus-renames.command-history.gschema.xml.in \
    nautilus-renames.schemas.in
    
  5. 変換した GSettings スキーマの XML ファイルを修正するgsettings-schema-convert ツールで変換した結果を修正する。ここではコマンドラインからスキーマ id を “org.gnome.*” に変更しているが、変換された path の内容は GConf の絶対パスのままなので手動で修正する。例えば
    <schema id="org.gnome.nautilus-renames.command-history"
    path="/schemas/apps/nautilus-renames/last_template" ...
    

    を次のように修正する (これを全キーに対して繰り返す):

    <schema id="org.gnome.nautilus-renames.command-history"
    path="/org/gnome/nautilus-renames/command-history/" ...
    

    その他に、各キーのスキーマにある <summary> を <_summary>、<description> を <_description> にそれぞれ変更し、スキーマ id の中に gettext のドメインを追加して intltool の @INTLTOOL_XML_NOMERGE_RULE@ のルールでエキスポートされるようにしておく:

    <schema id="org.gnome.nautilus-renames.command-history"
    path="/org/gnome/nautilus-renames/command-history/"
    gettext-domain="nautilus-renames">
    
  6. POTFILES.in に GSettings スキーマファイルを追加する上で追加した intltool のルールと intltool-update を使って l10n のメッセージ・カタログ・ファイルにスキーマの日本語訳をエキスポートできるように、GSettings のスキーマ XML ファイルの名前を po/POTFILES.in に追加しておく:
    [encoding: UTF-8]
    # List of source files containing translatable strings.
    # Please keep this file sorted alphabetically.
    ...
    data/org.gnome.nautilus-renames.command-history.gschema.xml.in
    

    あとは po ディレクトリで次のコマンドを実行すると、GSettings のスキーマ XML ファイルにある &lt_summary> と <_description> でそれぞれ囲った部分が翻訳メッセージのエントリとして追加されるようになる:

    $ intltool-update ja
    
  7. GConf の API を GSettings の API に置き換えてコンパイルしてみる最後に、プログラムから GConf の API を使ってアプリの設定情報を取得したり、別の値で上書きするなどしているコードをそれぞれ修正しておく。このアプリではアプリの設定に応じた GConf のラッパーを提供しているので、これを GSetting の API置き換えた。同様に、直接アプリの設定を取得するコードも GSetting の API でそれぞれ置き換えた

    それが完了したら、configure スクリプトが正しく GSetting を検出し、GSettings のスキーマ XML ファイルが生成され、GSettings の API を使ったコードがコンパイルされるか autogen.sh を実行して確認する。

といった流れになった。さらに、このアプリでは run-in-place をサポートするようにしており、せっかくなのでスキーマをシステム規模でインストールすることなく、ビルド直後にそのまま GSettings を利用できるようにちょっと fake な処理を追加している。
本来ならばスキーマをシステム規模の /usr/share/glib-2.0/schemas というディレクトリにインストールしてコンパイルする必要があるが、それは $XDG_DATA_DIRS という環境変数に基底ディレクトリが定義されているから:

$ echo $XDG_DATA_DIRS
/usr/share/gnome:/usr/local/share/:/usr/share/

すなわち、上記の基底ディレクトリ配下の glib-2.0/schemas に GSettings のスキーマ XML とそのバイトコンパイルが存在ししていないとアプリが起動しない:

$ nautilus-renames *.*
...
(nautilus-renames:14782): GLib-GIO-ERROR **: No GSettings schemas are installed on the system

ということで、システム規模にインストールせずにローカルのディレクトリで上記の条件を満足させるようにした上で、このアプリの起動時に次のように環境変数を変更してローカルのディレクトリを優先するようなコードを追加した:

#ifdef RUN_IN_PLACE
{
gchar             *val_string;
const gchar       *old_env;
old_env = g_getenv ("XDG_DATA_DIRS");
if (old_env) {
val_string = g_strdup_printf ("%s:$(XDG_DATA_DIRS)", DATADIR);
g_setenv ("XDG_DATA_DIRS", val_string, TRUE);
} else {
val_string = g_strdup_printf ("%s", DATADIR);
g_setenv ("XDG_DATA_DIRS", val_string, TRUE);
}
#ifdef DEBUG
mkf_debug_message (DEBUG_PRINT, "$XDG_DATA_DIRS = %s", val_string);
#endif /* Def: DEBUG */
g_free (val_string);
}
#endif /* Def: RUN_IN_PLACE */

そしてビルドした後に次のコマンドで GSettings のスキーマをローカルでバイトコンパイルして利用できる環境にする:

$ make compile-local-schemas
cd data && make compile-local-schemas
make[1]: ディレクトリ `nautilus-renames/data' に入ります
top_builddir=`cd .. && pwd`
Compiling schemas in local
mkdir -p ../data/glib-2.0/schemas/
install -c -m644 org.gnome.nautilus-renames.command-history.gschema.xml ../data/glib-2.0/schemas/
GLIB_COMPILE_SCHEMAS=/usr/bin/glib-compile-schemas && /usr/lib/x86_64-linux-gnu/glib-2.0/glib-compile-schemas ../data/glib-2.0/schemas
make[1]: ディレクトリ `nautilus-renames/data' から出ます

次が上のターゲットのルール:

+if RUN_IN_PLACE
+compile-local-schemas: org.gnome.nautilus-renames.command-history.gschema.xml
+       top_builddir=`cd $(top_builddir) && pwd`
+       @echo Compiling schemas in local
+       mkdir -p $(top_builddir)/data/glib-2.0/schemas/
+       install -c -m644 org.gnome.nautilus-renames.command-history.gschema.xml $(top_builddir)/data/glib-2.0/schemas/
+       GLIB_COMPILE_SCHEMAS=$(shell which glib-compile-schemas) && $(GLIB_COMPILE_SCHEMAS) $(top_builddir)/data/glib-2.0/schemas
+endif

これでアプリをシステム規模でインストールしなくても即行で起動できる。
あとGTK+ バージョン3を使った GUI の方も、Deprecated になったテーブルやボックスといったコンテナを全て Glade を使って書き直した。ウィジェットをコンテナを介して階層的に管理することは理論的に良いとは思うけど、実際にレイアウトを視覚的に決めるのが難しくなった。あれこれパラメータを変更しながらじゃないと一意にきまらないというか、やり直しが多くなるというか。一箇所操作するだけでレイアウトが決まれば良いのだけれど、Glade は個々のウィジェットをそれぞれ操作しないとうまくいかない。
ということで、以下がスクリーンショット:
nautilus-renames-2013010501.png
今バージョンからコンテキスト・メニューの項目でショートカットキーを利用できるようにした:
nautilus-renames-2013010401.png
See Also nautilus-renames-3.1.92.tar.xz: Release Candidate2
See Also 開発リポジトリ
See Also ホームページ
そういえば前のバージョンも未だ stable を出していなかったような気もするな…:O

Removed the codeset of PANGO_RENDER_TYPE_X.

Pango のバージョン 1.31.x (公式版は 1.32.x) から X11 のフォントバックエンドのコードが完全に削除されてしまった。まぁ最低限でも freetype と xft のレンダリングを使っている今時のデスクトップ環境では不要ということでかなり前から予告はあったのだけれど:

$ git log 194b6ee552318ec6c494f34ed9f0979d0460fe4f -p
commit 194b6ee552318ec6c494f34ed9f0979d0460fe4f
Author: Behdad Esfahbod 
Date:   Thu Aug 16 21:48:50 2012 -0400
Remove PangoX
Been overdue...
diff --git a/Makefile.am b/Makefile.am
index b0b56ec..1ac018a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -6,13 +6,11 @@ EXTRA_DIST =                  \
autogen.sh              \
pango.pc.in             \
pangocairo.pc.in        \
-       pangox.pc.in            \
pangoxft.pc.in          \
pangoft2.pc.in          \
pangowin32.pc.in        \
pango-uninstalled.pc.in         \
pangocairo-uninstalled.pc.in    \
-       pangox-uninstalled.pc.in        \
pangoxft-uninstalled.pc.in      \
pangoft2-uninstalled.pc.in      \
pangowin32-uninstalled.pc.in    \
@@ -84,10 +82,6 @@ if HAVE_CAIRO
pkgconfig_DATA += pangocairo.pc
endif
-if HAVE_X
-pkgconfig_DATA += pangox.pc
-endif
-
if HAVE_XFT
pkgconfig_DATA += pangoxft.pc
endif
diff --git a/configure.in b/configure.in
index fc5a0f7..90ed3c4 100644
--- a/configure.in
+++ b/configure.in
@@ -225,21 +225,6 @@ AC_ARG_ENABLE(rebuilds,
AM_CONDITIONAL(CROSS_COMPILING, [test $cross_compiling = yes])
-have_x=false
-if test "x$pango_os_win32" != xyes; then
-  AC_PATH_XTRA
-
-  if test x$no_x = xyes ; then
-    AC_MSG_WARN([X development libraries not found])
-    have_x=false
-  else
-    X_LIBS="$X_LIBS -lX11"
-    have_x=true
-    AC_DEFINE(HAVE_X, 1, [Have X libraries])
-  fi
-fi
-AM_CONDITIONAL(HAVE_X, $have_x) 
(...SNIP...)

その一方で新しく導入されたのが OpenType のフリーなレンダリングの HarfBuzz。試しに今の GNOME 3.6 な環境に両ライブラリをビルド・インストールしてみたが特にレンダリングの方は問題はなかった。今の環境のフォント設定ははベクタだけでビットマップなんて使っていないので当然といえば当然だけれども。
但し弊害が無いわけではなくて、上記のコードが削除されたことで libpangox-1.0.so.0 というモジュール用ライブラリが無くなってしまうため、このライブラリと動的にリンクしているアプリは当然起動できない等の問題が発生する。
例えば、自分の環境だと GTK+ バージョン2系のアプリで ATOKX が使えなくなった。Justsystem が日本語入力システム ATOK X3 for Linux としてリリースしているバイナリはかなり古いバージョンのフレームワークでビルドされており、まさにこのモジュール用ライブラリを動的にリンクしていた:

$ ls -al /usr/lib/gtk-2.0/2.10.0/immodules/im-iiim.so
-rw-r--r-- 1 root root 103278 Nov 17 13:14 /usr/lib/gtk-2.0/2.10.0/immodules/im-iiim.so
$ ldd /usr/lib/gtk-2.0/2.10.0/immodules/im-iiim.so
linux-vdso.so.1 =>  (0x00007fff99fff000)
(...SNIP...)
libpangoxft-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoxft-1.0.so.0 (0x00007f44a5a87000)
libpangox-1.0.so.0 => not found
(...SNIP...)
$
$ gtk-demo
(gtk-demo:4567): Gtk-WARNING **: libpangox-1.0.so.0: cannot open shared object file: No such file or directory
(gtk-demo:4567): Gtk-WARNING **: Loading IM context type 'iiim' failed

その影響で google-chrome とか firefox3 とか OpenOffice で日本語が入力できなくなってしまった ;(
解決方法の一つはリビルドすること。Pango のXのバックエンドが廃止になると予告していたのはかなり前のバージョンからなので、最近の GTK+ バージョン2系のフレームワークであれば libpangox-1.0.so.0 は動的にリンクされない (正確には ${LIBDIR}/pkgconfig/pango*.pc を確認のこと)。
で、ATOKX ならば製品付属のソースから iiimcf 相当のモジュールをリビルドしてインストールしておけば回避できる。

$ sudo install -c -m644 .libs/im-iiim.so /usr/lib/gtk-2.0/2.10.0/immodules/im-iiim.so

ビルド方法は昔 GTK+ バージョン3系向けにブログした時の Wiki ページを参照のこと。

GNOME 3.6 rc.

来週の公式リリースに向け、3.6 beta に続いて 3.6 rc の tarballs が今日からぼちぼちと upload されている模様。beta 時に作成した My debs パッケージらをさくさくと更新しビルド・インストールしてみる。今の環境がいくぶん不安定な beta なのでビルドの順番にかかわらずどんどんアップグレードしていく予定。
beta 環境とはいえ普通に使えているのだけれど、新機能、特に gnome-shell のスクリーンシャッター (画面のロックに相当) のバグのために、画面のロックを解除できないのは致命的だった (その際は、バックグラウンドから gnome-shell に SIGHUP を発行して対処していた)。
そこで beta からのバグ修正や新機能については都度まとめることにする。
まずは vte-0.34.0 の NEWS をみてみると、端末上に QR コードなんかを描画する際のバグが修正されたとかある:

0.34.0
======
* Support escape sequences to set the current directory (#675987)
* Fixed drawing of Box Drawing and Block Elements characters (#682692)
* Introspection fixes (#679805, #681714)
* Build fixes

早速インストールしてみると、tree コマンドでツリーを描画している棒線部分が強調されて表示されていた:
vte-0.34.0-BlockElementChars.png
大分前のバージョンでもこんな描画バグが話題になっていたような気もするが。あと、tmux で画面を分割する線なんかも同様に太くなって分かりやすい。
前回こきおろした Nautilus だけれども特に改善の傾向はみられないようなので、以前、変更したサイドバーのカテゴリを入れ替えるパッチをこのバージョン向けに更新してみた。今回はサイドバーの一番下にネットワークの参照があるので、それをブックマーク一覧の上に移動しただけ:
NautilusChangeSidebarOrder-20120918.png
あと GNOME シェルの拡張機能で、前のバージョンの 3.4 からお気に入りで使っているマウス等のホィールでワークスペースをくるくる切り替えるものがあったのだけれど、新バージョンの 3.6 (実際はバージョン 3.5.91) 向けに公開されているものワークスペースの左端にポインタを移動してホィールを回すタイプであり、お気に入りで使っていた右端に移動させる (i.e. ポインタを動かすことなくほぼ定位置の) タイプではなかったので、ちょっと修正して使っている:

--- extension.js.Left	2012-09-18 23:59:56.086201915 +0900
+++ extension.js	2012-09-16 22:16:57.583671301 +0900
@@ -23,12 +23,12 @@
Scroller.prototype = {
_init: function() {
-		let y = Main.panel.actor.get_height() + Main.panel._leftCorner.actor.get_height()
+		let y = Main.panel.actor.get_height() + Main.panel._rightCorner.actor.get_height()
this.actor = new Clutter.Rectangle({
-			name: 'left-scroller',
+			name: 'right-scroller',
opacity: 0,
reactive: true,
-			'x': 0, 'width' : WIDTH_px,
+			'x': Main.layoutManager.primaryMonitor.width - WIDTH_px , 'width' : WIDTH_px,
'y': y, 'height': Main.layoutManager.primaryMonitor.height - y
})

左端でホィールを回す仕様は、右端でホィールを回すとワークスペースではなく、ブラウザなどのアプリケーションのスクロールバーが反応するからといったのが理由だと思うけど、右端へ移動したポインタは画面の外にでるのでそうそうは衝突することはないかな。
(とりあえず、こんなところまで)

GNOME 3.6 beta 2.

今月は 9/26 にリリース予定の GNOME 3.6 だけれども、そろそろパッケージを作成しつつ、ついこないだアップグレードが完了したばかりの安定版を置き換えていこうということで、いつもと同様に Ubuntu の次期バージョンから K35 やら toolchain やらを含むミドルウェアに順次アップグレードし (起動や一般的な作業に影響のない範囲で) 新しい環境を構築してから、3.5.91 のパッケージをそれぞれビルド・インストールしてみた。
まだまだ完了まではほど遠いものの、なんとか先週末までで GNOME シェルを起動するところまで終わったので、すこしばかり気づいたり気に入らない点 :(などをまとめてみる。公式リリースまで 2weeks ほどしかないので、今の状態からどれだけ改善(?)されるか楽しみではある。
ちなみに今回から GNOME シェルは (前のバージョン 3.4 ではモード化されていた経緯で) GDM のバージョン 3.6 との連携が必須となっており、シェルをインストールする前に GDM の 3.6 相当をインストールしておかないとXを含め全く何も起動できなくなってしまう :$。この辺りまで到達すると流石に古い GNOME シェルはアンインストールする必要があるので、フォールバックモードで compiz を使ったデスクトップ環境上でパッケージを作成・ビルド・インストールした。
まずはそのログイン画面から。GDM が起動するとこんな感じ:
ScreenShot-GDM3.6-01.png
この画面が出るまでにちょっと cool なエフェクトがある。反転しているカーソルを動かしてログインユーザを確定すると:
ScreenShot-GDM3.6-02.png
セッションを選択するなどして、パスワードを入力してログインするのはいつもと同じ。ちなみに、このログイン画面の一部は GNOME シェルなのでカレンダを表示することができ、さらに一定の時間ログインされないと時刻つきのスプラッシュスクリーンが表示される。このスクリーンは所謂 (いわゆる)「シャッター式」なので、ポインタをドラッグして上に押しやるとログイン画面が出てくるという演出つき:
ScreenShot-GDM3.6-03.png
ScreenShot-GDM3.6-04.png
ScreenShot-GDM3.6-05.png
で、ログインすると 3.4 で使っていたアプリを含む、新しいデスクトップが表示される。当然ながら古い 3.4 で使っていたテーマや拡張機能は完全には利用できない。そのあたりはアップグレードする際の留意点でもある。今まで使い慣れたシェルの拡張機能が直ぐに使えるようになるとは限らないので、アップグレードするタイミングを見極めるのは面倒かも。しかしながら既に 3.6 をサポートしたものがあり、ブラウザから e.g.o に接続すれば、このバージョンで利用できるプラグインだけフィルタリングされて表示されるようになっていて便利ではある。
ということでテーマはデフォルトの Adwita:
Screenshot-Desktop-01.png
今まで同様にカレンダも付いているし:
Screenshot-Desktop-02.png
以前は右端にあったエントリが中央に移動したものの検索機能も使える。日本語の入力しづらさは以前よりちょっとだけ改善されている (連続して変換しながら入力できるので):
Screenshot-Desktop-03.png
Screenshot-Desktop-04.png
プリミティブな部分に移してみると、GTK+ は CSS を使ったアクションが多彩になった (今バージョンはそれくらいか?):

ScreenShot-GTK3-CSS-Accordion-01.png ScreenShot-GTK3-CSS-Accordion-02.png

「システムの設定」(gnome-control-center) はあまり大きな変化は無いけれど、それぞれのアイコンが大きめになってユーザビリティが向上している:
Screenshot-GnomeControlCenter3.6-01.png
Screenshot-GnomeControlCenter3.6-02.png
Ubuntu 12.10 から、GConf のブリッジを使用しなくなり (といってもこれ自体がパッチだったのだけれど) GSettings に一本化されたため、compiz などで使用していたワークスペースを上下に移動する際のキーバインディングなど UI からは指定できなくなっている。個人的には非常に不便きまわりない :|
で、今バージョンでホント使えなくなったアプリが「ファイルの一覧」(Nautilus)。これをインストールして最初に起動した時の落胆は表現しがたい :o:
Screenshot-Nautilus3.6.png
タイムスタンプの表記がまともに国際化されていないなどまだまだ完成度が低いものの、サイドペインのツリー表示やコンパクトビュー、ペインの分割といった機能がばっさり無くなってしまって自分としては全く利用価値がないアプリになってしまった (コンパクトビューの機能をドロップしろと報告した人は、コンパクトビューはリストビューを縮小表示すれば同じだとかぬかしていたな。えっ!? これがあっさり採用されるのだから、これまた恐ろしいものだ)。本気で前のバージョンに戻そうか考えている。
次は「ディスク」(gnome-disk-utility)。これは作者が G+ なんかでも自慢していたとおり良くできているし使いやすい:
Screenshot-GnomeDisks3.6.png
次は「インターネット・メッセージ送信ツール」(empathy)。GtkApplication クラスに対応し UI が変わったくらいかな。UOA (Ubuntu Online Accounts) とか使わなそうな機能が付いていたような気もするが:
Screenshot-Empathy3.6.png
GtkApplicationクラスは全く利用価値が分からないな。ショートカットキーも使えないし、ウィンドウにフォーカスを与える際は Sloppy モード (マウスがウィンドウの上に移動したら自動的にフォーカスを与える) を使っているので使い勝手が最悪。
最後に「画面のロック」。これは gnome-screensaver ではなく GNOME シェルの機能 (スクリーン・シールド!?)。GDM のスプラッシュスクリーン同様のエフェクトを持つ。ロックを解除する時は [Esc] キーを押下する。このバージョンでは何回かに一度はクラッシュしてしまうが…:
Screenshot-ScreenLock3.6-01.png
Screenshot-ScreenLock3.6-02.png
といった感じ。その他のアプリは未だインストールしていないし、(この時期にしては) バグも多いので公式リリースがどの程度の完成度になるかは不明だけれど (びっくりするほど) 大きな違いは無いだろうと予想する。
ちなみに自分の環境では、ibus のフレームワーク抜きでビルドしている。
GNOME 3.x になってから、新しい機能ばかり重点がおかれて、今まで慣れ親しんだ機能をばっさり切り落とすようなポリシーが目立ってならない。

GtkWindow on GDB-7.5.

今月の中頃にリリースされた GDB 7.5 だけれど、早速 Quantal Quetza (12.10) 版をインストールしてみた。で、その NEWS ファイルの一部には:

*** Changes in GDB 7.5
* GDB now supports x32 ABI. Visit <http://sites.google.com/site/x32abi/> for more x32 ABI info. * GDB now supports access to MIPS DSP registers on Linux targets. * GDB now supports debugging microMIPS binaries. * The "info os" command on GNU/Linux can now display information on several new classes of objects managed by the operating system: (省略) * GDB now has support for SDT (Static Defined Tracing) probes. (省略) * GDB now supports reversible debugging on ARM, (省略) * Python scripting (省略)

Python scripting” なんて粋な機能が付いているのを発見 (あとで気づいたのだけれど Python サポートは GDB 7.0 からなのね)。
で、実際に起動して確認してみた。まずは help を見てみる:

$ gdb
GNU gdb (GDB) 7.5-ubuntu
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb)
(gdb) help python
Evaluate a Python command.
The command can be given as an argument, for instance:
python print 23
If no argument is given, the following lines are read and used as the Python commands. Type a line containing "end" to indicate the end of the command. (gdb)

これによると、python というコマンドに続けてスクリプトを記述するか、あるいは python のあとでリターンすると複数行のスクリプトを記述でき、end で締めくくると解釈されるようだ。
何回かのアップグレードでかなり機能が改善されているようなので、GTK+ のウィンドウでも create してみるかと:

(gdb) python
>from gi.repository import Gtk
>
>win = Gtk.Window()
>win.connect("delete-event", Gtk.main_quit)
>win.show_all()
>Gtk.main()
>end

全くもって問題なく GtkWindow を一つリアライズできた :D
すごい。何の役に立つか分からんけど。