Latest topics 近況報告

日経Linux 2012年12月号は「#!シス管系女子」休載です - Oct 08, 2012

もうすぐ日経Linuxの12月号が発売される頃なのですが、今号は「#!シス管系女子」は休載です。楽しみにされていた読者の方、本当にすみません。

本作は昼間の本業が終わってから夜中の時間や土日を使って制作しているのですが、僕の手が遅いためいつもスケジュールに余裕がなくて、風邪＋中耳炎で数日ダウンしたために12月号には制作が間に合わなかった……という次第です。

「たった数日のダウンでなんで落ちるんだ？」というのはもっともな疑問なんですが、過去にもこういう不意のトラブルがあって、そのせいで1回完成が後ろにずれ込んだまま、その後遅れを解消できない・安全マージンが消滅した状態がずっと続いてしまっていました。安全マージンが消失した後でそれを回復できないままだったというのが問題なので、安定してマージンをとれるように、制作にかかる時間をもう少し短縮できないものかと悩んでおります……

なお、本来であれば12月号に載るはずだった原稿は、2013年1月号掲載用として手直ししてすでに完成済みなので、そちらはちゃんと載る予定です。

Tabs Outlinerとツリー型タブ - Sep 21, 2012

Tabs OutlinerというGoogle Chrome/Chromium用拡張機能がある。説明をよく読むと、Firefoxでツリー型タブを使っていた人が、Google Chromeに乗り換えるにあたって作った物らしい。

以前試した時は、リンクからタブを開いてもツリーが構築されないというのが「えっ」という感じであんまりよく試さないでアンインストールしちゃったんだけど、今日なんとなくまたインストールしてオプションを開いてみたら「Tree Style Tabs」ってチェックボックスがあって、そこに書いてあった説明を見たら「これONにしたら自動でツリーになるようになる」的な感じっぽかったので試してみたら確かにリンクから開いたタブが勝手に子タブになってくれた。

ということで、ツリー型タブにロックインされてしまってるせいでFirefoxからGoogle Chromeに乗り換えられないという人（時々そういう話を目にするのです）にとってこれはマジに救世主になるかもしれないなと思ってもうちょっとだけ試してみてた。タブの切り替えがダブルクリックじゃないとだめだったり、他の拡張機能との連携はさすがにできないっぽかったり、Google Chrome本体のメニューから終了したらツリー構造が保存されなかったりで、僕自身が乗り換える先としては厳しいなあ……とは感じたけど、そういう所が気にならない人なら、普通に使えるんだと思う。

そんな「Tree Style Tabs」モードなんだけど、チェックボックスの下にすごく長い注意書きが付いてた。僕が読み取れた大意としては、「そういう要望がものっそ沢山寄せられるから機能を付けてるけど、自分（作者）はこのモードはお薦めしない。試してみてもいいけど、このモードだけで使うんじゃなくて、このモードをOFFにしたTabs Outliner本来の状態でも是非使ってみて欲しい。」ということが書いてあるようだった。同様のことがTabs Outlinerの配布ページにも書いてあって、作者の人によると、ツリー表示は情報の一覧性が悪くて、フラットなタブのリストの方が可読性が高いぞ、と。ツリー、ずいぶん嫌われたもんですね……

この見解の違いは、タブとタブのツリーという物をその人がどう捉えているのか？　という所から生じているのだと思う。

僕にとって、タブのツリーは（生存期間は短いけれども）ある情報を起点にしてあちこちさまよい歩いた足跡そのものであって、どのページからどのタブへ辿り着いたのかが視覚化されているということが非常に重要だ。僕はその関係性を目で追って「分かれ道になったノードはどれだったっけ」と探している（ちなみに、この時見ているのは主にfaviconと情報化タブが提供するサムネイルで、タブのラベル文字列は注視していない）。1階層のグループ化しかできないPanoramaだけでは不十分なのは、「新しいタブを開いて分かれ道になったノードがどれだったか」という情報が欠落してしまうからだ。

そのくらい憶えておけよって言われるだろうけど、僕はほんとに頭が悪いというか物覚えが悪いというかバカなので、「そのくらい」がもう悲しいくらい絶望的なほどに覚えられない。覚えられないから、そのまま視覚化して置いておく。僕にとってタブのツリーは、脳に収まりきらない情報を置いておく外部記憶になっていると言える。メインメモリの中に情報が乗り切らなくて、画面の中にしか置いておけないのだから、多少アクセス速度が遅いとしても、そこに置いてある情報を毎回取りに行く。そういう使い方をしていると思う。

でも、「そのくらい」を覚えるのが苦にならない人にとっては、オーバーヘッドが大きすぎてまどろっこしいのかもしれない。タブ同士の関係はこぼれることなくメインメモリの上に載りきっているから、わざわざ画面の中にまで同じ情報を残しておく必要性が無い。そういうことなんじゃあないだろうか、と思う。

極端なことを言えば、ツリー型タブというのは脳味噌の性能が極めて低い障碍者がフツーの人に後れを取らないように、フツーの人に合わせて作られた社会の中で日常生活を送るために不足分を補うために使う、義肢とか車椅子とかそういう物に相当するのかもしれない。電動車椅子に乗れば確かに誰でもラクに移動できるけど、自分の足で立って歩ける人は、車椅子を降りて歩いた方が自由にもっといろんな所に行ける。また、電動車椅子に慣れきってしまうと、脚がひなびて自力で立てなくなってしまうかもしれない。使わなくても生きていけるなら、使わない方が健康でいられるのかもしれない。ツリー型タブという物については。

ツリー型タブがあると遅くなるとかツリー型タブが重いとかその辺の話について - Sep 17, 2012

ツリー型タブが重いという声をたまに見かけるんだけど、そういうのを見かける度に「ほんとかなあ？」とついつい思ってしまう。

もちろん、素のFirefoxに対して余計な処理を加えるわけだから、そりゃあ、元の状態より重くはなると思う。でも、「重い」って言ってる人の言ってる「重い」は、なんというか、そういうレベルのことを言ってるわけではないって気がする。もっと鈍重な、全体的に動作がヤバイくらい緩慢になる、そういうのを指してる気がしてる。

で、そういう現象が起こるとして、本当にそれがツリー型タブのせいなのかどうか。ツリー型タブを使っている時と使っていない時とで、同じ数のタブを開いていて、同じ時間だけブラウジングした状態で、ツリー型タブがある場合だけ顕著に性能が劣化するのかどうか。というのが、この件で自分が一番気になっているポイントなのです。

何故僕はこうまで頑なに「ツリー型タブが原因で遅くなっているのだ」と素直に認めようとしないのかというと、基本的にツリー型タブはブラウザのコンテンツ領域や履歴にはタッチしないように設計しているつもりなので、「コンテンツ領域に起因するメモリリークがある」とか「履歴を消去したら軽くなった」とかの報告があるという事自体が、どうにも不可解なのです。

実際、about:memoryではタブ毎にメモリの使用状況を確認できますが、「about:memoryを見ると、メモリが解放されていないことが分かる」と言われた再現条件をこちらで試行しても問題が再現せず、その後報告者の環境でもツリー型タブだけをインストールした状況では問題が再現しなくて、どうやら他のアドオンがこの問題の原因になっているのではないかという話になったこともありました。

ツリー型タブがあるとタブを開く数が増える＆1つ1つのタブの生存期間が長くなる傾向があると思うので、他のアドオンやFirefox自身が潜在的に抱えてはいるものの普段の利用では無視できる程度だったという問題があったとしたら、それらがより顕在化しやすい状態になるとは思います。例えばあるアドオンを入れていると全体の動作が0.1秒遅くなるとして、5つくらいタブを開いている状況ではそれが気にならなかった。でも、ツリー型タブを入れてタブを50とか開きっぱなしにしていると、些細な重さでもそのまま×50されるから、シャレにならない重さになる。こういう事は十分にあり得ます。でもツリー型タブ単体でそういう事が起こるとはどうしても自分には考えにくいのです。

「コンテンツ領域への参照を残しているせいでメモリリークが発生する」というのは自分もアドオン開発初期にはよくやらかしていたミスなので、かなり後の方になって開発したツリー型タブの頃にはそこらへんのことは想定に入れられるようになっていて、多少速度を犠牲にしてでも安全になるように、だいぶ気をつけて設計したという認識があります。「そこまでやらんでもええんちゃうん」って所まで偏執的にやってることすらあります。Firefox本体のコードでもaddEventListenerした物をremoveEventListenerせずに放りっぱなし（多分ガーベジコレクション任せ？）になってるのとか見ると、怖いなーって思ってしまうくらいです。

その一方で、僕は「これこれこのアドオンと衝突してるんだけど」という報告を受ける度にそのアドオンのソースを見るという事がこれまで結構あったのですが、ソース見てげんなりすることが割とありました。これメモリリークするやろ、とか。で、そういう問題を解決しようと思ったら、根本的なアーキテクチャの変更が必要だったりして。そういうとこまで見だすときりが無いし、大体それは僕の領分でもないので、ツリー型タブとの衝突の原因になってるとこだけ見てあとは見て見ぬふりしてるんですけども。

そういう惨状を見てるから、僕の心情としてはついつい、まず最初に他の原因の方を疑ってしまいます。それらの可能性がなくてちゃんと明らかに「ツリー型タブが原因だ」と断言できる、という所にまで絞り込まれてないと（はい。ほんとにツリー型タブが原因で問題が起こってる可能性も、もちろんあるとは思ってます。そこまで完全否定はできないです。）、調べようという気になかなかなれないです。これって、思い上がりすぎですかね？

あと、それとは全然別の話として、ツリー構造が何らかの理由で壊れてしまうせいで、無限ループが発生してフリーズしてしまう……という事は時々起こるみたいなので、そういうのはもう完全にツリー型タブの責任なので今後も粛々と直していきたいとは思ってます。

いずれの場合にしても、メンテナンスに十分に時間を割けない現状では「ツリー型タブのせいで問題が起こってる、かもしれない」という段階では動けなくて、「間違いなくツリー型タブのせいで問題が起こってて、この手順で100％再現できる」という所まで絞り込んでもらってることが、こっちで対処できるためには絶対に欠かせない条件という感じです。できれば「この部分が問題になっている」という所まで明らかにしてもらえてると嬉しいし、もっと言えば修正パッチをpull requestでもらえるのがベストなんですが。

それから、何と言おうとツリー型タブを入れてFirefoxの動作がおかしくなり、ツリー型タブを削除したことでこれらが解決されたことは事実なのです。 という風な話はもう何度あったか覚えてられないくらいにあって、GitHubのIssue Trackerを探してもゴロゴロでてくるんだけど、詳しく聞いてみると大概は他のアドオンとの衝突です（全部がそうだというわけではないですが、感覚的には、そうである場合の方が多かったという印象です）。こういうのも、じゃあどのアドオンと衝突してるのかという所まで明らかにさえしてもらえれば、何か手の打ちようが出てきくる可能性がありますので、より快適な生活を望む場合には、衝突の解消に協力してもらえたらなーって思います。

日経Linux 2012年10月号には「シス管系女子」第14話は載ってません、が…… - Sep 14, 2012

告知が遅くなったのですが、日経Linuxの10月号が発売されています。Amazonでも買えます。

こちらの雑誌で「シス管系女子」というコマンドライン豆知識漫画を連載していたのですが、実は前回で終わってしまいました。なんと、今号には「シス管系女子」は載っていません。

というのは釣りで、代わりに「#!シス管系女子」第1話が載っています。タイトルがちょっとだけ変わって、新シリーズです。なので、話数カウントもまた第1話からです。これって一応新連載なんでしょうか？

で、どこら辺が違うのかというと、新しいタイトルでぴんと来る人もいるかも知れませんが、シェルスクリプトを主軸に置いた内容にしていく予定です。コマンドライン豆知識漫画から、シェルスクリプト入門＋コマンドライン豆知識漫画にクラスチェンジです。みんとちゃんがどんどん濃い方向に突っ走っていく様を、どうか生暖かい目で見守って下さい。

ところで、前号からシェルスクリプト関係の連載がいくつか始まって、そのビッグウェーブに乗り遅れてなんでシス管系女子だけ1ヶ月遅れでシェルスクリプトなのかっていうアレなんですが、前号の作業を終えた後でリニューアルを打診されて「じゃあ手を出しやすい所でシェルスクリプトでも扱いますかねえ」とポヤーンと考えていたら届いた見本誌がシェルスクリプト一色で「ちょwwwwwwwwwきwwwwwいwwwwwてwwwwwなwwwwwいwwwww」ってなったんですけど、今更別のシリーズ（構想だけなら一応、Sambaでドメイン構築編とかアイデアがあるにはあったのです）にするのも厳しかったのでそのままシェルスクリプト編にしちゃいました。いやあ、みんな考える事は同じなんですね……

あと、「シス管系女子」第1話から第12話までのまとめ冊子が付いてさらに第13話も掲載の9月号なんですが、今見たらAmazonでは売り切れてました。マーケットプレイスでなら中古を買えるみたいなんですが、通常なら定価より値下がりする所、この号だけ高くなっちゃってました。バックナンバーのページから辿れるBP書店だと定価みたいなので、買おうと思ってたけど買いそびれたという方はこちらからトライしてみるといいかもしれません。

「プロメテウス」3Dで見てきた - Sep 03, 2012

とりあえず見とくか……的な。「エイリアン」好きだったし。

「エイリアン」で見覚えのある形をしたものがちょいちょい出てきてニヤリとさせられたんだけど、総じて「なんかよくわかんない映画だった……」って印象でした。「エイリアン」の前日譚っていう触れ込みだったから、アクションなりホラーなりの分かりやすい特徴に期待しちゃったんだけど、そういう分かりやすい（ユーザーフレンドリーな）映画では残念ながらなかった。

敵を2種類出すのは詰め込みすぎだったんじゃないかなあ。「俺は先に帰らせてもらうぜ！」ポジションな2人の扱いも適当っていうか投げやりっていうか……なんかわちゃわちゃ起こってた中の1つの出来事でしかなくって、あんまりオイシイ使われ方ではなかった気がするし。パンフレットを後で見たら「人類の起源に迫る」みたいな所が前面に押し出されてたけど、本編中ではそれすらもなんかわちゃわちゃ語られてた中の1つだった印象を受けました。そういう壮大なテーマよりはむしろ、デヴィッドとホロウェイ博士、社長さんとその子のやり取りから、子が親を超えるとか子が親を殺すとかそういう所の方が話の根底にある物なのかなーという気がしました。

Mozilla勉強会@東京 7th 発表資料を公開しました - Aug 19, 2012

Mozilla勉強会@東京 7thでの発表資料やサンプル実装を公開しました。

発表時は準備不足のため時間の配分に失敗し、満足な説明を行えませんでした。すみません。発表時に喋ろうと思っていた内容のメモも併せて公開していますので、そちらもご覧頂ければと思います。

続きを表示する ...

同居と食生活 - Aug 19, 2012

家事とか料理とか普通にしてますよって言ったら「意外だ」って言われた、という事が過去にあった。

「料理してる」という言葉の響きがなんか大仰だけど、実際僕の方がやってる事って、スパゲッティを茹でるか、ご飯の上に鰹節載せてレタスと水菜を刻んで載せてアボカドとネギトロ載せてマヨネーズと醤油かけて「アボカドネギトロ丼や－！！」って言い張って出すか、Cook Doするか、そんな感じですよ。特に料理が趣味というわけでも無い人間が、朝出勤して夜帰ってきた後に残った気力でできる事なんて、たかが知れてますよ。

なんとなくだけど、自分以外の人がいると、カップラーメン出して「晩ご飯これで」とか、スーパーで見切り品の弁当買ってきて「はい」とか、そういうのは、何か、こう……ちょっと、ないよね、って思っちゃって。結果的に取れる栄養の内容は大差なくても、スパゲッティ茹でて出来合いのソースかけて出す方を選んでしまう。

そこにどれだけの意味があるんだろう。見栄なんだろうか。薄いプラスチックのペコペコの容器で出す、っていう事に一番抵抗があるのかも。家でまでそういう器で食事を取るって、なんか、みじめな思いをさせてしまう気がして。そういうのが動機のかなりの部分を占めている気はする。栄養バランスをちゃんと考えていたら、こんなもんじゃ全然駄目なんだろうし。体裁だけ整えようとしてるんじゃんって言われたら、返す言葉も無いですね。

という風な事を、中村うさぎ×伏見憲明 トークライブの記事の私にしてもパートナーがいるとか、一緒に暮らしてる人がいるってことは、ちょっと重荷なのよ。だけど、その重荷がずっしりと重くて、背負って歩けないというほどではなく、ちょうどいい重しみたいな感じ。あたりの件を読んで自分を省みて思ったのでした。

「シス管系女子」1話から13話までまとめて読める日経Linux 2012年9月号発売中です - Aug 09, 2012

既にご覧になった方もいらっしゃるかとは思いますが、コマンドライン豆知識漫画の「シス管系女子」が連載されている日経Linuxの9月号が8日付けで発売となりました。Amazonでもお買い求め頂けます。

今回、別冊付録としてシス管系女子の1話から12話までを再録した「シス管系女子まとめ読み」が付いています（代わりにDVD-ROMは無し）。元々の掲載ページ数が少ないので全部で70ページにも満たないいわゆる「薄い本」なのですが、本誌掲載分も合わせると13話を一気読みできます。過去の回を見逃された方・「シス管系女子」ってなんやねん？と気にはなっていたけれども……という方は、是非ご覧下さい！

再録にあたって原稿を見返していると、「描き直したい……！」と思う所ばかりで、古い原稿はほんと見返すもんじゃないなと思いました。1話と2話はみんとちゃんの髪型が3話以降と少しだけ違ってた（3話から変えた）ので、カラー化のついでにそこだけ直しましたけど。

カラー化で思わぬ落とし穴だったのが、スクリーンショットでした。うっかりモノクロに変換した状態の物しか残していなかったので、同じような状況をまた作ってスクリーンショットを撮り直す羽目になってしまい、これがいろんな意味で辛かったです。元ファイルはなるべく残す、というのを怠ってしまった代償は大きかった……

ところで、付録の表紙と本誌掲載の13話（さらに言うとカラー化した1話・2話も）から、制作環境をComicStudio 4にアップグレードしました。コミティアの会場で買ってから半年ほど本棚の肥やしにしてしまってましたが、原稿のカラー化にあたってちょうどいい機会だと思って、頑張って移行してみました。ComicStudio 3から変わっている箇所が結構あって戸惑うことも多いのですが、13話を書き終える頃にはだいぶ慣れてきたような気もします。

あと、アップグレードついでに描画ツールを「鉛筆（ラスター）」から「ペン（ベクター）」に変えました。最初のもえじら組の同人誌で使った時に結構戸惑ったのと、やっぱり線編集に頼るのって邪道かな……という思いと、あと柔らかい線があって、それ以後ベクターのペンツールはずっと避けてしまっていたのですが、表紙に載せるならやっぱり綺麗な線じゃないとガッカリだよねとか、変な所にこだわって無駄に時間かかって汚い絵になるのと、ツールの助けを借りてサクッと綺麗な絵にするのとどっちがいいのかとか、そのへんの事を考えて、昼の仕事と無理なく両立させるためにも読者の皆さんにより良い物をお届けするためにもツールの機能を活かせる所は最大限活かした方がいいだろう……と考えを改めた次第です。

で、実際切り替えてみた感想ですが、いやー、いいですねこれ（手の平返し）。今までは「この線、なんか気に入らない……！」と思ったら消して描き直してという事を何度も何度も繰り返してたのですが、大体こんなもんやろってところで引けたら後は線修正で微調整するという感じで、ずいぶん時間が短縮された気がします。交点削除で髪の毛などの重なりを描きやすくなったのも大きい。あと、グレースケールのラスターレイヤに鉛筆を組み合わせた描き方だとどうしても線に半透明の部分ができてしまって、トーン処理する時に単純な閉領域選択の塗りつぶしだと線の所が逆に色が薄く見えてしまうというようなことが起こってしまっていたのですが、ベクターのペンツールだとパキッと線の色が着くので、単純な塗りつぶしのままでも結構見れる物になるんですね。これも時間短縮につながった気がします。

まとめると、ツールの機能をちゃんと使うと漫画制作は確実に楽になるのだなあとしみじみ実感したという話なのでした。

セッションの復元とツリー構造の維持 - Aug 07, 2012

ツリー型タブを3ヶ月ぶりに更新した。

地味な修正が多い中で特に地味な修正だけど、セッション復元でツリー構造が壊れるという問題について一定の改善を見られたのではないかと思ってる。実際に効果があったのかどうかは、今後同様のバグ報告が減るかどうかで見るしかない。

何故ツリーが壊れるか、という事の前にそもそもツリーが壊れるってどういう事やねん、という話なんだけど、ツリー型タブを使っててごく希に、「リンクから新しい子タブを開いても子タブにならない」とか「親にあたるタブには折り畳みのためのつまみが表示されているのに、子になったはずのタブはインデントされておらず、つまみをクリックしても子になったはずのタブが折り畳まれない」とかそういう怪しい挙動になる事があった。

何故そういう事が起こるのか。これはタブの管理方法に理由がある。

ツリー型タブでは、個々のタブに一意なIDをあらかじめふっておいて、tab.setAttribute(TreeStyleTabService.KPARENT, parentTab.getAttribute(TreeStyleTabService.kID)) とか tab.setAttribute(TreeStyleTabService.kCHILDREN, childTabs.map(function(aChild) { return aChild.getAttribute(TreeStyleTabService.kID); }).join('|')) とかいう感じにIDの文字列をキーにして互いの関係を保持している。親のタブや子のタブを取得する時は、TreeStyleTabService.getParentTab(tab) とした時にその中で tab.getAttribute(TreeStyleTabService.KPARENT) して取得したIDを使って（DOM3 XPathなどで）実際の要素を改めて取得するという風になってる。何故こうしたかというと、

• タブの要素ノードに直接 tab.parentTab = parentTab のようにしてしまうと、うっかり参照を消し忘れたらいつまで経ってもメモリが解放されないんじゃないか、という心配があった。（意図しない事態の発生を防ぐため）
• 実際には setAttribute() するのと同じタイミングで SessionStore.setTabValue(tab, TreeStyleTabService.kPARENT, parentTabId) のようにしてセッションに情報を複製しており、クラッシュ時のツリーの復元などに役立てている。（ツリー構造の永続的な保存のため）

といった理由があってのことだった。

これはそれなりに堅牢なやり方なはずだと思ってたんだけど、実際にできあがってからJavaScriptデバッガでプロファイリングしてみたら、IDの文字列からタブの要素ノードを探すという処理が呼ばれる回数が突出して多くて、それが結構無駄な待ち時間を増やす元になっているらしかった。それで、もう少し高速に動作するような仕組みを後から加える事にした。setAttribute(TreeStyleTabService.kID, id) するのと同じタイミングで、gBrowser.treeStyleTab.tabsHash[id] = tab; としてハッシュテーブルを作っておき、それ以後はそちらだけを参照するという、ごくシンプルな物だ。

上記のおかしな挙動は、このハッシュテーブルが原因だっていた。このハッシュテーブルの仕組みが上手く働くためには、「ハッシュテーブルに入っていないタブはない（すべてのタブがハッシュテーブルで管理されている）」という前提が必要になる。もし万が一何らかの理由でハッシュテーブルの管理から漏れてしまうと、そのタブはAPI経由では永久に見つけられないことになってしまう。そのタブを親として子タブを登録する、という風な事はできるのに、その子タブに保存された情報から親のタブを探そうとしても、ハッシュテーブルに無いタブだから見つけられない。こういう不整合の発生は考慮に入っていなかったので、親子関係に基づくインデント幅の調整などの処理が中途半端な所で止まってしまって、上記のような色々と不可思議な現象が発生していた。

色々調べた結果、大量のタブが一気にセッション復元された時に「現在のタブ」になっていたタブが、このハッシュテーブルの管理から漏れてしまうことがあるようだという事が分かった。なので、そのような場合もちゃんとハッシュテーブルに入るようにした。これによって、手元で再現性100％だったケースについては問題が起こらないようになった。これまでに報告があった全ての問題がこれと同一の原因かどうかは不明だけれども、今までよりは問題が起こりにくくなったという事は言えると思う。

あと似たような問題で、タブの復元のタイミングによっては「ツリー構造だけの高速な復元」ができなくなるという現象も起こっていた。ツリー型タブが完全に初期化されるよりも前にFirefoxのセッション復元の仕組みによってタブが復元されていた、という想定外の状況が発生していて、それで色々な前提が崩れてしまっていた。理屈から言ってなんでそうなるのかがてんで分からなくて、どうにかしてタブが復元されるよりも前のタイミングに割り込みたかったんだけど、どうも無理っぽかったので、既にタブが復元されてしまっていた場合でもちゃんとそれらのタブを「後から初期化」するようにした。

そういう地味な修正ばかりが入っている版です。

Unityのランチャーに沢山Firefoxの項目を追加する代わりにサブコマンド？にした - Jul 29, 2012

複数のプロファイル、複数のバージョンを検証用に用意しないといけなくて、簡単に使い分けられるような環境を作る必要があるのです。

1. Unityのランチャー上にある「Firefox ウェブ・ブラウザ」を右クリックして、「ランチャーに常に表示」のチェックを外す。

2. /usr/share/applications/firefox-custom.desktopとして以下の内容でファイルを作成する。

   [Desktop Entry]
   Version=1.0
   Name=Firefox Web Browser (custom)
   Name[ja]=Firefox ウェブ・ブラウザ (custom)
   Comment[ja]=ウェブを閲覧します
   GenericName=Web Browser
   GenericName[ja]=ウェブ・ブラウザ
   Exec=firefox %u
   Terminal=false
   X-MultipleArgs=false
   Type=Application
   Icon=firefox
   Categories=GNOME;GTK;Network;WebBrowser;
   MimeType=text/html;text/xml;application/xhtml+xml;application/xml;application/rss+xml;application/rdf+xml;image/gif;image/jpeg;image/png;x-scheme-handler/http;x-scheme-handler/https;x-scheme-handler/ftp;x-scheme-handler/chrome;video/webm;application/x-xpinstall;
   StartupWMClass=Firefox
   StartupNotify=true
   X-Ayatana-Desktop-Shortcuts=NewWindow;Sub;ESR;Stable;Beta;Nightly;
   
   
   [NewWindow Shortcut Group]
   Name=Open a New Window
   Name[ja]=新しいウィンドウを開く
   Exec=firefox -new-window
   TargetEnvironment=Unity
   
   
   [Sub Shortcut Group]
   Name=Sub
   Exec=firefox -no-remote -p sub
   TargetEnvironment=Unity
   
   
   [ESR Shortcut Group]
   Name=ESR
   Exec=/home/piro/opt/firefox-esr/firefox -no-remote -p esr
   TargetEnvironment=Unity
   
   
   [Stable Shortcut Group]
   Name=Stable
   Exec=/home/piro/opt/firefox-stable/firefox -no-remote -p stable
   TargetEnvironment=Unity
   
   
   [Beta Shortcut Group]
   Name=Beta
   Exec=/home/piro/opt/firefox-beta/firefox -no-remote -p beta
   TargetEnvironment=Unity
   
   
   [Nightly Shortcut Group]
   Name=Nightly
   Exec=/home/piro/opt/firefox-trunk/firefox -no-remote -p trunk
   TargetEnvironment=Unity
   

3. ファイルに実行権限を設定する。
4. Dashホームから「Firefox ウェブ・ブラウザ(custom)」を探して、実行する。
5. ランチャーに表示されたアイコンを右クリックして「ランチャーに常に表示」にチェックを入れる。

これで、アイコンを右クリックして各プロファイルで起動できるようになった。

ユーザのホーム以下にファイルを作成して複数のアイコンを登録してみたりとか色々試みてたんだけど、自分で付けた名前と表示名が一致しないとか色々動作が怪しくて、結局このような所（グローバルな設定ファイルとして作成）に落ち着いた。

2014年8月21日追記。Ubuntu 14.04LTSで、Thunderbird用の物も作った。

[Desktop Entry]
Encoding=UTF-8
Name=Thunderbird Mail (custom)
Name[ja]=Thunderbird電子メールクライアント (custom)
Comment=Send and receive mail with Thunderbird
Comment[ja]=メールの読み書き
GenericName=Mail Client
GenericName[ja]=電子メールクライアント
Keywords=Email;E-mail;Newsgroup;Feed;RSS
Keywords[ja]=Eメール;イーメール;mail;e-mail;email;メール;電子メール;ニュースグループ;ネットニュース;RSS;フ>ィードリーダー;書く;読む;Mozilla
Exec=thunderbird %u
Terminal=false
X-MultipleArgs=false
Type=Application
Icon=thunderbird
Categories=Application;Network;Email;
MimeType=x-scheme-handler/mailto;application/x-xpinstall;
StartupNotify=true
Actions=Compose;Contacts;AnotherProfile

[Desktop Action Compose]
Name=Compose New Message
Name[ja]=新しいメッセージの作成
Exec=thunderbird -compose
OnlyShowIn=Messaging Menu;Unity;

[Desktop Action Contacts]
Name=Contacts
Name[ja]=連絡先
Exec=thunderbird -addressbook
OnlyShowIn=Messaging Menu;Unity;

[Desktop Action AnotherProfile]
Name=Start with Another Profile
Exec=thunderbird -no-remote -p sub
OnlyShowIn=Messaging Menu;Unity;

Firefoxの物を作った時と微妙に様式が変わっているようだ。