眠れぬ夜のために

既存のものと同名のネームスペースを addNamespace すると、Snow Leopard 環境で Segmentation fault になる

2012-01-29T13:03:00.000+09:00

NSXMLElement の addNamespace メソッドにおいて、レシーヴァがすでに同名のネームスペースを持っている場合、かつ Snow Leopard な環境で実行すると Segmentation fault で落ちる。

　以下のような HTML があるとする。　html 要素に epub という名前のネームスペースを持っている。

　次に、この HTML を読み込んで処理を行う以下のようなコードがあるとする。　test.html にはすでに epub というネームスペースを持っているが、そこにさらに同名のネームスペースを追加する処理を行う。このコードは Lion では正常に動作するが、Snow Leopard で実行すると addNamespace: の部分で Segmentation fault で落ちる。

　addNamespace: のドキュメントによると、

If the receiver already has a namespace with the same name, aNamespace is not added.

とのことで「レシーヴァがすでに同名のものを持っている場合はネームスペースは追加されない」、つまり何もしないということだと思うんだが、そして Lion ではそのようになっているんだが、Snow Leopard では Segmentation fault で落ちる。うーん……。

　したがって、Snow Leopard で実行される場合は addNamespace: する前に同名のネームスペースがあるかどうかをチェックしておく必要がある。ある名前を持つネームスペースがあるかどうかは namespaceForPrefix: メソッドで調べることができる。

Cocoa テキストシステムのキィバインドをさらに Emacs に近づける

2011-12-31T13:34:00.001+09:00

本ブログのエントリィ「眠れぬ夜のために: KeyBindingsEditor」の六年ぶりの続編。

　上記エントリィの繰り返しになるけど、Mac OS X の Cocoa フレームワークを用いて作られたアプリケーションのテキストフィールドは、ディフォルトで Emacs 風なキィバインドが割り当てられている。たとえば Control + p/n/f/b/a/e によるカーソル移動や Control + d/h によるカーソル前後の文字削除、Control + k/y による kill-line と yank など。
　Emacs 風のキィバインドに慣れたユーザであれば、両手をキィボードのホームポジションに置いたままで様々な操作ができるけん、テキスト編集のスピードが上がる。みんな覚えよう！

　ほなけど、ディフォルトの割り当てだけではまだまだ Emacs でよく使う操作には足りない。今回は Cocoa テキストシステムのキィバインドをさらに Emacs に近づけることを考える。

　今回は以下の操作をキィバインドに割り当てる。

set-mark
newline
newline-and-indent
kill-region
kill-ring-save

　キィバインドの割り当てには前回のエントリィと同じ KeyBindingsEditor を用いる。

KeyBindingsEditor を立ち上げる
メニューバーから File -> Open -> User Key Bindings を選択してユーザのキィバインド定義ファイルを開く
Add Binding ボタン（2 ストローク以上のキィバインドの場合は Add Multikey binding ボタン）を押してキィバインドを追加する
追加したキィバインドを選択して、ウィンドウ下部の Keystroke 欄をクリックし、好みのキィバインドをタイプする
Actions 欄でキィバインドに割り当てる操作を選択する。ひとつのキィバインドにふたつ以上の操作を割り当てたい場合は Add Action ボタンを押してアクションを増やす
3 - 5 を必要なだけ繰り返す

　KeyBindingsEditor でキィバインドを割り当てた結果が以下の画像のようになる。

　画像中で Action 欄が ( となっているのはふたつ以上のアクションを割り当てたもの。具体的には Control + j には insertNewline: と indent:、Control + [ に続く 2 ストローク目の Control + w には deleteToMark: と yank: が割り当てられている。

　今回の KeyBindingsEditor での割り当てで kill-ring-save に対応するキィバインドは Control + [、Control + w とした。Emacs において kill-ring-save に対応するキィバインドは M-w であり、ふだん私が Emacs でこの操作を行う場合は Meta を C-[ で代用してから 2 ストローク目で w を単独で押す。本来であれば KeyBindingsEditor での割り当ても 2 ストローク目は単独の w で構わない。ほなけど、日本語入力が ON になっている状態で 2 ストローク目の w を押すと、その入力が IM に取られて割り当てた操作が実行されない（日本語入力が OFF の場合は単独の wで動作する）。Control を修飾すると日本語入力が ON の状態でも動作するので、今回のようにしている。

　これで 一般的なCocoa アプリケーションのテキストフィールドにて割り当てた操作を実行できる（Cocoa アプリケーションではなかったり、テキストフィールドを独自実装しているような場合は実行できない。たとえば Google Chrome なんかは動作が怪しい）。たとえば Control + Space でマークし、カーソルを動かして Control + w すると、マークした箇所からカーソル位置までの文字を削除して kill-ring に格納することができる。kill-ring の内容は Control + y で yank。つまり、ホームポジションのままでカットアンドペーストができることになる。
　割り当て変更後にはアプリケーションの終了、再実行が必要となる。

　ここで、kill-ring の内容と Mac OS X 標準のペーストボードの内容とは関係がないことに注意。コンテキストメニューや Command + c/x からコピィ・カットした文字を Control + y で yank することはできないし、上述の Control + w で kill-ring に格納した文字を Command + v でペーストすることはできない。それぞれが独立して動作する。

Mac アプリケーションの環境設定ウィンドウを作る

2011-12-20T05:21:00.001+09:00

環境設定ウィンドウについて

　Mac アプリケーションの動作等を設定するときに用いる環境設定ウィンドウを作る。

　環境設定ウィンドウの特徴は、

クラスは NSPanel （非 NSWindow）
これはエスケープキィを押したときにウィンドウが閉じられることから
ツールバーを持ち、そのツールバーアイテムをクリックすることでウィンドウのヴュウを切り替える
ヴュウを切り替える際にウィンドウの大きさがアニメーションを伴って変化する

　ここでは、上記のような環境設定ウィンドウの、ウィンドウとしてのふるまいを実装していく。実際にアプリケーションの設定をする方法は別論（NSUserDefaults 等を用いる）。

　今回作成したプロジェクトは GenjiApp/PrefWindowApp - GitHub で公開するので参照のこと。

Xcode プロジェクトの作成

　Xcode を起動し、New Project... から Mac OS X Application の Cocoa Application を選択する。ここでは Project Name を PrefWindowApp とし、適当な場所にプロジェクトを作成する。

ウィンドウコントローラの追加

　プロジェクトに環境設定ウィンドウを管理する新しいファイルを追加する。New File... から Objective-C class を選択し、NSWindowController のサブクラスを作成する。名前は PreferencesWindowController とした。
　今回の環境設定ウィンドウはふたつのヴュウを切り替えて操作するものとする。
　それぞれのヴュウを判別するための tag に用いる定数を列挙型で宣言しておく。

typedef enum {
  PreferencesViewGeneral = 100,
  PreferencesViewAdvanced,
} PreferencesViewType;

　さらに、それぞれのヴュウと接続するメンバ変数として、ふたつの NSView クラスの変数を宣言する。

@interface PreferencesWindowController : NSWindowController
{
  IBOutlet NSView *generalView_;
  IBOutlet NSView *advancedView_;
}

　最後に、ヴュウを切り替えるアクションメソッドを宣言する。

- (IBAction)switchView:(id)sender;

　実装部は後回しにして、次に xib ファイルを編集する。

環境設定ウィンドウの xib ファイルを編集する

　MainMenu.xib ファイルを開く。
　Object Libaray から Object（NSObject）をドラッグしてトップレヴェルに追加する。オブジェクトの Identity Inspector で Class を先ほど作成した PreferencesWindowController に設定する。MainMenu の Preferences... メニューアイテムから PreferencesWindowController へ Control + ドラッグして showWindow: と接続する。

　Object Library から Panel（NSPanel）をキャンバスにドラッグして追加する。パネルの Attribute Inspector で以下の設定を行う。

Style を Regular Panel に変更
Controls の Resize と Minimize からチェックを外す
Behavior の Hide on Deactivate と Visible At Launch からチェックを外す

　次に PreferencesWindowController からパネルへ Control + ドラッグして window と接続する。

　Object Library からToolbar（NSToolbar）をパネルにドラッグして追加する。ツールバーの Attribute Inspector で Customizable からチェックを外す。
　ツールバーの Allowed Toolbar Items からすべてのツールバーアイテムを削除し、代わりに Object Library から Image Toolbar Item（NSToolbarItem）をふたつドラッグして追加する。追加したふたつのツールバーアイテムをそれぞれ Default Toolbar Items 欄にドラッグする。ツールバーアイテムの Attribute Inspector より以下のように設定する。

Image Name をそれぞれ NSPreferencesGeneral、NSAdvanced に設定する
Label をそれぞれ General、Advanced に設定する
Palette Label をそれぞれ General、Advanced に設定する
Tag をそれぞれ 100、101 に設定する
この 100、101 は PreferencesWindowController.h で宣言した列挙型の値に合わせたもの
Behavior の Selectable にチェックを入れる

　それぞれのツールバーアイテムからトップレヴェルオブジェクトに追加した PreferencesWindowController へ Control + ドラッグして switchView: アクションと接続する。これでツールバーアイテムをクリックしたときに switchView: アクションが呼ばれるようになる。　

　次に Object Library から Custom View（NSView）をふたつ、キャンバスにドラッグしトップレヴェルに追加する（Panel への追加ではない）。このヴュウのサイズは適当に違う大きさにしておくと、あとで実装するヴュウ切り替えによるウィンドウサイズの変更が解りやすくなる。とりあえず、解りやすいように Label（NSTextField）でも追加して適当な文字列を入力しておく。
トップレヴェルオブジェクトの PreferencesWindowController からふたつのヴュウへ Control + ドラッグして、それぞれ generalView_、advancedView_ へ接続する。これで、PreferencesWindowController.m からふたつのヴュウを参照できるようになる。

環境設定ウィンドウのふるまいを実装する

　PreferencesWindowController.m を開き、以下のような switchView: メソッドを実装する。これは前述のツールバーアイテムをクリックしたときに呼ばれるアクションメソッドである。

- (IBAction)switchView:(id)sender
{
  NSWindow *window = [self window];
  NSView *contentView = [window contentView];

  NSArray *subviews = [contentView subviews];
  if([subviews count]) {
    NSView *currentView = [subviews objectAtIndex:0];
    [currentView removeFromSuperview];
  }

  NSToolbarItem *item = (NSToolbarItem *)sender;
  NSString *title = [item label];
  [window setTitle:title];

  NSView *newView = nil;
  switch([item tag]) {
    case PreferencesViewGeneral:
      newView = generalView_;
      break;
    case PreferencesViewAdvanced:
      newView = advancedView_;
      break;
    default:
      return;
  }

  NSRect windowFrame = [window frame];
  NSRect newWindowFrame = [window frameRectForContentRect:[newView frame]];
  newWindowFrame.origin.x = windowFrame.origin.x;
  newWindowFrame.origin.y = windowFrame.origin.y + windowFrame.size.height - newWindowFrame.size.height;
  [window setFrame:newWindowFrame display:YES animate:YES];

  [contentView addSubview:newView];
}

　ここで行なっていることは、

ウィンドウの contentView がサブヴュウを持っている場合はそれを取り除く
sender、つまりツールバーアイテムの label からウィンドウのタイトルを設定する
sender、つまりツールバーアイテムの tag から切り替え先となる新しいヴュウを判別する
ウィンドウと新しいヴュウの frame から、切り替え後のウィンドウの frame を計算する
計算したウィンドウの新しい frame をウィンドウにアニメーション付きで適用する
ウィンドウの contentView に新しいヴュウを追加する

である。
　ウィンドウの新しい frame について、Mac OS X の座標系は左下原点なので、contentView のサイズを変更しただけでは、ウィンドウの上端が動いてしまうことになる。したがって、ヴュウ切り替え前のウィンドウの上端座標を計算し、そこから切り替え後のウィンドウの高さを引くことで、ウィンドウの新しい原点座標を得る。

　最後に、以下のような awakeFromNib メソッドを追加する。

- (void)awakeFromNib
{
  NSWindow *window = [self window];
  NSToolbar *toolbar = [window toolbar];
  NSArray *toolbarItems = [toolbar items];
  NSToolbarItem *item = [toolbarItems objectAtIndex:0];

  [toolbar setSelectedItemIdentifier:[item itemIdentifier]];
  [self switchView:item];
  [window center];
}

　awakeFromNib メソッドは xib ファイルが読み込まれ、そこに登録されたオブジェクトにアウトレット接続がなされたあとで呼ばれる。ここでツールバーアイテムの初期選択状態や、最初に表示されるヴュウの設定を行う。今回はツールバーアイテムの一番最初のものを初期状態に設定するようにしたが、選択状態を適当な方法で保存しておき、次回起動時にその状態を復元しても良いかもしれない。

ビルドして実行

　以上により、環境設定ウィンドウが完成した。アプリケーションを実行し、アプリケーションメニューから Preferences... を選択して環境設定ウィンドウを表示してみる。ツールバーアイテムのクリックでヴュウが切り替わり、同時にウィンドウサイズの変更がアニメーションを伴って変更されることを確認する。

　今回作成したプロジェクトは GenjiApp/PrefWindowApp - GitHub で公開するので参照のこと。

Mac App Store に提出するアプリケーションに Spotlight/Quick Look プラグインを同梱する方法

2011-12-03T15:27:00.000+09:00

アプリケーションの Xcode プロジェクトと、Spotlight/Quick Look プラグインのプロジェクトがあるとする。

アプリケーションのプロジェクトを開いて、Project navigator にプラグインのプロジェクトをドラッグ・アンド・ドロップする
プラグインのプロジェクトの Build Settings にて Skip Install を Yes に設定する
アプリケーションのターゲットにて、Build Phases タブで Add Build Phase で Add Copy Files を選択して追加する。Copy Files の Destination には Wrapper、Subpath はそれぞれ Contents/Library/Spotlight、Contents/Library/QuickLook を指定する。コピィするファイルはそれぞれのターゲットを指定する

Build Phases にて Add Build Phases で Add Run Script を選択して追加し、以下のようなコマンドを入力する

codesign -v -s "${CODE_SIGN_IDENTITY}" ${CODESIGNING_FOLDER_PATH}/Contents/Library/Spotlight/EPUBImporter.mdimporter
codesign -v -s "${CODE_SIGN_IDENTITY}" ${CODESIGNING_FOLDER_PATH}/Contents/Library/QuickLook/EPUBQLGenerator.qlgenerator

署名は提出用だけでいいので、Run script only when installing にチェックを入れておく

Archive して完成

　手順 2 について、Skip Install を Yes にしておかないと、手順 5 でアプリケーションがうまくアーカイヴできない。
　手順 3 でアプリケーションパッケージ内に各プラグインを配置。
　手順 4 でプラグインに署名を行う。以前まではプラグインに署名せずとも大丈夫だったが、ちょっと前からプラグインにも署名をしないといけなくなった。

EPUB をフォルダ展開するサービスを Automator で作る

2011-11-28T23:18:00.001+09:00

EPUB ファイルは、その構成物を Zip でまとめたもんやけん、EPUB の内部構成等を確認したい場合は、Zip アーカイヴを展開すればよい。
　ふつうの Zip ファイルであれば拡張子が .zip であり、Finder からダブルクリックすれば関連付けられたアーカイヴ展開ツールが起動してフォルダ展開してくれるだろう。ほなけど EPUB ファイルは拡張子 .epub であり、ファイルをダブルクリックしたところで EPUB 閲覧アプリケーション等がインストールされていればそれが起動し、インストールされていなければどのアプリケーションを用いてファイルを開くかを尋ねてくるダイアログ等が表示されるだけ。
　ほなけん、EPUB ファイルを展開したい場合は、

あらかじめアーカイヴ展開ツールの GUI を起動させ、そこへ EPUB ファイルを読み込ませる
EPUB ファイルの拡張子を .zip に変更してからダブルクリックでアーカイヴ展開ツールを起動する
$ unzip <epubfile.epub> 等のコマンドライン操作を行う

等の手段を用いることになる。

　めんどくさい。
　いちいちこんなことをやるのはめんどくさいけん、Automator を使って EPUB をフォルダに展開するサービスを作る。

　Automator を起動し、新規作成のダイアログで「サービス」を選ぶ。「"サービス"は、次の選択項目を受け取ります」には「ファイルまたはフォルダ」を、「検索対象」には「Finder」を選択する。
　用いるアクションは「シェルスクリプトを実行」のみ。「シェル」には「/bin/bash」を選択して、以下のようなシェルスクリプトを入力する。

for filePath in "$@"
do
  workingDir=${filePath%/*}
  filename=${filePath##*/}
  extension=${filename##*.}
  filenameWithoutExtension=${filename%.*}
  cd "$workingDir"
  if [ $extension != epub ] ; then continue; fi
  if [ -e "$filenameWithoutExtension" ] ; then continue; fi
  mkdir "$filenameWithoutExtension"
  unzip "$filename" -d "$filenameWithoutExtension"
done

　これで完成。かんたんですね。

　保存すると ~/Library/Services に保存される。Finder から EPUB ファイルを選択してコンテキストメニュー（右クリック or Control + クリック）かアプリケーションメニューの「サービス」に保存した Automator ワークフローがあるけん、それを選択すればフォルダに展開してくれる。
　仕様は以下の通り。

EPUB ファイルがあるフォルダに EPUB ファイルと同名のフォルダを作り、そこに中身を展開する
- すでに同名のフォルダがある場合はなにもしない
拡張子 .epub 以外のファイルからこのサービスを呼び出してもなにもしない
複数の EPUB ファイルを一気に展開できる

MacBook Late 2008 の HDD を SSD に換装

2011-10-18T20:52:00.000+09:00

「MacBook Late 2008 のメモリィを 8GB に増設」でメモリィ増設した MacBook Late 2008、今度は内蔵 HDD を SSD に換装した。

　使用する SSD は Crucial の M4 SSD 256GB モデル。前回のメモリィ増設と同じ上海問屋さんから購入した。

　作業自体は超かんたん。必要な工具はプラスドライヴァとトルクスドライヴァ。この YouTube 動画に換装のやり方が紹介されとるけん見ておくと良い。

　ウチにはサイズの合うトルクスドライヴァがなかったけん、ペンチで挟んで無理矢理回したけど、これは推奨されんやり方やけん真似しないように。

　換装後は Snow Leopard のインストール DVD を挿入して SSD のフォーマット。さらに外付け HDD の Time Machine バックアップからシステムとデータを復元した。インストール DVD は Snow Leopard で、復元するシステムは Lion のものやったけど、いまのところ問題はないみたい。

　ただ、換装前の HDD には Lion にアップグレードした時点で Recovery HD という隠しボリュームができとったんやけど、それが消失した。
　Recovery HD は緊急時にインストール DVD と同様の作業が行えるボリューム。Mac App Store 経由で Snow Leopard から Lion にアップグレードした場合は、Lion のインストールメディアが存在しないため、インストール DVD の役目を担うボリュームが内蔵ストレージ内に作られる。
　Time Machine でバックアップされるのはふつうの起動ディスクの内容であり、その外側にある Recovery HD はバックアップされていないのが消失の原因。別に Recovery HD がなくても、トラブルさえ起きなければ、特に問題はないものと思われる。今回のシステム復元で用いたように Snow Leopard のインストール DVD があればそれで役目は果たせると考えてもいいのかも。保険として Recovery HD を持っていた方が良いかもしれないので、復元できる方法を調査してみる。

　換装前後のベンチマークを Xbench で取ったので、それを掲載する。左側は換装前 HDD のベンチマーク、右側が換装後 SSD のベンチマーク。

　換装前の Disk Test 総合値が 36.42、換装後が 341.99 と約 9.3 倍のスコアをマークした。換装後の Disk Test 以外の項目のスコアが軒並みダウンしているのは、換装後のベンチマークを取る際に MacBook からバッテリィを外していたため、CPU が抑制されていたものと考えられる（参考「MacBook および MacBook Pro：AC アダプタ使用時にバッテリーが取り外されるとプロセッサの速度が抑制される」）。

　なぜバッテリィを外していたのかというと、換装するさいに気がついたんやけど、バッテリィが膨張していたため。裏蓋が閉まらないほどではなかったものの、一応安全を期してしばらくはバッテリィを抜いて MacBook を運用する。後日サポートセンタに連絡したいと思う。

　……抜けやすいマグセーフアダプタでバッテリィなし運用はスリリングだぜ！

iCloud？それよりも Complete My Album って覚えてる？

2011-10-17T21:56:00.000+09:00

Apple の iCloud サーヴィスにおいて、音楽配信に関連する部分が日本では提供されていないというということに対する業界への批判なんかを最近よく目にしたりする。

　iCloud の音楽配信関連サーヴィスは、iCloud の特徴説明ページに詳しい。
　かんたんにまとめると、ひとつはあるデヴァイスでストアから購入した楽曲が自動的に他のデヴァイスへもダウンロードされるというサーヴィス。ひとつは過去にダウンロード購入した楽曲を再ダウンロードできるというサーヴィス。
　以上は iOS アプリケーションでは同様のサーヴィスが開始されている。
　次に、上述の日本版説明ページには書いていないが、アメリカ版ページには書いてある iTunes Match というサーヴィス。これもかんたんにまとめると、すでに自分が CD 等から iTunes に取り込んだ楽曲で、かつその楽曲が iTunes Store で配信されているものであるとする。その場合、年会費を支払うことでその楽曲をストアで配信されている 256 Kbps で DRM フリーな AAC ファイルをダウンロードできるというサーヴィスである。自分が過去に CD から取り込んだときの、128 Kbps 等の現在から見ると低ビットレートなファイルを、自分で取り込み直すことなくお手軽にアップグレードできるというわけである。

　これらが日本では——というかアメリカ以外のほとんどの国では提供されていない。これに対して業界に批判の声がいったりしているわけである。

　でもちょっと待って。みんな忘れてないかい？　iTunes Store のサーヴィスでまだ日本で始まっていないのがあるよ。それは Complete My Album というサーヴィス。これに関する説明は日本語ではこのプレスリリースにある。
　かんたんに説明する。一曲あたり 99 セントでアルバム単位では 9.99 ドルであったとき、そのアルバムからたとえば三曲を購入したとする。そのあとでアルバム単位で購入しようとするときは、先に購入した三曲分の値段がアルバム価格から割り引かれて 7.02 ドルで購入できるというわけ。たいていアルバムを一曲ずつ購入するよりもアルバム単位で購入した方が価格が安い。でも、先にアルバムから数曲を購入していた場合、一曲ずつ残りのものを購入した方が安いのか、あるいはアルバム単位で購入した方が安いのかを自分で計算しなければならない。アルバム単位で購入したとしても、先に購入した楽曲がダブってしまう。こんなスマートじゃない状況を解決してくれるのが Complete My Album というサーヴィス。
　これ、上述のプレスリリースを見ると解る通り、アメリカでは 2007 年に始まっている。4 年も前だけどまだ日本では始まっていない。

　いま注目を集めている iCloud の音楽配信関連サーヴィスについては先に説明をしたけど、よく考えてほしい。
　購入した楽曲が手持ちの他のデヴァイスへ自動ダウンロードできたらそれは便利だけど、それがなくたって明示的に同期をすれば済む話ではある。iTunes Store で購入した楽曲はダウンロードしたデヴァイスでの再生に限られているわけじゃないからね。楽曲の再ダウンロードはそれが必要になるのはレアケースじゃないかな？ Time Machine でバックアップ取っとけばまあ問題ないと思う。iTunes Match に関しては、これだけは他のと違って有料サーヴィスなのでちょっと言及を避けるけども。

　とまあこのように、iCloud の音楽配信関連サーヴィスはなきゃないでまだいいと思うんだ。
　それよりもアメリカでは 4 年も前に始まっている Complete My Album、こっちを先にサーヴィスインしてほしいとは思わないかい？

Automator を用いて EPUB を作る

2011-07-31T21:56:00.003+09:00

Mac OS X Lion の Automator には「テキストを EPUB ファイルにレンダリング」というアクションが追加されている。このアクションを用いることでテキストファイル（.txt）もしくはリッチテキスト（.rtf）から EPUB ファイルを生成することができる。今回は以下のようなサービスを作成して実際にどのような EPUB が生成されるかを見てみる。

　この Automator ワークフローを保存すると ~/Library/Services に保存され、Finder のサービスメニューもしくはファイル選択して右クリックのコンテキストメニューから実行できるようになる。
「テキストを EPUB ファイルにレンダリング」アクションは複数ファイルの入力をサポートしており、その場合はファイル名の順番に章立てされるような感じで EPUB が生成される。複数のファイルから生成する場合はそれらに連番を付ける等をしておくと並び順を制御できる。

　原稿のテキストファイルとそれらから生成した EPUB が以下。

　EPUB を Murasaki で表示すると以下の画像のようになる。

　元が単なるテキストなので見栄えはしない。たとえばファイルの先頭一行目はタイトルとみなして自動で大きめのフォントサイズにしてくれる、みたいな気の効いたことをしてくれると使い出があるのだが。

　次にリッチテキスト原稿と生成した EPUB が以下。

　EPUB を Murasaki で表示すると以下のようになる。

　こちらの場合では、元のリッチテキストの段階でフォントサイズや色をある程度制御できる。4ページ目の「文字いじり」の章が以下の画像のようになる。

　これは Mac OS X 付属のテキストエディットで設定できる「段落スタイル」に対応している。「アウトライン」以外のスタイルは Murasaki で表示できる形式に変換されているようである。「アウトライン」の部分が実際にどのように変換されているのかを見てみると font-effect: outline という CSS3 のプロパティが設定されていた。Murasaki は Safari と同等の WebKit を用いているが、WebKit は font-effect には対応していないようである。

　設定されるメタデータが以下のようになる。

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf">
    <dc:title>Automator で EPUB を作る（テキストファイル編）</dc:title>
    <dc:language>en</dc:language>
    <dc:identifier id="BookId" opf:scheme="ISBN">123456789X</dc:identifier>
    <dc:creator opf:file-as="" opf:role="aut">Genji</dc:creator>
</metadata>

　dc:title と dc:creator の値はアクション実行時のダイアログから設定できるが、dc:language と dc:identifier は固定のようである。dc:language はともかく dc:identifier が固定なのは気持ち悪い。

　テキストエディットでは文中に画像を入れた、rtfd という拡張子を持つ「添付データ付きリッチテキストフォーマット」を作成できるが、この Automator アクションには対応していない。アクション実行時のダイアログで表紙画像を設定したり、HTML ファイルそれぞれに画像等を配置したりすることはできる。

　以上、簡単な紹介でした。

NSXMLDocument と文字コード指定の謎

2011-07-28T19:16:00.000+09:00

NSXMLDocument の謎な挙動でハマったのでメモ。

　HTML ファイルの内容を NSXMLDocument でパースして情報を取得するという場合を考える。読み込むのは以下のような HTML ファイル。

<!doctype html>
<html lang="ja">
  <head>
    <meta charset="utf-8" />
    <title>あいうえお</title>
  </head>
  <body>
    <p>あめんぼあかいなあいうえお</p>
  </body>
</html>

　ポイントは HTML5 的な <meta charset="utf-8" /> という文字コード指定。従来の <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> というような指定方法では問題ないのに、上記 HTML5 的な指定をすると NSXMLDocument が文字コードを正しく解釈してくれず、場合によっては取得する文字列値が化ける。

　NSXMLDocument オブジェクトを初期化する方法として三つの異なる初期化メソッドを用いて実験してみる。

#import <Foundation/Foundation.h>

static void output(NSXMLDocument *xmlDoc)
{
  NSLog(@"encoding: %@", [xmlDoc characterEncoding]);
  NSArray *nodes = [xmlDoc nodesForXPath:@"html/body/p" error:NULL];
  NSXMLNode *node = [nodes objectAtIndex:0];
  NSLog(@"result  : %@", [node stringValue]);
}

int main (int argc, const char *argv[])
{
  NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

  NSUInteger options = NSXMLDocumentTidyHTML;
  NSURL *url = [NSURL fileURLWithPath:@"/Users/genji/Desktop/test.html"];

  NSXMLDocument *xmlDoc;
  xmlDoc = [[NSXMLDocument alloc] initWithContentsOfURL:url
                                                options:options
                                                  error:NULL];
  output(xmlDoc);
  [xmlDoc release];

  NSData *htmlData = [NSData dataWithContentsOfURL:url];
  xmlDoc = [[NSXMLDocument alloc] initWithData:htmlData
                                       options:options
                                         error:NULL];
  output(xmlDoc);
  [xmlDoc release];

  NSString *htmlString;
  htmlString = [NSString stringWithContentsOfURL:url
                                        encoding:NSUTF8StringEncoding
                                           error:NULL];
  xmlDoc = [[NSXMLDocument alloc] initWithXMLString:htmlString
                                            options:options
                                              error:NULL];
  output(xmlDoc);
  [xmlDoc release];

  [pool drain];
  return 0;
}

　処理内容は NSXMLDocument を用いて HTML ファイル中の p 要素の文字列値を出力するという単純なもの。こいつの実行結果が以下のようになる。

encoding: (null)
result  : ã‚ã‚ã‚“ã¼ã‚ã‹ã„ãªã‚ã„ã†ãˆãŠ
encoding: (null)
result  : ã‚ã‚ã‚“ã¼ã‚ã‹ã„ãªã‚ã„ã†ãˆãŠ
encoding: UTF-8
result  : あめんぼあかいなあいうえお

　はじめのふたつ、初期化メソッドに initWithContentsOfURL:options:error: を用いた場合と、一度 NSData にファイル内容を読み込んでから initWithData:options:error: を用いた場合は characterEncoding に何もセットされておらず、文字列値を出力しても化けてしまっている。

　翻ってファイル内容を NSString に読み込んでから initWithXMLString:options:error: を用いた場合は characterEncoding が正しくセットされており出力も正常に出る。

　NSString でファイル内容を読んだあとに dataUsingEncoding: で NSData に変換して初期化した場合は characterEncoding はセットされず文字化ける。

　さらに、上記のコード例では NSXMLDocument の初期化メソッドに渡すオプションは NSXMLDocumentTidyHTML にしているが、これを NSXMLDocumentTidyXML にすると、characterEncoding がセットされないのは変わらないが、出力文字列値が化けないのである。

文字数を数えるサービスを Automator + AppleScript で作る

2011-07-09T17:58:00.002+09:00

ウェブブラウザやテキストエディタで選択中の文章の文字数を数えるサービスを作る。今回は Automator の「AppleScript を実行」アクションを使う。

　まず、ワークフロー新規作成時の「ワークフローのテンプレートを選択」より「サービス」を選択する。

　次に「AppleScript を実行」アクションを追加する。

　ワークフロー表示部分の上にある「"サービス"は次の選択項目を受け取ります」には「テキスト」を選択する。

　AppleScipt は以下のような感じ。

on run {input, parameters}
	
	set inputCharacters to (input as string)
	set lengthOfCharacters to length of inputCharacters
	display dialog "Length of characters is " & lengthOfCharacters buttons {"OK"} default button 1 with icon 1
	
end run

　これで完成。かんたんですね。ワークフローを保存すると ~/Library/Services に拡張子 .workflow で保存される。

　あとはブラウザやテキストエディタなんかで文章を選択状態にして、メニューバーのサービスメニューもしくは右クリックのコンテキストメニューからこのサービスを使うことで文字数を表示したダイアログが表示される。

Mac App Store での Dashboard Widget 配信の可能性について

2011-07-09T15:41:00.000+09:00

Mac OS X 10.4 Tiger から搭載された機能として Dashboard がある。Dashboard は HTML + CSS + JavaScript で作られた Widget という Web アプリケーションのようなものを動かす環境である。時計やカレンダー、辞書、計算機、スティッキーズメモなどの Widget が標準で用意されている。Widget のゲームなんかもサードパーティから公開されていたりする。

　Tiger の目玉機能のひとつとして発表当時からしばらくはそこそこの話題にはなったものの、今となっては影が薄くなった感は否めない。そこで今一度 Dashboard が注目を集めるにはどうすればよいか？　と考えて思いついたのが Mac App Store での配信である。

　Mac App Store は iOS の App Store の Mac 版である。サードパーティ企業や一般の開発者によって登録されたアプリケーションが一堂に会しており、簡単にアプリケーションのダウンロード・インストールを行うことができる。
　App Store をユーザから見た場合、ひとつの場所で多くのアプリケーションから目的のものを探すことができ、有料アプリケーションの決済についても Apple ID をひとつ用意するだけですむメリットがある。
　ディヴェロッパから見た場合、Apple ブランドの店に商品を卸すことができ、自前で決済システムを用意することなく有料アプリケーションを販売することができるメリットがある（その代わり売り上げの 30 % は Apple の手数料となる）。

　現在、Mac App Store では Dashboard Widget の配信は行われていないが、それが可能になれば、再び Dashboard に注目が集まる日が来るかもしれない。通常の Mac 用アプリケーションで作るよりも Dashboard Widget の方が向いているようなジャンルも存在するし、Tiger 当時よりも Web アプリケーション分野も発達してきておりノウハウも貯まってきている。App Store で簡単に有料配信が可能になれば Dashboard Widget 開発に乗り出すディヴェロッパも増えてくるのではないだろうか。

　Dashboard Widget の配信に際して問題になるのは、そのアーキテクチャである。Dashboard Widget の実体は簡単に言えば HTML、CSS、JavaScript（＋その他のリソース）をフォルダに纏めただけのものである。簡単に中身を覗くことができ、ロジックやリソースはコピィし放題となる。これでは有料配信には向かない（と考えるディヴェロッパもいるだろう）。

　ここで参考になるのが Apple のもうひとつの電子ストアの iBookstore である。iBookstore は iOS 機器から利用できる電子書籍ストアでり、EPUB を扱う。

　EPUB は電子書籍の形式のひとつでる。その実体は、書籍の内容となる HTML、CSS やその他画像等のリソースと、メタデータとなる XML を纏めて zip 圧縮したものであり、構造としては Dashboard Widget とよく似た部分がある。

　iBookstore で配信されている EPUB は DRM が掛かっており、その中身は暗号化されている。そのためダウンロードした EPUB ファイルを展開して単純に中身を覗こうとしても、それは不可能となっている。

　これと同じようなことを応用すれば、Mac App Store で Dashboard Widget の配信も可能になるのではないだろうか？

3DS と Mac 間の画像受け渡しを SD カードを介さずに行う

2011-06-18T17:07:00.001+09:00

ニンテンドー 3DS で撮った写真や、保存した Mii 画像、ゲームソフトで生成した画像を Mac（パソコン）に移動させようとしたら、通常は SD カードを経由して行うことになる。つまり

3DS から SD カードを抜いて
カードリーダ・ライタ機器に差して
それを Mac に認識させて
ファイル移動
カードリーダ・ライタ機器から SD カードを抜いて
3DS にカードを差す

というような手順を踏む。

　これはいかにもめんどくさい。3DS から SD カードを抜き差しする際は 3DS 本体の電源を切ることが推奨されてるっぽいのでさらにめんどい。3DS 本体が SD カードリーダ・ライタとして動作し、Mac とケーブルで繋いでファイル転送、くらいならまだいいのだが……。

　そこで、六月の 3DS 本体アップデートでインターネットブラウザが使用可能になったことに着目する。3DS のインターネットブラウザはフォームの <input type="file" /> に対応しており、本体および SD カードに保存されている画像のアップロードを行うことができる。

　つまり、ローカルネットワーク上でウェブサーヴァを立ち上げて、そこで簡易的な画像アップローダを構築すれば、SD カードの抜き差しを行うことなく画像の受け渡しが可能になるというわけである。

　アップローダは「ファイルをアップロードする - Python CGIプログラミング入門」を参考に Python で書いた。40 行程度。参考ページの Python スクリプトは単にファイルをアップロードするだけやけど、一般的な画像アップローダみたいなファイルリストなんかも出力するようにしておけば、Mac から 3DS への画像移動も簡単にできるようになる（3DS のインターネットブラウザで画像を開くと本体に保存できる）。ウェブサーヴァは Mac 標準の Apache で適当な設定をして Python スクリプトが CGI として動くようにしておく。画像を書き込むディレクトリィのパーミッション設定も忘れずに。

　3DS のインターネットブラウザは viewport 指定が効くみたいやけん、head 内に <meta name="viewport" content="width=device-width"> を入れておくとイイ感じのサイズで表示してくれる。

　準備が終われば 3DS のインターネットブラウザからアップローダにアクセスし、Mac に移動したい画像をアップロードすればよい。簡単ですね。

Segmented Control 等に独自のアイコンを設定する際の留意点

2011-05-17T15:08:00.001+09:00

Interface Builder を用いて Segmented Control 等に独自のアイコン画像を設定する場合、まず画像を Xcode に登録してから IB のインスペクタで画像を選択する。

　Xcode に登録する画像名は任意でも構わんのやけど、名前の末尾に Template と付けておくと、Segemented Control 等を選択時に画像を良い感じにしてくれる。
　たとえば SDK に用意されている NSPathTemplate という定数名で指定する画像は、非選択時には黒単色で構成されている画像やけど、選択時には青いドロップシャドウが掛かった感じになる。SDK の他の画像も末尾に Template が付いているものは同様になる。
　自分でアイコン画像を用意する場合も同様で、画像名の末尾に Template を付けると（HogeTemplate.png 等）上記の画像変換を自動でやってくれる。

　上記の画像は各行の左ふたつは SDK で用意されている標準の画像（NSPathTemplate、NSListViewTemplate）。右ふたつは自分で用意した画像（BookmarkTemplate.png、Bookmark.png）。右端の Bookmark.png を設定したセグメント以外は、クリックで選択時に青いドロップシャドウが掛かった画像に自動的になる。

　Template 画像に関する詳細は NSImage のクラスリファレンスを参照。

MacBook Late 2008 のメモリィを 8GB に増設

2011-05-02T12:17:00.001+09:00

現在使用している Mac は MacBook の Late 2008 版。非 MacBook Pro でありながらアルミニウムユニボディの筐体を持つ珍しい世代の MacBook である。

　二年以上前の世代ながら性能はまずまずで、一般的な用途ならまだぜんぜん現役で戦えるし、ぱっと見 MacBook Pro みたいでかっこいい。また、現在のユニボディ筐体は底面も一体化していてバッテリィや内蔵ストレージへのアクセスが容易ではないのに対し、この Late 2008 版は底面の半分をワンタッチで取り外しでき、内部へのアクセスが容易であるという利点もある(その反面、それまでの世代では搭載されていた FireWire 端子がオミットされている)。

　購入時にメモリィを最大の 4GB にしていたし、一般的な用途(ウェブブラウズや音楽・動画鑑賞等)ではぜんぜん問題なかったものの、それらにプラスして Xcode や Interface Builder 等の開発アプリケーションを同時に立ち上げたりしていると、メモリィを食い尽くして頻繁にスワップしてしまっていた。

　だがだが、この MacBook Late 2008 版、公称ではメモリィは最大 4GB ながらも、実は非公式ながら 8GB まで搭載できるのである。そのあたりの詳しい情報は Google 先生にお尋ねを……。

　ここはいっちょう、8GB まで増設してみるのだ。

　MacBook Late 2008 版に搭載できるメモリィの規格は「DDR3 SODIMM PC3 8500 (DDR3 1066)」というタイプのもの。今回は上海問屋さんから SAMSUNG 製のものを購入。
　値段は、私が購入したときで 4GB が 3,880 円の掛ける 2 で 7,760 円。送料無料でクレジットカードも使えて便利で安い。

　今のところ相性問題等もなく、快適に 8GB ライフを満喫している。Google Chrome だろうが、iTunes だろうが、Xcode だろうが、Interface Builder だろうがドンとこい！

　これで内蔵ストレージを SSD に換装できれば、あと三年は戦えるのだが……。もっと安くなっておくれ、SSD。

NSToolbar にカテゴリィを用いてメソッドを追加する

2011-04-30T19:54:00.002+09:00

Safari で言えば「戻る・進む」ボタンや URL 欄がある部分を Cocoa アプリケーションでは「ツールバー」と言い、NSToolbar クラスで表現される。ツールバー上にある要素は NSToolbarItem クラスで表現され、NSToolbar のインスタンスメソッド - (NSArray *)items で配列オブジェクトとして取得できる。画面最上部のメニューバーとメニュー項目は、同じように NSMenu クラス、NSMenuItem クラスで表現され、NSMenu からインスタンスメソッド - (NSArray *)itemArray で配列オブジェクトととして NSMenuItem を取得できる。

　ここで、NSMenu にはインスタンスメソッド - (NSMenuItem *)itemWithTag:(NSInteger)aTag が存在し、NSMenuItem に設定した tag をパラメータに指定することで特定のメニュー項目を一発で取得できるのに対し、NSToolbar にはそのようなインスタンスメソッドが存在しない。

　今回は NSToolbar に NSMenu と同様の - (NSToolbarItem *)itemWithTag:(NSInteger)aTag を実装する。実装するにあたり、NSToolbar のサブクラスを作るのではなく、カテゴリィを用いてメソッドを追加する形で行う。

　まずヘッダファイル NSToolbar+Additions.h が以下のようになる。

#import <Cocoa/Cocoa.h>

@interface NSToolbar (Additions)

- (NSToolbarItem *)itemWithTag:(NSInteger)aTag;

@end

　実装ファイル NSToolbar+Additions.m は以下のようになる。

#import "NSToolbar+Additions.h"

@implementation NSToolbar (Additions)

- (NSToolbarItem *)itemWithTag:(NSInteger)aTag
{
  NSArray *items = [self items];
  for(NSToolbarItem *item in items) {
    if([item tag] == aTag) return item;
  }
  return nil;
}

@end

　簡単ですね。これで、NSToolbar+Additions.h をインポートすれば、NSToolbar のインスタンスメソッドとして - (NSToolbarItem *)itemWithTag:(NSInteger)aTag を使えるようになる。

WebView に水平スクロールバーが表示されているかを検出する

2011-02-27T21:43:00.001+09:00

作成中の EPUB 閲覧アプリケーション Murasaki において、EPUB の本文を表示している WebView に水平スクロールバーが表示されているかどうかを検出する必要が出た。そこで、WebView のサブクラスに以下のようなインスタンスメソッドを実装した。

- (BOOL)isHorizontalScrollerVisible
{
  NSInteger clientWidth, scrollWidth;
  clientWidth = [[self stringByEvaluatingJavaScriptFromString:
                  @"document.documentElement.clientWidth;"] integerValue];
  scrollWidth = [[self stringByEvaluatingJavaScriptFromString:
                  @"document.documentElement.scrollWidth;"] integerValue];
  return (clientWidth < scrollWidth);
}

　WebView のインスタンスメソッド stringByEvaluatingJavaScriptFromString: は、NSString 型で JavaScript のコードを渡すと、その結果を NSString で返してくれるけん、これを用いる。
　document.documentElement.clientWidth はユーザに見えている表示領域の幅、document.documentElement.scrollWidth はドキュメントの実際の幅を返す。表示領域の幅よりもドキュメントの実際の幅が大きければ、すなわち水平スクロールバーが出ているということ。

Now Playing: "オレンジ・フィルム・ガーデン" from the album "GOOD DREAMS" by the pillows, My Rate: *****

トラックパッドのピンチ操作で拡大縮小

2011-01-29T16:29:00.023+09:00

「Cocoaの日々: [Mac] トラックパッド〜ピンチで拡大縮小」を参考に、開発中の EPUB 閲覧アプリケーションにピンチ操作による文字の拡大縮小処理を追加。具体的には WebView のサブクラスに以下のメソッドを実装した。

- (void)magnifyWithEvent:(NSEvent *)event
{
  static NSTimeInterval lastOccurredTime;
  NSTimeInterval currentTime = [event timestamp];
  if(currentTime - lastOccurredTime < 0.3) return;

  if([event magnification] > 0) [self makeTextLarger:nil];
  else [self makeTextSmaller:nil];
  
  lastOccurredTime = currentTime;
}

　ピンチ操作の拡大縮小具合は [event magnification] で得られる。拡大の場合は正、縮小の場合は負の値が取れるけん、それに合わせて WebView の文字拡大縮小のメソッドを呼び出す。

　ユーザ的には一度のピンチ操作でも、magnifyWithEvent: はジェスチャ中に何度も呼び出されてしまう。そのままでは一度のピンチ操作で一気に最大／最小文字サイズまで行ってしまうけん、最後にイヴェントが発生した時間を保存しておき、現在時間と比べて適当な時間間隔内であれば何もしないようにしておく。イヴェントが発生した時間（システム起動時からの経過時間）は [event timestamp] で取れる。

リンク先の URL を表示する

2010-12-31T13:09:00.002+09:00

EPUB にはふつうの HTML 同様、ハイパリンクを入れることができる。前回のポストでは EPUB 内リンクと外部リンクで動作を変えたわけやけど、今回はリンク文字列にマウスカーソルを乗せたときにそのURLをウィンドウ下部に表示する処理を考える。

　WebView に表示させている HTML 文書の要素上にマウスカーソルが乗ったときに呼ばれるデリゲートメソッドが webView:mouseDidMoveOverElement:modifierFlags:。実際の実装具合が以下の通り。

- (void)webView:(WebView *)sender
mouseDidMoveOverElement:(NSDictionary *)elementInformation
  modifierFlags:(NSUInteger)modifierFlags
{
  NSString *statusText = @"";
  NSURL *linkURL = [elementInformation objectForKey:WebElementLinkURLKey];
  if(linkURL) {
    NSString *urlString = [linkURL absoluteString];
    if([urlString hasPrefix:@"file://"]) {
      statusText = [NSString stringWithFormat:@"Go to \"%@\"", [urlString lastPathComponent]];
    }
    else {
      statusText = [NSString stringWithFormat:@"Open \"%@\" in Web Browser", urlString];
    }
  }
  [statusLabel setTitleWithMnemonic:statusText];
}

　マウスカーソルが乗ったのがリンク文字列だった場合は、elementInformation の WebElementLinkURLKey キィにリンク先URLが入っている。前回同様、EPUB 内リンクだった場合と外部リンクの場合とで処理を変える。結果生成された文字列を NSTextField に設定してやることで完成。

ザ・シネマハスラーで評論された映画を iTunes で観る

2010-11-24T00:20:00.013+09:00

ラジオ番組「TBS RADIO ライムスター宇多丸のウィークエンド・シャッフル」のポッドキャストを聴いている。その中で「ザ・シネマハスラー」という映画を評論するコーナがあって、お題となっている映画を観たリスナからのメイルを紹介しつつ、パーソナリティ宇多丸さんの熱い評論が聴ける。

　で、先日始まった iTunes の映画レンタル（or 販売）サーヴィス。それなりのラインナップが用意されとってどれを観るか目移りするわけやけど、そこで前述のザ・シネマハスラーの登場となる。
　過去に評論されたものはいまでもポッドキャストで聴けるけん、宇多丸さんとリスナの評論を元にどの映画を観るかの参考にしてみる。ザ・シネマハスラーで評論されたものの中で、現在 iTunes の映画レンタルで観ることができる作品を対応づけたリストを作成した。

ザ・シネマハスラーで評論された映画を iTunes で観る

　こうやって纏めてみると、2010年作品はまだしも、2009年・2008年作品でもまだまだ iTunes で取り扱ってないのが多いな。

EPUB 内リンクと外部リンクで動作を変える

2010-10-31T12:09:00.071+09:00

Mac 用 EPUB プレヴュワ開発について。

　EPUB の実体は (X)HTML やけん、本文中に <a href="http://www.google.com/">Google</a> みたいなハイパリンクを入れることができる。

　EPUB プレヴュワの表示エンジンには WebKit を使っとるけん、何もしなくてもリンククリックでページ遷移をすることはできる（ただし、target="_blank" 等で新しいウィンドウを開くタイプのリンクの場合はちょっとしたコードを書く必要がある）。ほなけど、作っとんのはあくまでも EPUB を（簡易的に）閲覧するアプリケーションやけん、外部リンクの場合は Safari 等システムで指定されとるウェブブラウザで開いて、目次から各章へのリンクなどの同一 EPUB 内へのリンクはアプリケーション内のページ遷移で処理する必要がある。
　したがって、クリックしたリンクのリンク先 URL をページ遷移処理前に調べて、それが内部リンクなのか外部リンクなのかで動作を変える処理を入れる。

　ページ読み込み処理の前には

webView:decidePolicyForNavigationAction:request:frame:decisionListener:

という WebPolicyDelegate 非形式プロトコルのメソッドが呼ばれる。これをオーヴァライドすることで上述の処理を実現できる。具体的には以下のような感じ。

- (void)webView:(WebView *)webView
decidePolicyForNavigationAction:(NSDictionary *)actionInformation
        request:(NSURLRequest *)request
          frame:(WebFrame *)frame
decisionListener:(id <WebPolicyDecisionListener>)listener
{
  int navigationType = [[actionInformation objectForKey:WebActionNavigationTypeKey] integerValue];
  if(navigationType == WebNavigationTypeLinkClicked) {
    NSDictionary *element = [actionInformation objectForKey:WebActionElementKey];
    NSURL *linkURL = [element objectForKey:WebElementLinkURLKey];
    if(![[linkURL scheme] isEqualToString:@"file"]) {
      [[NSWorkspace sharedWorkspace] openURL:linkURL];
      [listener ignore];
    }
  }

  [listener use];
}

　actionInformation には読み込み処理がトリガされたアクションに関するデータが NSDictionary で入っている。その WebActionNavigationTypeKey キィには、リンククリックやフォームのサブミット等、どのような操作によって読み込み処理が発生したのかが入っている。WebActionElementKey キィには要素の詳細なデータがやはり NSDictionary で入っとるけん、そこからリンク先の URL を調べることができる。内部リンクであれば、リンク先の URL のスキームは file になっとるはずやけん、file 以外ならばシステム指定のブラウザで開く処理とディフォルトの動作を無視させる [listener ignore]; の処理を入れる。

　上記のようなコードを書いたあとは、Interface Builder において WebView の Policy Delegate を接続してやると、内部リンクと外部リンクで動作を変えた処理をできるようになる。

EPUB プレヴュワ開発中

2010-10-31T04:49:00.004+09:00

Amazon Kindle や Apple iBooks 等の登場により、電子書籍がちょっとしたブームになっとります。一口に電子書籍と言ってもその形式は様々で単なる PDF だったりプラットフォーム側が用意した独自形式だったり。
　そんななかで有力な形式とひとつとして EPUB というものがある。おおざっぱに言えば、本文を記述した (X)HTML とメタデータを記述した XML ファイルを纏めて ZIP 圧縮したものである。オープンな規格でだれでも簡単に作成できることから、電子書籍ブームの中で注目されている規格と言える。

　iPhone や iPad で EPUB を読むなら iBooks を使えば良いわけやけど、これが Mac でとなると話が変わってくる。Mac 用の EPUB リーダもいくつか存在してはいるものの、どれもいまいち使い勝手が良くない。そのどれもがマルチプラットフォームを意識した作りになっとって、実際の実装がどうなっとるかは解らんけど、とにかく Mac 用アプリケーションらしさがない。Apple が Mac 用の iBooks を作ってくれればそれで良いんやけど、どうもそういう気配もないわけで。

　ないならいっちょ作ってみよう、と考えてやっと今回のエントリィのタイトルにたどり着くわけです。現在、EPUB のプレヴュウアプリケーションを開発中。

　ふつう、電子書籍を閲覧するアプリケーションは「Reader/リーダ」を名乗るけど、あえて「Previewer/プレヴュワ」なのはそれほど凝ったことをやるつもりがないから。
　Mac の標準的な開発環境である Cocoa フレームワークでは、ウェブブラウザ Safari や Chrome でも用いられとる WebKit を使うことができて、ごく単純なウェブブラウザならば、それこそ自分では一行もコードを書くことなく作れてしまう。EPUB の実体は (X)HTML やけん、今回のアプリケーションでは WebKit に HTML を喰わすだけ、みたいなシンプルな実装をしてみようと思う。これは Mac App Store が始まることへの布石でもある。

　で、試作してみたアプリケーションがこんな感じ。

　中身の HTML を WebKit に読み込ませとるだけやけど、だからこそ自分で特別な処理を書かんでも画像やルビなんかも表示できる。

　実際、単に EPUB を読むだけならば、現在出回っとる他の EPUB リーダよりもこのアプリケーションの方が読みやすいんじゃないかと思います。

　まだ実装すべき部分があって、加えて Mac 用アプリケーション開発の実績も、オブジェクト指向言語での開発も碌にしたことがない私なので、覚えるべきこと、調べるべきことがたくさんあって、完成にはまだまだと言ったところ。

Automator + Python でサービスを作る

2010-09-30T00:02:00.073+09:00

Mac OS X 付属の自動化処理作成アプリケーション Automator で「サービス」を作ることができる。Automator の中で Python を実行させることもできるけん、今回は Automator + Python な環境で、iPhone アプリケーションのスクリーンショット画像から、AppStore 提出用にステータスバー領域を切り抜いた画像を生成するサービスを作ってみる。

　まず、ワークフロー新規作成時の「ワークフローのテンプレートを選択」より「サービス」を選択する。

　そして、「Finder 項目を複製する」アクションと「シェルスクリプトを実行する」アクションを追加する。

　ワークフロー表示部分の上にある「"サービス"は次の選択項目を受け取ります」には「イメージファイル」を選択し、シェルスクリプトを実行するアクションの「シェル」には「/usr/bin/python」を、「入力の引き渡し方法」には「引数として」を選択する。

　Python スクリプトは以下のような感じ。

import sys
import Image

def cropImage(image):
 width, height = image.size
 offset = 0
 if (width, height) == (640, 960) or (width, height) == (960, 640): offset = 40
 elif (width, height) == (320, 480) or (width, height) == (480, 320): offset = 20
 else: return image
 return image.crop((0, offset, width, height))

for filename in sys.argv[1:]:
 try:
  image = Image.open(filename)
  cropped = cropImage(image)
  cropped.save(filename)
 except IOError as err:
  print "IO Error: %s" % format(err)
  continue

　これで完成。切り抜き等の画像処理には Python Imaging Library (PIL) を使っとるけん、事前にインストールが必要。

$ sudo easy_install PIL

　このワークフローを保存すると、~/Library/Servicesに拡張子 workflow で保存される。

　あとは Finder で画像ファイルを選択し、メニューバーのサービスメニュー、もしくは右クリックから作成したサービスを実行することができる。複数ファイルを選択した状態でも実行可能。

　「Finder 項目を複製する」アクションを噛ましとるけん、元の画像は変化せず、コピィされたファイルに対して画像処理が施される。

　Python の勉強がてら便利そうなもの作ってみるテストでした。

無線LAN設定と戦った三時間

2010-07-31T22:47:00.000+09:00

iPhone 4を買った際に貰ったfonルータを、今まで使っていた無線ルータと置き換えよとして浪費した三時間。

自分が使っとるMacBookとiPhone、父親が使っとるiBookの設定はそれぞれ5分程度で終了。問題は姉が使っているWindowsマシンなのだった。

Windowsマシンはデスクトップ型で無線LAN機器は内蔵されていない。既存の無線ルータに付いてきたUSB接続の子機を介して無線接続されていた。

問題は子機のドライバである。fonルータのディフォルトでは無線の暗号化にWPA/WPA2を使う。しかし子機は古い機種でWEPにしか対応していなかった。

メーカのウェブサイトで新しいドライバを探すとWPAに対応したドライバが配布されていたので、早速インストールしたのだが、はい、出ました。ブルー・スクリーン・オブ・デス！

新しいドライバをインストールすると、子機を接続した段階で落ちる。子機を外しておくと落ちない。ドライバをアンインストールすると子機接続時でも落ちない。

問題は新しいドライバのようです。

何度かインストール・アンインストールを繰り返して見るものの問題は解決せず。

子機購入時に製品に添付されとったCDからインストールする古いドライバだとBSODはでないけどWPAに対応していない。新しいドライバはWPAに対応しとる(？)けど落ちて使い物にならない。

結局、不本意ながらfonルータの暗号化の形式をWEPに変えて対処した。

そういうお話し。

Google SketchUp + Podiumプラグイン

2010-07-15T02:29:00.037+09:00

Google SketchUpは簡単な操作で3Dモデルを作成できるアプリケーション。WindowsとMacに対応。ただしあくまでもモデリングツールやけん、SketchUpだけではリアルな質感や光源の表現は難しい。
　そこで登場するんがPodium for SketchUp。SketchUp内で動作するプラグインで、これを使うことによってリアルな質感や光源の表現を伴ったレンダリングを行うことができる。有料のソフトウェアやけど、機能制限が付いた無料版がある。

　SketchUp標準の画像出力がこんな感じになる。

　これとまったく同じ3DモデルをPodiumを使ってレンダリングすることで、

　というような感じに、リアルな質感を持った画像を出力できる。SketchUpだけでは出せない金属部分の光沢や反射が綺麗に表現できていると思う。

　MacBook 2GHz Intel Core 2 Duoプロセッサ、4GBメモリの環境で、SketchUp標準の画像出力に掛かる時間が五秒程度、Podiumでのレンダリングに掛かる時間が500x500ピクセルサイズ・クォリティ重視の設定で一分程度といったところ。

　SketchUpもPodiumも無料で使えるソフトウェアでここまでできるんだから良い時代になったもんです。

　

iPhoneベルアプリ作成その4

2010-06-23T23:26:00.000+09:00

iPhoneベルアプリ作成その4。

　いままでベルの画像はGoogle画像検索で拾ってきた適当なのを使っとったんやけど、Google SketchUpで3Dモデルを作って差し替え。金属部分の光沢が出せない……。