Somehow up to GNOME 3.10.

3.8 の紹介ブログを書き終えないうちに 3.10 のビルドを始めてしまい中途半端になってしまったけど、ここは区切りをつけて次のバージョンについてブログしてみる :P
いつものとおり最新版の ubuntu (Kernel 3.11 / libc6 2.17 / gcc 4.8.1) をベースにビルドを開始したのは、3.10 が 2nd リリースされ始めた10月の初めくらい、マイペースで終わったのが11月の中くらい。しかしながら、今回はリリース物を全てインストールしても問題がいくつかあって、それが解決したのが先週の12月初め、といった具合。時間はともかくとして、結果として ubuntu Trap にハマってしまったのと、やはり今回の GNOME リリースも完成度がいまイチだなぁというが総評といったところ。個人的に仕事などで他のデスクトップ (Microsoft Windows 7 とか Apple MacOS X Mavericks) に触れる機会があって、そちらと比較しても User ExperiencesFeatures の面で物足りなさがあり、なんと言うか新鮮さがない感じ。
特に Mavericks の Safari の描画の速さには驚いた。その一方で、同じ (かな?) Webkit を使っている Epiphany の遅さと重さは半端ないんだけど ;(
いくつか遭遇した現象
パッチが足りないとか、依存関係やビルド方法が悪いとか、使っているシステムやディストリによっては発生しないかもしれないけど、とりあえず。一応公式リリース後に発生した現象:

  1. Shutdown/Reboot できない
  2. GNOME シェルでロック画面のロックを解除できない
  3. gnome-maps が起動しない
  4. gnome-documents に何も表示されない
  5. 巨大化する GtkDialog
  6. GNOME コントロール・センターのオンライン・アカウントが SIGSEGV する
  7. GNOME 3.8 の環境に gnome-settings-daemon 3.10.x をインストールしてから再ログインするとカーソルが消えてしまう

最初の gnome-session 経由で電源 OFF したり再起動できないのは非常に苦痛だった。ubuntu 13.10 からログイン関係は systemd がデフォルトになったため gnome-session の他に、gdm を –enable-systemd もしくは –with-systemd するなどして有効にすると上手く機能しなくなった。前の 3.8 から共に systemd をサポートしていたのだけれど、全て無効にしていたので問題はなかった。3.10 では無効にすると逆にログインできなかった。この現象は、ubuntu パッチとして提供さている XDG_CURRENT_DESKTOP なんていう環境変数を gnome-session と gdm 共に export しておくことで解決した。どうやら片方にしか適用していなかったのが問題っぽい。ubuntu って、こういうパッケージを超えたポリシーを多用するので困る :$。まぁ debian/changelog にそれぞれ書いてあると言われるとそれまでだけど。
2は gnome-shell のバグ。
3は原因不明。システム規模のアップグレードをしていたらいつの間にか表示されるようになった。JS のエラーだったような気がするけど。
4は Tracker 0.16 をリビルドする (かアップグレードする) 必要がある。
5は GTK+ 3.10.5 から発生している。例えば g-c-c を開くと、こんな感じ:
G310-GTK_3.10_Issu_with_line-wrap.png
どうもラベルのラッピングのパラメータを指定していないと発生する現象らしく git の log には

Author: Matthias Clasen <mclasen@redhat.com>
Date:   Sun Dec 1 14:55:02 2013 -0500
Fix problems with dialog sizing
Many dialogs contain wrapping labels, but don't set max-width-chars on them. Previously, we were capping their width at 640, but since 3.10.5, they extend all the way to the width of the screen, which is not the desired behaviour.
Go back to capping the width of dialogs at 640 in the stable series. In git master, we will set max-width-chars on the labels instead.
https://bugzilla.gnome.org/show_bug.cgi?id=719516 https://bugzilla.gnome.org/show_bug.cgi?id=719569

って 3.10.6 で直ったとあるけどまだ再現するものがある :$
6 は g-c-c のオンラインアカウントで新規にアカウントを追加しようと [+] ボタンを押下するとクラッシュする。ちょうどここで報告されている現象と全く同じ。Bugzilla には一応登録されているようだけど解決したのかどうかは不明。
7 は修正方法はわかったんだけど、まだ稀に発生する。GNOMEシェルを再起動すると直ったり直らなかったり:

$ gsettings get org.gnome.settings-daemon.plugins.cursor active
true
$ gsettings set org.gnome.settings-daemon.plugins.cursor active false

で、以下はアプリ別に気づいた点など。
GTK+ など
Cairo 1.2.16 は初めて –enable-gl=yes でリビルドした。DRI を使って Kernel の Nvidia ドライバが提供する DRM でアクセスしているのか、体感でも描画は速くなった (このあたりは以前翻訳した “The Linux Graphics Stack” を参照のこと)。
GTK+ 3.10 はというとコンテナ・クラスがいくつか追加されている。例えばアニメーションを消したり出したりする GtkRevealer クラス、いろいろなコンテナをリスト状に配置する GtkListBox クラス、スタックに格納した子ウィジェットを一度に一つだけ順番に表示する GtkStack クラスの他、Nautilus のサイドバー相当の機能を提供する GtkPlaceSidebar クラスなど。
あと GTK+ のウィジェットを HTML5 互換のブラウザ上で描画するためのバックエンドである Bloadway のデーモンもビルドできるようになている。使い方は説明にあるとおり:

①まずデーモンを起動する
$ broadwayd
Listening on /run/user/1000/broadway1.socket
②別の端末から GDK のバックエンドとして broadway を指定して、GTK+ のアプリを起動する
$ GDK_BACKEND=broadway LIBOVERLAY_SCROLLBAR=0 gtk3-demo
とか
$ GDK_BACKEND=broadway LIBOVERLAY_SCROLLBAR=0 gedit

最後に HTML5 をサポートするブラウザから http://localhost:8080/ にアクセスするだけ:
G310-GTK_3.10_Broadway_demo.png
あとは、上であげたダイアログの幅が妙に大きくなる問題をなんとかしてもらいたい。
GNOME シェルとデスクトップ全般
これが現在の GNOME シェルとデスクトップ。小物は 3.8 からあまり変更していない:
G310-GNOME_Shell_Desktop.png
ちなみに、前バージョンを紹介したブロクでも書いたけど、背景と Nautilus との関係は無くなってしまったので、この 3.10 でも同様に Nautilus と g-s-d にパッチをあてて Nautilus で背景を描画するようにしている。
リリースする度に思うのだけれど、慣れ親しんだテーマが次のリリースでは使い物にならないのは、なんとかならないものだろうか :(。GTK+ しかり、GNOME シェルしかり。毎回アップグレードするとテーマの一部または全部が「ボロボロ」になってしまい、新しいテーマを探さなくてならない。それにリリース出始めは満足できるテーマが揃っていないし。
これは GNOME シェルの拡張機能にも言える。新しくしたのは良いけど、また新たに User Experiences を構築しないといけないって言うのはダメでしょ。
次は、検索時のアクティビティ画面。外観は 3.8の頃とあまり変わらない。「全てのアプリ」の一覧がページ単位でスクロールするようになったくらいか:
G310-GNOME_Shell_Activity.png
強化されたのは検索機能。これは tracker を起動して情報を収集しておかないと、あまり期待した結果にならないけど、結構便利 (下は「gnome」を検索した結果):
G310-GNOME_Shell_Activity_and_Search.png
トップバーの右端にある音量と電源ボタンの部分をクリックすると、メイン・メニューが表示される:
G310-GNOME_Shell_MainMenuButton.png
メイン・メニューは、使用しているテーマ (や拡張機能) によって若干変わるけど、概ねつぎのような感じ:
G310-GNOME_Shell_MainMenu.png
テーマに関わらず決まって一番下にメニュー項目が並んでいて、左から設定 (g-c-c)、画面のロック、電源OFF/再起動のボタン。メイン・メニューの中には音量系の部品がデフォルトで含まれている。さらにユーザ名の横にある折りたたみのボタンを押して展開すると、ログアウトボタンとユーザの切り替えボタンが表示される:
G310-GNOME_Shell_MainMenuUserButton.png
あと、ネットワーク設定や Bluetooth のアイコンは、これらのハードウェアが実際に接続されている場合にしか表示されなくなった。この設計思想も理解できないよね。有線 LAN 使っていても何かと設定したくなるだろうに。一応 g-c-c からはできるけど:
G310-GNOME_Shell_MainMenu_WiFiButton.png
あと GNOME シェルで何か書くことあったかな。3.8 の拡張機能も未だに半分以上は利用できないし。多少メモリ・リークが少なくなった!?くらいか。
上にある画面のロックを解除できない問題があった時はホント大変だった。3.8 で、普通にディスプレイの電源が切れるとロックがかかるようにしていたので、一度ロックがかかると毎回バックグランドから gnome-shell に HUP を投げて解除していた :(
GNOME Tweaks
UI が作り直しで、3.8 の頃よりもわかりやすく、日本語に翻訳しがいがあるようになった:
G310-GNOME_Tweaks-01.png
G310-GNOME_Tweaks-02.png
とはいえ、いつも思うけど、このアプリと g-c-c の関係がわからんなぁ :/
Nautilus
変わったところは、サイドバーを GtkPlaceSidebar クラスで置き換えたくらいか。おかげで、かなり前から当てていた、サイドバーに表示するアイテムの順番を変えるパッチが無用になってしまった。なんで「ブックマークの一覧」は折りたためないんだろうか。
あとは、自分の場合は背景を描画する機能を revert するパッチを ubuntu から移植している。
ということで、スクリーンショットは割愛。
と、まぁホントはもっと他のアプリなどを紹介したかったけど、だらだらと長くなってきたので、またの機会 (TAKE 2) に持ち越すことにする (やる気があればだけど… :X)。

Up to GNOME 3.8 (TAKE 02).


【Note】
2013年12月現在、既に GNOME 3.10 にアップグレードしてしまったけど、せっかくなので、当時書きかけの投稿を出来ているところだけ公開してみる。苦心して screencast も撮ったし。



移行した GNOME 3.8 のデスクトップで (良し悪しを含め) 気になったアプリをまとめてみた。
Nautilus
前のバージョンでの使い勝手については散々な感想にしたけど、この半年間使っていて基本的な操作を行う上では (いやがおうにも) 慣れてしまったという感じが否めなくなってしまった :|:
GNOME3.8-NautilusFileBrowser-20130721.png
今回のアップグレードで印象が良かった機能が二つあって、そのうちの一つがアイコンをドラッグしてフォルダの上に移動させると、フォーカスが当たったフォルダが自動的に開くというもの:

GNOME3.8-NautilusFileAction-20130721.png
アイコンをフォルダの上にドラッグすればどんどんフォルダ間を移動できる。
もう一つは gnome-terminal に Nautilus プラグインが追加されたので、従来まで使用していた buggy な nautilus-open-terminal が不要になったこと。なんと言っても端末がちゃんと指定したフォルダの中で開くようになって、端末指向のユーザにとっては今まで無かったのが不思議なほど当たり前でお世話になる機能:
GNOME3.8-GnomeTerminalPlugins-20130722.png
これが Nautilus 用のプラグイン:

$ dpkg -S  /usr/lib/nautilus/extensions-3.0/libterminal-nautilus.so
gnome-terminal: /usr/lib/nautilus/extensions-3.0/libterminal-nautilus.so

Up to GNOME 3.8 (TAKE 01).

正式なリリースから大分時間がたってしまったけど、なんとか GNOME 3.8 のデスクトップへの移行が完了した。今日現在で最新のマイナーリリースのバージョン 3.8.3 (2003年6月16日リリース) なので、実際には一ヶ月程度の遅れだけれど :P
この春に (GNOME 3.8 リリースにむけて) 新マシンを購入したんだけれど手をつけている時間がまったくなくて、手っ取り早く Ubuntu 13.04 の GNOME フレーバーのベータ版のインストールから始めて、週末の度にパッケージをビルド・インストールしてきたという次第。
ちなみに、Ubuntu 13.04 から (混じりけなしの) 正式な multiarch のサポートになったため、例えばそれまでのように ia32-libs なんかで (32/64bit 版との間で異なるバージョンのライブラリを) 一括インストールする訳にはいかず、主要なライブラリはその 64bit 版と同じバージョンで 32bit 版をインストールしなければならなくて、その準備やらに結構時間をくってしまった。結論としては、ちゃんと便利な (chroot を使った) ビルド・システムが用意されていて、ベースのファイルシステムを作るのに多少ディスク容量と時間を必要とするものの、それ以降は簡単なスクリプトで amd64 のパッケージをビルドした後に i386 のパッケージをビルドして同時にインストールするってな具合で進めていったのだけれど。
GNOME 3.8 の方はビルド時の依存関係なんかを調べるのが面倒なので、いつもどおり build.gnome.org の jhbuild のビルド一覧を参考にしようと思ったのだけれど、いつの間にかシステムがアップグレードされて無くなってしまったので、仕方なく jhbuild のモジュールセットを直接参照しながら順番にビルドした。
あと、Ubuntu 13.04 って未だ systemd を完全にサポートしていないんだな :(systemd-services なんてパッケージが入っていたものだから、てっきりサポートしているものとして gnome-sessiongdm–enable-systemd=yes でビルドしていたんだけど、GDM や GNOME シェルからリブートやシャットダウンできなかったり、NetworkManager 経由でネットワーク・プロパティを変更できなかったりと、あとで色々トラブってしまった。よくよく確認してみるとサポートしているのはログイン、時刻と日付、ロケールぐらいだったよ :$
で、本当は一回で紹介してしまおうと思ったのだけど、しばらくぶりのブログで書くのに時間がかかってしまったので何回かにわけることにした ;)
Login Sessions
リリースノートにあるように「GNOME クラシック」とか「GNOME 初期設定」なんかが追加されていた。前者は GNOME 2 ライクなスタイルを GNOME 3 (GNOME シェル) で表現しただけ。別に GNOME 2 になるわけではない。Ubuntu が patch で用意している「GNOME Fallback」が実は metacity や GNOME パネルを使った GNOME 2 相当のセッション。あと後者は gnome-initial-setup という未だ中途半端なパッケージが提供するセッション。ひと通り環境設定が済んだら $HOME/.config/gnome-initial-setup-done なんてファイルが touch されて次回からはこのセッションに入らないような仕組みのようだ:
GNOME3.8-NewSessions-20130715.png
これが GNOME クラシック (GNOME 2風なパネルを GNOME シェルの拡張機能を使って表現しただけ) のセッション:
GNOME3.8-GNOME_Classic_Session-20130715.png
これが GNOME 初期設定のセッションの一部で、他にもいくつかのお決まりのステップが用意されている。どこかで見たことがあるかと思ったら Mac OS X を初めて設定する時に出てくる設定ダイアログそのままで、特に目新しさも無いし出来もまだまだ:
GNOME3.8-GNOME_InitialSetup_Session-20130715.png
GNOME3.8-GNOME_InitialSetup_Session-02-20130715.png
一応 GNOME シェルで利用できるセッションは次のコマンドラインから確認できる:

$ gnome-shell --list-modes
gdm
initial-setup
user
classic

そして実際に GDM からログインすると、なんと GNOME シェルのセッションに入る際に背景がズームインしてくる:
DesktopZoomIn-AfterLogin-20130713.png
DesktopZoomIn-Completed-20130713.png
GNOME 3.8 では、このように Clutter を使った画像効果が随所に追加されている。他には GNOME コントロールセンターの各ペインを切り替える時に前のペインの残像を残しつつ次のペインに遷移するなんかがある。
My Latest Desktop
これが、いろいろ GNOME シェルの拡張機能 (gnome-shell-extensions パッケージの他にウェブサイトの Extensions) を追加した現在のデスクトップ:
GNOME3.8-MyCurrentDesktop-20130715.png
アプリのランチャは前のバージョンのデスクトップ同様に Docky だけど、これ横に長くなるまでランチャを追加してしまうと GNOME シェルの下部にあるメッセージバーを表示させるためのホットスポットを探すのが面倒 (このバージョンからマウス・ポインタを移動させるだけでよくなった) なので、ある程度だけで残りは この拡張機能を使っている。
拡張機能に含まれているアプリケーション・メニューを使うという考えもあるけど、アプリを探すならアクティビティ画面からの検索の方が便利 (各アプリに付属する .desktop ファイルの Keywords に含まれる単語を使ってそのまま検索できる)。なので、慣れると [Super]+A キーだけで十分便利だ。このあたりはリリースノートの記述が詳しい。
これが検索時のアクティビティ画面。日本語でも検索 OK:
GNOME3.8-AppSearch-20130715.png
このバージョンから背景の描画方法が Nautilus から GNOME シェルに移行された。それも ReleaseCandidate 版で急に。そのため前のバージョンのデスクトップ設定が残っていると、デスクトップアイコンを表示する際に背景が単色で表示されてしまう。これ結構ユーザをいろいろ混乱させたようだ。Ubuntu では背景の描画処理を Nautilus にバックポートしているくらいだ (こっちは Unity とか他のデスクトップのことを配慮したため):
GNOME3.8-BackgroundByGnomeShell-20130715.png
そして背景の変更は Nautilus ではなく GNOME シェルのコンテキストメニューから選択できるようになっている:
GNOME3.8-SelectBackground_From_GNOME_Shell-20130715.png
とは言っても GNOME シェルの背景と Nautilus のデスクトップ・アイコンの統合は不可能ではないようで、次の設定を有効にするだけで OK だった:

$ gsettings set org.gnome.settings-daemon.plugins.background active true
$ gsettings set org.gnome.desktop.background show-desktop-icons true

バージョン 3.8 の GNOME シェルも長く使っていると操作が遅くなってくるので再起動の操作は必須だな。メモリ使用率 (RSS) を見ても上位に入るくらいだし。バージョンが上がる度に API も変更され、今まで慣れ親しんだ拡張機能が (一時的に) 使えなくなることもしばしば。このあたりが毎回アップグレードする際の悩みどころなのだけれど、個人的にはもう少しパフォーマンスが良くなってほしい :|
My Favorit Extensions
よく使いそうな拡張機能が、このバージョンの gnome-shell-extensions に含まれているので、あとはお好みで。赤色のマークがついているのがウェブサイトから入手した拡張機能:
GNOME3.8-GNOME_Shell_Extensions-20130715.png
その中でもお気に入りの拡張機能が、実はデスクトップ右上隅に固まっていたりする:
GNOME3.8-Favorit-Extensions-20130715.png

Weather は GNOME 3.8 から仮採用されている gnome-weather っていう天気を一覧で表示するアプリなんかよりも便利で見やすい。デスクトップ上にあるので直ぐに参照できるし、日本人には不評の libgweather ライブラリを使っていないので国内でも市区県レベルで天気を確認できる。あとは Web Search Dialog なんかもウェブ検索する際には直ぐにアクションできるので嬉しい:
GNOME3.8-Favoriit-Extension-WebSearch-20130716.png
とりあえず、こんなところまで。

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

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
})

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