Mac OS X Lion になって、これまで Leopard / Snow Leopard とデフォルトで使ってきたアプリケーションが変わりました。

ブラウザ

Firefox → Safari

メーラー

Thunderbird → Outlook

開発環境

Xcode 3 → Xcode 4

Firefox / Thunderbird という Mozilla 組でも問題があるという訳ではないのですが、

• Safari → 動作が軽快。スワイプジェスチャーによる「戻る・進む」動作が視覚的に分かりやすい
• Outlook → 動作が軽快。横長レイアウトが見やすい

という点が気に入って、現在 Safari と Outlook (Microsoft Office 2011) を使っています。

Firefox / Thunderbird どちらも Maximizer を利用することでフルスクリーンアプリケーションとして利用することができます。

Word / Excel / PowerPoint は Carbon アプリケーションで Maximizer でもフルスクリーン化できませんが、Outlook は Cocoa アプリケーションでフルスクリーン化が可能です。

メーラーに関しては、Apple 純正の「メール」も候補の一つでした。Mac OS X Lion の「メール」は横長レイアウトがサポートされ、フルスクリーンで利用することで、MacBook Pro 13 インチの画面の狭さがあまり気にならなくなります。

「メール」だとフルスクリーン化した時、メールの編集画面がその場で開きます。Landscape (横画面) で使っているときの iPad のメール編集画面と同じように動作すると言えばイメージできるでしょうか。

一方、Outlook では Maximizer でフルスクリーン化している影響もあるのだと思いますが、メール編集画面は別画面で開きます。結果、もうひとつ別のフルスクリーンが追加されるような形で動作します。

一見すると、「メール」での動作の方がフルスクリーンアプリケーションとしては自然な感じがするのですが、このインタフェースだとメール編集中に他のメールが見ることができないという欠点があります。

他のメールからコピーしたいときは一度下書き保存してメール編集画面を閉じる必要があります。一方、Outlook の方式だと、メール画面は別スクリーンなので、Outlook のメインスクリーンに戻れば、いつでも他のメールを確認することができます。

また、私の環境では、Apple 純正の「メール」よりも Outlook の方がキビキビ動作している印象です。

Outlook も IMAP 接続でサーバ側ですでにある「下書き」フォルダや「送信済み」フォルダを使ってくれず、独自のフォルダを作成してしまうという作法的にどうなのという仕様がありますが、使い勝手の面で Apple Mail / Thunderbird に優っていると今のところ感じています。

開発環境は Xcode 4 に……。Xcode 3 はおそらく Mac OS X Lion にはインストールできません (試していませんが)。Xcode 3 & Interface Builder という組み合わせでできていたことが、Xcode 4 でできなくなっていたりします (例えば、高解像度での xib ファイル編集など)。

とは言っても、MacBook Pro になって初代 MacBook で感じていた「重さ」は解消されましたし、タブインタフェースとフルスクリーンの活用で、画面の「狭さ」はあまり気にならなくなりました。

ちなみに以下のアプリケーションを通常フルスクリーンで利用しています。

• Safari
• Outlook
• iTunes
• iPhoto
• Xcode 4

Maximizer を利用しているせいなのか、iPhoto はフルスクリーンで挙動不審になることがあります。iLife アプリケーションは、今のところ iPhoto ぐらいしか使っていませんが、おそらく GarageBand や iMovie もフルスクリーンで利用したほうがいいような気がします。

ちなみにフルスクリーンはマルチディスプレイ環境とは、あまり相性がよくありません。フリーズするとかそういう相性ではなく (私の環境では一度もフリーズしたことはありません)、インタフェース的にマルチディスプレイが考慮されていない感じ。

フルスクリーン化されたアプリケーションはメイン画面のみに表示され、サブ画面はログイン画面でも利用されているデフォルト背景が表示されるだけの画面になります。……なんかもったいない。フルスクリーンのサブ画面は補助的なデスクトップとして利用できたりしたら、ぐっと使いやすくなる感じがするのですが。

Mac OS X Lion で新たに導入された Launchpad ですが、正直なところ使い勝手は今ひとつという印象。

こんな人には向いている……？

まっ更な状態から始めるという方には Launchpad は使いやすいかもしれません。

アクセスのしやすさは抜群 (Mac OS X Lion がプリインストールされたラップトップなら専用キーもある) ですし、インストールされたアプリケーションを俯瞰してざっくり探すのには向いています。

Mac App Store からインストールされたアプリケーションは、ここを見ればあるのが確実なので、迷うことも少ないでしょう。

なにより iPad / iPhone のスプリングボード (ホーム画面) と同じようなインタフェースで、同等のユーザーエクスペリエンスを実現しています。同等なグループ機能ももちろんサポートされているので、同じような感覚で利用できます。

Snow Leopard から移行すると……

ただ、Snow Leopard から移行した場合には、「アプリケーション」フォルダにあるアプリケーションは、ほぼもれなくリストアップするという仕様が「あだ」になっているような気がします。

Snow Leopard から移行した場合、以下のようなルールでリストアップされているようです。

• メインの「アプリケーション」フォルダ以下のアプリケーション
• 「アプリケーション」内の「ユーティリティ」フォルダは「ユーティリティ」グループとして登録
• 「ユーティリティ」以外のサブフォルダは第一階層のみ「アプリケーション」フォルダ直下に置かれているものとして扱う。例：Micorosoft Office 2011
• サブディレクトリの第二回層以下はフォルダ名をグループ名にして登録
• ホームディレクトリ直下に置かれた「アプリケーション」もメインの「アプリケーション」と同等に処理される
• 「/Developer/Applications」の直下に置かれたアプリケーションは「Developer」グループとして登録

従って Snow Leopard から移行すると、いきなり大量のアプリがざっくり平面的に登録されている、なかなかカオスな状態でスタートします。

上述のルールを元に Lion に移行する前に Snow Leopard のアプリケーションディレクトリを整頓しておくのはひとつの「手」です。アプリケーションによっては場所を変えるとまずいものもあるかもしれませんが。

解決策はあるのかな？

それでも柔軟にカスタマイズできれば問題ないのですが、インタフェースは基本的に iPad / iPhone のスプリングボード (ホーム画面) を移植してみた程度の出来で、「カスタマイズも面倒くさい」というのが正直な印象です。

編集モードで複数のアプリケーションを選択できるようにしたり、キーボードショートカットで削除できるようにするだけでも、かなり印象が違うと思うのですが……。

余談になりますが、Launchpad ではアイコンを長押しして編集モードに入る iOS 的な操作以外に option キーを押すことで編集モードに入ることができます。shift キーを押すとスローアニメーション、カーソルの左右キーでページ移動がそれぞれ可能です。

Lunchpad Control を利用すると Launchpad で表示するアプリケーションを選択できます。

余計なアプリケーションを隠すことができるので、ずいぶん使い勝手がよくなります。

一度非表示にしたアプリが不意に復活してしまう場合があった (OS の再起動で非表示にしたアプリが再登録されてしまうのかも……) ので、現在は使用を一時的に休止しています (2011.08.12 現在)。

Launchpad Control は「~/Library/Application Suppprt/Dock/」以下にあるデータベースファイルを編集して Launchpad での表示されるアプリケーションを制御しているようです。

リストを編集した際にオリジナルのデータベースファイルには backup という拡張子が付加されてバックアップ用に複製されるようです。

MacBook Pro セットアップ - システム環境設定編に続いて、SIMBL などの補助的アプリケーションについて

ImageUp

ImageUp は入力ソース (インプットメソッド・IME) の状態をメニューバーを使わずに視覚的に表示してくれるツールです。

フルスクリーンアプリケーションでは、基本的にメニューバーが表示されないので、現在日本語入力状態なのか、英語入力 (直接入力) 状態なのかが、一目では分かりません。

ImageUp では、「A marker at the cursor」というオプションをオンにすることによって、マウスカーソル付近に入力ソースの状態に応じてマーカーが表示されます。

メニューバーを表示したり、テキスト打ってみたりしなくても、入力状態が一目で分かるようになります。

SIMBL プラグイン

• Maximizer
• Safari Stand

SIMBL そのものは新規ではないのですが、新たに Maximizer を導入したので、触れておきます。

Maximizer は Cocoa アプリケーションで「フルスクリーン」に対応していないアプリケーションをフルスクリーン化するプラグインです。

Drift Diary XIII さんの「Maximizerで一足先にLionの新機能を満喫する」にあるとおり、Mission Control できちんとフルスクリーンアプリケーションとして認識してくれるようになるのが大きな特徴です。

相性の良い・悪いはあるようですが、後述する Outlook がきちんとフルスクリーンアプリケーション化されるので、重宝しています。

Safari Stand は定番 Safari 強化プラグインですね。アドレスバーでキーワードが利用できるようになるのが、かなり便利です。

Homebrew

• wget
• git
• imagemagick

Homebrew は Mac OS X 上の UNIX のパッケージを管理するソフトウェアです。

これまでは MacPorts を利用していました。MacPorts では、バイナリを /opt/local/bin/ という独自のパスにインストールするためパスを通したり、シンボリックリンクを張ったりハック的な運用が必要でした。

Homebrew では、標準にパスとして通っている場所にバイナリをインストールするので、標準な環境と親和性が高くなっているのが特徴です。

実際、MacPorts では若干苦労していた ImageMagick のインストールは Homebrew を使ったら、呆気なくできたり……。素晴らしい。

git は Xcode 4 と一緒にインストールされるので、必要ないんですが、テスト的に brew を使ってアップデートしました。

Mac OS X Lion になって色々と新しく機能が追加されたのに伴い、Snow Leopard と作法が変わった部分もあります。

基本的にはできるだけ Mac OS X Lion の新しい作法に準じる方向で使っていたほうが後々楽だと思うのですが、まだ不安定な部分もあったりするので、試行錯誤しながら使っています。

2011.08.11 現在、「システム環境設定」の主な項目は次のように設定しています。

一般

• アプリケーションを終了して再度開くときにウィンドウを復元 → オフ

これだと Safari のセッションが復元されなくなってしまうので、Safari の「復元」だけを個別にオンにします。ターミナル上で

defaults write com.apple.Safari NSQuitAlwaysKeepsWindows -bool true

というコマンドを発行します。

「オン」にしていないのは、defaults コマンドで制御できないアプリケーションがあるからです。Carbon なアプリケーションはその傾向が強く、当面全体の設定は「オフ」でオンにしたいアプリケーションだけ defaults コマンドでオンにするという運用にします。

Dock

• 画面上の位置 → 左
• 起動済みのアプリケーションにインジケータ・ランプを表示 → オン

Dock の位置は左側で。以前は右側に置いていましたが、最近はメインスクリーンが左側にくる傾向が強いので、Dock は左側に配置しています。

Mission Control

• Dashboard を操作スペースとして表示 → オフ
• 最新の使用状況に基づいて操作スペースを自動的に並べ替える → オフ

Dashboard はあまり使わないので、そのためのスペースは必要ありません。

デスクトップからフルスクリーンに切り替えたときに、そのフルスクリーンが該当するデスクトップの右に来るような動作になっている感じですが、順番がころころ変わってむしろ鬱陶しいので「デスクトップは左・フルスクリーンは右」に固定。

本来はドラッグで自在に順番を変えられるべきだと思うのですが、どうなんでしょうね。

トラックパッド

• タップでクリック → オン
• スクロール方向：ナチュラル → オン
• ページ間をスワイプ → オン：2 本指で左右にスクロール
• フルスクリーンアプリケーション間をスワイプ → オン：3 本指で左右にスワイプ
• Mission Control → オン：3 本指で上にスワイプ
• アプリケーション Expose → オン：3 本指で下にスワイプ
• Launchpad → オン：親指と 3 本指でピンチ
• デスクトップを表示 → オフ

話題になっているスクロール方向は「ナチュラル」で。他の Snow Leopard / Windows XP / Windows 7 の環境も全てナチュラル準拠の方向に統一しました。

本当はトラックパッドのみ「ナチュラル」で、マウスのホイールはスクロールバーを操作するという形で設定したいのですが……。

Snow Leopard では Scroll Reverser で、Windows では AutoHotKey で。Windows ではトラックパッドのドライバによって「ナチュラル」と同じ方向に設定できる場合もあります。少なくとも、Synaptics のドライバソフトウェアでは可能でした。

「ページ間をスワイプ」は Mac OS X の標準設定に従っています。あとで触れますが、デフォルトブラウザを Safari にしたので、この設定でも特に問題ありません。

ユニバーサルアクセス

• マウスとトラックパッド / トラックパッドオプション / ドラッグ → オン：ドラッグロックなし

タップでクリックをオンにしたので、ドラッグ操作を行うためにこのオプションを設定。

「3 本指でドラッグ」というオプションが「トラックパッド」の方にありますが、これをオンにすると、Misson Control の操作に 4 本指を使わなくちゃいけなくなってしまって、少し億劫に感じたので、「3 本指でドラッグ」を使わずにこちらのドラッグオプションを有効にしています。

FloatyMemo ならびに FloatyMemo+ ver 1.07 をリリースしました。

今回のバージョンアップでは、何人かの方々いただいた「メモの自動リサイズ」を実装してみました。サイズ計算が完璧ではないので、オートリサイズをオンにしていても、メモの一部が隠れてしまう場合もあるかもしれません。

見た目には関係ないところで、ほぼ全面的にリファクタリングをしていたりするのですが、またそれは別のお話。

Xcode 4 の導入と Xcode 3 との併用 と触れたように、Xcode 4 と Xcode 3 を併用していますが、未だにメインの開発環境は Xcode 3 です。

今月、Mac OS X Lion と iOS5 の発表とともに iOS5 beta ならびにその SDK が Xcode 4.2 beta が開発者向けにリリースされました。

iOS5 での動作チェックなどを行うべく、早速 Xcode 4.2 beta をインストールしましたが、当初以下のような構成にしていました。

/Developer

Xcode 4.2 (Xcode 4.0 からのアップデートで標準インストール)

/Xcode3

Xcode 3 はそのまま。

今回のバージョンアップのコーディングやテストは、主に Xcode 3 を使って行いましたが、この構成だと最後の AppStore への申請部分の手続きで、問題が発生 しました。

AppStore の申請では、作成したバイナリファイルをアップロードするのですが、これが

There is no codesign_wrapper executable. Please reinstall the Xcode developer tools.

のようなエラー表示でアップロードできませんでした。

調べてみると、Xcode 4.2 はベータ版でコードサインが正しく行えない様子。Xcode 4.2 を Xcode 4 に上書きインストールしてしまったことにより、正規にコードサインできるツールがない状態になってしまっているようでした。

解決する方法は……

1. Xcode 4.2 をアンインストール
2. Xcode 4.0.2 を再インストール
3. Xcode 4.2 を上書きしないインストール

単にコードサインできる状態にするだけなら、Xcode 4.2 をアンインストールした後で、Xcode 4.0.2 を再インストールすればいんですが、iOS5 の環境も構築しておきたかったので、Xcode 4.2 を再インストールすることにしました。

Xcode のアンインストールは /Developer/Library の中にあるアンインストールスクリプトを通して行う必要があります。手動でインストール先ディレクトリを丸ごと削除してもシステムツールはそのまま残ってしまうので、注意が必要です。

Xcode 4.2 の再インストールでは Xcode 4.0.2 とは、別のインストール場所を指定するのももちろんですが、「System Tools」「UNIX Development」をインストールしないようにしておきます。

結果、現在の環境は以下のように……

/Developer

Xcode 4.0.2 / システムツールなどは正規版である Xcode 4.0.2 のものを使用

/XcodeBeta

Xcode 4.2 beta / iOS5 beta SDK

/Xcode3

Xcode 3

Xcode 4.2 が正規リリースされたら、XcodeBeta は削除予定……。Xcode 3 は分かりません。Xcode 3 は iOS5 をサポートしない感じがするので、いずれ使わなくなるとは思うのですが……。

Xcode 4 がリリースされました。

ユーザーインタフェースが刷新され、iTunes に近いインタフェースになりました。

特にバージョン管理に対しては

• svn だけでなく、git にも対応
• バージョンエディタ (Version Editor) によるリアルタイム差分表示。差分表示中に編集可能
• タイムマシン風 (?) の履歴表示

のような大幅な機能強化があります。

Xcode 4 のバージョンエディタモードは、File Merge に似たような差分表示ですが、File Merge とは異なり、最新ファイルは直接編集できます。画面下部の「時計」アイコンをクリックすると、タイムマシン風のスライダインタフェースが表示され、履歴の内容を確認できます。

Xcode 4 で変わったところ

前述の通り、ユーザーインタフェースは大幅に刷新されました。動作が微妙に変わったところもあって、慣れるまでは戸惑うかもしれません。

例えば、Xcode 3 では「Build」メニューにあった「Build & Debug (Command + Y)」に直接該当する動作は Xcode 4 にはなく、「Product」メニューの「Run (Command + R)」でプログラムを動作させ、ブレイクポイントの On/Off を「Product→Debug」メニューの「Activate/Deactivate Breakpoints (Command + Y)」で切り替えるような動作になりました。

キーバインド (キーボードショートカット) のデフォルト設定も変更されています。ほとんどのキーバインドはカスタマイズできるとは言え、デフォルト設定で Xcode 3 を使い込んでいる人には微妙にストレスの貯まる要因になるかもしれません。

例えば、私がよく利用するキーボードショートカットをいくつか取り上げると……

操作	Xcode 3	Xcode 4
ソースファイルと対応するヘッダファイルの切替	Command + Shift + ↑	Command + Control + ↑
エディタの履歴 (戻る・進む)	Command + Shift + ← / →	Command + Control + ← / →
オーガナイザーを開く	Command + Control + O	Command + Shift + 2

Xcode 3 ではプロジェクトのビルドターゲットを「Overview」ドロップダウンメニューで選択する形式でした。Xcode 4 では Overview の代わりに「Scheme」という概念が導入されています。

「Overview」ではビルドタイプ (Release, Debug, Distribution, etc)、デバイス (Simulator, Device)、ターゲット、実行環境、CPU アーキテクチャを個別に指定する必要がありました。

「Scheme」ではそれらの組み合わせをショートカットとして予め登録しておくような形で管理します。「Product」メニューで実行するコマンドに応じて、ビルドタイプを指定することができ、基本的には Release ビルド・Debug ビルドなどを意識する必要がないというコンセプトになっています。

Xcode 4 ではソースコードの編集中にリアルタイムでコンパイルが行われるのも大きな特徴です。

ソースコード単体の「Compile」コマンドはなくなりました。標準の設定では、ソースコードの編集時に適時コンパイルが行われ、エラー表示・警告表示もほぼリアルタイムで行われます。

当初、これを止める設定がないと思い込んでいましたが、Preferences → General → Enable Live Issues で止めることができます。私はとりあえず止めて利用するようにしています。

File → Project Settings → Build にも同様の設定があります。念のため、双方オフにしています。

iTunes に似たインタフェースと先にも触れましたが、基本的にはひとつのウィンドウで全てを処理するような感じになっています。Interface Builder や Property Editor, File Merge などを統合したインタフェースになっていて、そのせいか画面スペースを Xcode 3 よりも占有します。

私は初代 MacBook を使っていますが、13 インチ 1280 x 800 の解像度ではかなり手狭に感じます。最近は外部モニタ (1280 x 1024) も使っていますが、やはり少し大きい画面が欲しくなります。

という訳で Xcode 4 をとりあえず導入はしてみましたが、しばらくは Xcode 3 と併用する方向で開発を行うようにしました。幸い Xcode は異なるバージョンを複数インストールして、それぞれを共存させることができるよう考えられています。

Xcode 3 と併用する

私の環境では、標準の Xcode パスである /Developer/ には Xcode 4 を、Xcode 3 は /Xcode3/ というディレクトリを作成して、そちらにインストールするようにしました。基本的には徐々に Xcode 4 に移行する前提で、緊急を要するときなどは慣れた Xcode 3 で作業するような感じにするようにしています。

ただ、初代 MacBook にメモリ 2GB という貧弱な環境では Xcode 4 はやはり重く、気がつくと Xcode 3 でばかり開発作業していたりしますが……。

まず、Xcode 3 をインストールするディレクトリをルートディレクトリ上に作成します。ルートディレクトリ上なので、管理者権限が必要です。

sudo mkdir /Xcode3

Apple Developer サイトからダウンロードした xcode_3.2.6_and_ios_sdk_4.3__final.dmg を展開し、インストーラを立ち上げます。

インストール先として先ほど作成した「Xcode3」を選択します。標準では「場所」が「Developer」になっていますが、これをクリックして「Xcode3」に変更します。

この時、以下のパッケージのチェックボックスを外しておきます。

• System Tools
• UNIX Development
• Documentation
• Mac OS X 10.4 SDK

つまり、「Essentials」だけインストールする格好になります。私の場合、すでに Xcode 4 をインストール済みで、これらはすでに必要な場所にインストールされています。おそらくバージョンチェックによって上書きはされない思うのですが、念のため外しておきました。

あとは通常通りのインストールです。インストール終了後、/Xcode3/Applications/ の中を確認しておきます。

以前、Xcode 3 のアップグレードで肝心の Xcode アプリケーション本体がインストールされなかったという経験があるので、念のため確認する癖が……。そのときはおそらく Xcode がきちんと終了されていなかったのではないかと思っているのですが……。

このままだと、Xcode 4 と Xcode 3 のアイコンが同一で、区別が付きません。Xcode 3 をきちんと区別するためにアイコンを適当に自作して、入れ替えておきました。

もし欲しい方がいらっしゃいましたら、自作アイコンをダウンロード (313KB) してください。

解凍した「appicon.icns」ファイルを Xcode 3 のパッケージ内にある同一ファイル名と差し替えます。

Xcode 4 と Xcode 3 は同時に立ち上げることが可能ですが、同じプロジェクトファイルを開くのはやめておいた方が無難です。プロジェクトファイルが破損する可能性があります。……私の場合、ファイルの破損はしませんでしたが、挙動不審になったことがあり、以来同一プロジェクトを同時に開くことはしないようにしています。

そもそも Xcode 4 が重いので、基本的にはどちらか一方の Xcode のみを立ち上げるというスタンスにしています。

先日リリースした FloatyMemo / FlatyMemo+ ver 1.01 において、iOS 3.2 でアプリケーションが立ち上がらないという不具合が見つかりました。

ver 1.01 では新たに「ふい字 P」というフォントを追加したのですが、これが原因でアプリケーションがクラッシュします。iOS 3.2 のみで発生し、iOS 4.0 以降がインストールされた iPhone / iPod touch / iPad では、正しく動作します。

フォントが原因なので、これを取り除けば (新規追加したフォントが利用できないという点を除いて) アプリケーションが動作するようになります。

「既知の不具合とその対処法」のページでも触れていますが、iPhone Explorer というアプリケーションを利用して、不具合の要因を取り除く方法で対処できると思います。

1. iPhone Explorer をお使いの PC にインストールします。
2. お使いの iPad と PC をつなげます。
3. インストールした iPhone Explorer を立ち上げます。
4. 以下のディレクトリをチェックします (スクリーンショットを参考にしてください)
   FloatyMemo
   iPad -> Apps -> FloatyMemo -> FloatyMemo.app
   FloatyMemo+
   iPad -> Apps -> FloatyMemoPlus -> FloatyMemoPlus.app
5. HuiFontP29.ttf を削除します。

6. フォントを削除したあと、FloatyMemo / FloatyMemo+ が正しく立ち上がることを確認します。

新しく追加したフォント「ふい字 P」は、トゥルータイプフォント (ttf) です。別の ttf フォントで確認もしましたが、iOS 3.2 で ttf を読み込むと必ず落ちるという訳ではないようで、特定のフォントでのみ発生する様子。

確実に特定したわけではありませんが、ひとつ要因っぽいのは、ttf フォント内で設定されているフォント名です。どうも ttf フォントの場合、フォント名に日本語が利用されているとダメなのかもしれません (単に互換性の問題かもしれません)。

という訳で、iOS でフォントをロードする際は注意が必要というお話でした。

FloatyMemo / FlatyMemo+ ver 1.01 が公開されました。

いくつか変更点がありますが、FloatyMemo / FloatyMemo+ 双方で「クイック編集」を実装したこと、FloatyMemo+ で「マルチページ」に対応したことが最も大きな変化です。

FloatyMemo / FloatyMemo+ での多かった意見の一つに「メモを編集するときのアニメーションが鬱陶しい」というのがありました。

iPad や若干古めの機種でそのように感じるようで、アニメーションをオン・オフをできる設定を追加しました (iPad ではデフォルトでアニメーションしない設定になります)。

これとは別のアプローチで、編集時のストレスを軽減する方法として「クイック編集」を追加しています。

クイック編集は、編集画面に移行せずにその場でキーボードを表示して、メモの編集ができるモードです。

クイック編集中は、フォントやカラーの変更はできませんが、メモのリサイズや位置の移動は可能です。画面の移行アニメーションも別画面を開くタイプよりもスムーズです。

技術的には、通常の編集画面と実装的には大きな変化はありません。

ただ、編集対象となるメモの画面上の位置やサイズはバラバラなので、キーボードのせり上がり処理に関しては若干工夫しています。

メモの下限位置がキーボードのせり上がった位置と重なるようだったら、メイン画面の位置をその分上げるという感じの処理を行っています。

メモの上限位置は考慮していないため、メモによっては隠れてしまう場合もあります。当初、クイック編集中はリサイズは行えないようにするつもりでしたが、隠れてしまった場合のことを考えて、クイック編集中でもリサイズや位置の変更は可能なようにしています。

キーボードのせり上がりに合わせて行うメイン画面の位置調整は、view.frame をいじって行うつもりだったのですが、何故だか横画面で view.frame で正しい値を返してくれないため、view.bounds を利用するようにしています。

先月リリースした FloatyMemo ならびに FlatyMemo+ は ATOK Pad との連携機能があります。

ATOK Pad がインストールされた環境では、メモの編集画面ツールバーにあるアクションボタン (矢印ボタン) を押したときに「ATOK Pad を開く」オプションが追加されます。

ATOK Pad の仕様制限として、ATOK Pad で編集を行った跡は必ず「戻る」ボタンで FloatyMemo / FloatyMemo+ に戻る必要があります。ホーム画面を開いたり、アプリケーションスイッチで FloatyMemo / FloatyMemo+ に戻っても正しく編集結果が反映されません。

さらに FloatyMemo / FloatyMemo+ の設定画面にて「ATOK Pad 連携強化」をオンにすると、メモの編集には必ず ATOK Pad を利用するようになります。

メイン画面から編集画面を開いたときはもちろん、編集画面でテキストをタップしただけで ATOK Pad が開きます。

副作用として通常のキーボードでメモの編集はできないということになります (FloatyMemo+ でサポートしている検索などの入力では ATOK Pad は開かれません)。

「ATOK Pad 連携強化」をオンにした場合、FloatyMemo の編集画面は、フォントやカラー設定などを行う以外には、基本的に閲覧専用のような形で動作するようになります。

三年以上前にまとめた「Mac OS X上で動作するウェブブラウザのまとめ」は、何故だか SimpleBoxes で一番人気の記事ですが、内容はやはり古くなっています。

単に件の記事を最新情報に沿うように更新するというのでもいいのですが、今では「Macブラウザおすすめ比較フリーソフト」のようなまとめサイトもありますし、個人的にもそれではあまり面白くないので、今回は「タブ型ウェブブラウザ」という視点でまとめてみようと思います。

タブ型ウェブブラウザは「タブブラウザ」とも呼ばれますが、複数のウィンドウを「タブ」としてまとめて表示するユーザーインタフェースを備えたブラウザです。

個人的には Windows の MDI (マルチドキュメントインタフェース) の派生だと認識しているのですが、起源はよく分かりません。

Mac OS X のタブブラウザは、その表現方法により大まかに四つに分かれるようです。

• Safari 系 …… 上向きタブインタフェース
• Camino 系 …… 下向きタブインタフェース
• Opera 系 …… Tab on Top インタフェース
• OmniWeb 系 …… サムネイルを利用するインタフェース

Safari 系 [上向きタブインタフェース]

Mac OS X の標準ブラウザとも呼べる Safari では、上から

• ウィンドウタイトルバー
• アドレス・検索バー
• タブバー (上向き)
• ウェブコンテンツ

の順で並んでいます。現行の Firefox も同様のインタフェースで、今回 Camino 系は別系統に分類しましたが、動作的にはほぼ同一であるため、事実上最も標準的なタブ型インタフェースと言えるでしょう。

タブが上向きで、タブがウェブコンテンツと関連してそれを切り替えるものと機能するという観点から見ると、やや直観的ではないのかもしれません。見た目はすっきりしていています。

Safari

言わずと知れた Apple 純正のブラウザです (WebKit ベース)。

2010 年 6 月にリリースされた Safari 5 では、Safari リーダー・機能拡張への対応といった新機能が搭載されました。

Safari リーダーは、本文に当たる部分だけを抜き出して大きく表示する機能です。面白い機能だとは思いますが、マークアップや class 要素などの内容で本文だと思しき部分を抽出するので、記事によってはうまく表示されません。例えば、「localizer.js - JavaScript で多言語対応を考える」など。

機能拡張は Google Chrome のそれと構成が似ているようで、案外出揃ってくるが早いかもしれません。HTML5 への対応も早く、Apple 純正だけあって、安定感はあるような気がします。

Firefox 3.*

Firefox は Gecko 系ブラウザの代表とも言うべきブラウザです。

Firefox は激しいパフォーマンス競争を繰り広げている Safari や Chrome などと比較すると、やや動作は重めですが、メモリ消費量などは比較的抑えめだったりする利点があります。

豊富な機能拡張やマルチプラットフォームでの安定感のある動作などはやはり一日の長がある印象があります。

ここでは Safari 系タブインタフェースとして Firefox 3.* を分類していますが、機能拡張により様々なタブインタフェースを実現しているのも Firefox のひとつの特徴と言えます。Firefox 4.* で標準採用となる予定の Tab on Top も機能拡張により実現できるようです。

シイラ 1.*

シイラ 1.* はタブエクポーズなど独自な機能拡張を施した WebKit ベースのタブブラウザです。HMDTの木下誠さんにより開発されています。

インタフェースはすっきりとまとめられ、動作はきびきびしている印象があります。

ブックマークや履歴などの表示するサイドバー (ドロワー) がなかなか便利だと思いますが、いかがでしょうか。ドロワーというインタフェースは最近 Apple があまり積極的に採用していない印象がありますけれども。

Cruz

Twitter との連携機能のある WebKit ベースのブラウザです。「クルーズ」と発音するのでいいのかな。

アバウト画面にシイラの表記があるので、もしかしたらシイラの派生ブラウザなのかもしれません。

GreaseKit を取り込んでいるようで、UserScript による機能拡張を標準でサポートしている様子。UserStyles を管理する設定画面などもあり、サイト毎にカスタマイズする機能は充実している印象を受けます。

プラグインと呼ばれる独自の機能拡張を利用すると、表示ペインを増やすことができます。追加したペインはアクティブなタブによらず常に表示されます。Twitter との連携機能もプラグインという形で実装されています。

Sunrise

WebKit ベースのタブブラウザです。

シンプルな設定画面とグラフィカルなブックマークが印象的なブラウザです。履歴やユーザーエージェント切替時の表示はフリップアニメーションして中々凝っています。シンプルな分飽きづらいかもしれません。

Camino 系 [下向きタブインタフェース]

Geckeo 系ブラウザである Camino で採用されているタブインタフェースで、上から

• ウィンドウタイトルバー
• アドレス・検索バー
• タブバー (下向き)
• ウェブコンテンツ

の順で並んでいます。タブの向き以外は Safari 系と同等です。

タブが下向きなので、ウェブコンテンツを切り替える役目がはっきりとします。

ただし、ウェブコンテンツとタブの色がマッチしない場面が多いため、SeaMonkey 以外のブラウザでは、(不自然にならないように) タブとウェブコンテンツを分ける仕切りのようなラインが置かれています。

Camino

HTMLレンダリングエンジンに Gecko を採用しながら、GUI フロントエンドに Cocoa を使った Mac OS X 独自のブラウザです。

印象としては Firefox と Safari の間の子。ブックマークのインタフェースなど Safari の雰囲気を感じます。

Gecko 系の特徴であるアドオンが利用できないという欠点がありますが、その分、軽快に動作しますし、広告非表示など独自に拡張された機能もあります。

SeaMonkey

「Mozilla Application Suite」と呼ばれるメーラーなども含めた統合アプリケーションです (Gecko ベース)。

ウェブブラウザ、メーラー、HTML エディタ、IRC チャットクライアントが統合されています。その分やや重めのアプリケーションになっています。

Flock

ソーシャルブラウザというコンセプトを持つブラウザです。

普通にブラウザとしても利用できますが、特徴的なのはブログ投稿クライアントや flickr との連携機能などがあります。

Windows 版は Chrome ベース (WebKit ベース) になったようですが、Mac OS X 版は 2010.11 現在まだ Gecko ベースです。

iCab

iCab は少し前まで独自のレンダリングエンジンを利用したブラウザでしたが、最新版では WebKit ベースのブラウザになっています。

iCab はエラーリポート・ページ外観などの機能を見てもらうと分かるとおり、HTML の規格を意識した作りになっていたりします。

今でもクラシックな MacOS 向けバージョンを配布していたりしていて、WebKit ベースとなった今でもインタフェース的には独特な雰囲気のあるブラウザに仕上がっているような印象です。

Opera 系 [Tab on Top インタフェース]

Opera では、上から

• ウィンドウタイトルバー
• タブバー (下向き)
• アドレス・検索バー
• ウェブコンテンツ

の順に並んでいます。アドレスバーがタブバーの下に来るのが特徴で「Tab on Top」とも呼ばれるインタフェースになります。

Opera の場合、ブックマークバー (パーソナルバー) はタブの上に配置されるようなので、いわゆる「Tab on Top」とは異なるかもしれません。

アドレスバーはウェブコンテンツのアドレスを表示し、基本的にウェブコンテンツと共に表示の変化があるという点からすると、直観的な位置と言えるかもしれません。

現在ベータ版の Firefox 4 でも Opera と同等なインタフェースを採用しています。

Opera

最速ブラウザを標榜しているブラウザで、独自のレンダリングエンジン Presto を採用しているブラウザです。

Opera のインタフェースはやや独自色が強い印象があります。SeaMonkey と同様、ウェブブラウザだけでなく、メーラーやチャットクライアント機能もあるいわゆる統合ソフトウェアです。そのためか、設定項目が多くカスタマイズ性に富みます (反面、ごちゃごちゃした印象を受けてしまうのは仕方ないところでしょうか)。

ver 11 からは Safari / Google Chrome と同様、機能拡張をサポートすることを表明しています。

ここでは Opera を Tab on Top インタフェースの代表格として挙げていますが、タブバーより上部に位置する「メインバー」をカスタマイズすることにより、Camino 系と同等なインタフェースにすることも案外簡単にできてしまいます。

また、Opera ver 10 では、アクティブでないタブにマウスカーソルを当てるとそのタブのウェブコンテンツをサムネイル表示も行ないます。

Google Chrome

Google Chrome は WebKit をベースとして独自の JavaScript エンジンを採用したブラウザです。

タブ毎にプロセスを発生させるのが特徴で、高速性・安定性の向上に繋がっているようです。

タブのインタフェースとしては、Opera に近く、

• タブバー (下向き)
• アドレス・検索バー
• ウェブコンテンツ

のように並んでいて、タブバーがウィンドウタイトルバーの領域に入り込むような形になっているのが最大の特徴です。現在、このタイプのタブインタフェースを採用しているのは Google Chrome のみですが、Safari でも ver 4 のベータ版で同様なインタフェースを実験的に採用したことがあります。

Safari 4 beta でのタブインタフェースは見た目 Google Chrome に似た感じですが、動作は微妙に異なるものでした。例えば、タブのドラッグはタブ位置の変更ではなく、ウィンドウをドラッグしたような感じでウィンドウの画面上の位置を変更するように動作したり。結局、正式版では採用されず今に至ります。

長いタイトルが完全に表示されないなどの欠点はありますが、タイトルバーを削った分、ウェブコンテンツの表示領域が広がるのが利点になります。

Firefox 4.*

Firefox は ver 4 から Tab on Top インタフェースを採用します。2010.11 現在、ベータ版が公開中です。

インタフェースの刷新以外にも HTML5 対応、パフォーマンスの大幅な向上などメジャーバージョアップにふさわしい内容になるようです。

残念ながら 2010 年中の正式版リリースは見送られてしまいましたが、2011 年始めにはリリースされるとのこと。

Stainless

Stainless は WebKit ベースブラウザで、Google Chrome 同様タブ毎にプロセスを生成します。

タブ毎プロセス以外にもセッション復帰やブックマークシェルフなど Safari にはない機能がいくつかありますが、基本的には機能をそぎ落として、とてもシンプルに仕上げられていて、動作が非常に軽快です。

OmniWeb 系 [サムネイル表示]

タブペイン (あるいはドロワー) にウェブコンテンツのサムネイルを利用します。

画像を表示することになるので、他のタブブラウザでは「タブバー」に当たる部分が必然的に大きな面積を取るようになり、タブバーというより「タブペイン」といった趣になります。

タブを切り替える前に大体の内容が把握できるという利点があります。

OmniWeb

OmniWeb は WebKit をベースとしたブラウザです。長いことシェアウェアでしたが、最新版ではフリーウェアになっています。

OmniWeb はタブブラウザですが、いわゆる「タブバー」がありません。「タブを表示」を選ぶと、タブドロワーが表示されます。タブはサムネイルもしくはリストで表示され、リスト表示するといわゆる縦型タブのようなインタフェースになります。

性質上横幅をとる形式になりますが、ワイド画面の機種が多い Mac とは、相性が良いのかもしれません。

シイラ 2.*

シイラ 2.* はシイラ 1.* の後継として開発された WebKit ベースのブラウザです。

PageDock と呼ばれるインタフェースを採用しています。

• ウィンドウタイトルバー
• アドレス・検索バー
• ウェブコンテンツ
• PageDock

の順に並び、タブにあたる PageDock には表示中のウェブコンテンツがサムネイル表示されます。

シイラ 2 では、サムネイル表示で場所を占有がちな欠点を逆に活かして、読み込みプログレス表示に利用したりしています。

まとめ

ブラウザ	バージョン	エンジン	セッション 復帰	タブバー ダブルクリック	ステータス バー	アドレス・検索 バー統合
Safari	5.0.2	WebKit	要 SafariStand	新規タブ	○	要 SafariStand (キーワード)
Firefox	3.6.12	Gecko	○	新規タブ	○	○ (キーワード利用可)
シイラ	1.2.3	WebKit	×	何も起きない	○	×
Cruz	0.4	WebKit	○	新規タブ	○	×
Sunrise	2.1.5	WebKit	×	何も起きない	×	○
Camino	2.0.5	Gecko	○	新規タブ	○	キーワード利用
SeaMonkey	2.0.8	Gecko	○	新規タブ	○	キーワード利用
Flock	2.6.1	Gecko	○	新規タブ	○	キーワード利用
iCab	4.8.0	WebKit	○	新規タブ	○	キーワード利用
Opera	10.63	Presto	○	新規タブ	○	○ (キーワード利用可)
Firefox	4.0b6	Gecko	○	新規タブ	○	○ (キーワード利用可)
Stainless	0.7.5	WebKit	○	何も起きない	○	○ (キーワード未対応)
Chrome	6.0.472.63	WebKit	○	ウィンドウしまう	ポップアップ	○ (キーワード利用可)
OmniWeb	5.10.1	WebKit	×	何も起きない	○	×
シイラ	2.3	WebKit	○	何も起きない	○	×