Project "pKizzy"

pKizzy のご紹介

PDF 内容のプレビュー機能
プロパティ中の文字列をキーとしてアーティクルをインクリメンタルに絞り込み
Spotlight 全文検索/メタデータ検索を用いたアーティクル絞り込み
階層化可能なグループによる管理
条件指定可能なスマートグループ
スマートグループの条件を使った検索機能
PDF ファイルを持たない PDFless アーティクルを作成・管理可
Source プロパティの省略形を管理する Source Titles Manager
アーティクルのリストを任意書式でテキストとして出力する Bibliography Exporter
PDF インポート時に自動的にメタデータを抽出する Extractor をプラグ・インとして組み込み可

Download pKizzy

pKizzy

Meta-Information Extractors

pKMEx pack (2010. 2. 17)

旧バージョン

pKizzy (Snow Leopard 専用版)
download pKizzy Ver.0.8.3

pKizzy (Leopard 以降専用版)
download pKizzy Ver.0.7.8
download pKizzy Ver.0.7.8 source files

pKizzy (Tiger 対応版)
download pKizzy Ver.0.6.10
download pKizzy Ver.0.6.10 source files

pArticles (未 Core Data 版)
download pArticles Ver.0.4.2
download pArticles Ver.0.4.2 source files

Meta-Information Extractors
pAMEx pack (2006. 5.25)

Meta-Information Extractor SDK

header file Ver. 0.1.1
sample Xcode project Ver. 0.1.1

SDK の使い方はこちらのページで。

なんちゃってクラウド化計画

コンセプト: なんちゃってクラウド化には、オンラインストレージサービス (Dropbox/SugarSync/Google Drive 等) を利用します。
これらのクラウドストレージは、Mac 上の指定したフォルダ (またはディスクイメージ) の中身のコピーをサーバ上に保存します。
フォルダの中身に変更が加えられると、それを自動的に検出してサーバ上のデータにその変更を反映します。
クラウドストレージには複数の Mac (あるいは他のデバイス) を同期させることができ、ある Mac で加えられた変更は自動的に他のデバイスに反映され、同期フォルダの中身は複数デバイス間で常に同じに保たれます。

pKizzy では、ライブラリファイルや PDF (およびその他の管理対象となる) ファイルを、任意の場所に置くことができます (参考)。
そこで、ライブラリをクラウドストレージの同期フォルダ内に置き、複数デバイス間で同期させることによって、ライブラリの共有を実現する事ができます。

メリット

なんちゃってクラウド化すると、

複数 Mac 間でライブラリを共有できる

のほか、

自動的にライブラリのバックアップがとられる

というメリットもあります。
なので、１台の Mac で pKizzy を使ってるだけ、という人でも、クラウド化する恩恵は十分にあると言えるでしょう。

やり方

なんちゃってクラウド化を実行するためには、以下の手順にしたがってください。
あらかじめクラウドストレージサービスへの登録は終え、利用可能な状態になっているとします。

マスターとなる Mac (pKizzy ライブラリ) を決める。
すでに構築されたライブラリがある場合は、その Mac を基準とすればよいでしょう。
マスター Mac で pKizzy が起動していれば終了する。
マスター Mac にある pKizzy ライブラリフォルダ
を、クラウドストレージの同期フォルダ内の任意の場所に移動。
移動した pKizzy フォルダのエイリアスを
フォルダに配置して、名前を "pKizzy" に設定。

２台目以降の Mac がある場合、それぞれで以下の手順をおこないます。

クラウドストレージの同期が完了するまで待機。
同期が完了したら、同期フォルダ内の pKizzy ライブラリフォルダのエイリアスを
フォルダに配置して、名前を "pKizzy" に設定。

以上！！

このクラウド化は、あくまで「なんちゃって」です。
複数のマシンから同時にライブラリにアクセスするような状況は想定されていません。
あるマシンで使用中のライブラリに別のマシンからアクセスする、あるいは、pKizzy が稼働している間に別のマシンによってライブラリが変更される、といった事態が起きた場合、いかなる事態が生じるか保証しかねます。
ある Mac で pKizzy を起動する前に、ライブラリを共有する他のすべての pKizzy を終了しておくのが無難かと思われます。
ライブラリが破壊されるような事態になっても責任は負いかねますので、あしからず。
(本当は、複数マシンからのアクセスを想定したクラウド化をするべきなんだろうけど、技術力や開発リソース (要するに時間) の問題で、すぐにはムリです。とりあえず、なんちゃってクラウド化でしのいでください。)
すでに構築されたライブラリをクラウドに移す場合、最初の同期にはかなりの時間がかかるかもしれません（もちろんライブラリのサイズによります）。
同期途中で共有するとややこしい事態が生じる可能性もあります。
初回の同期には、十分に時間の余裕を見ておいた方がよいでしょう。

pKizzy Browser (iOS アプリ)

SugarSync/Google Drive その他には対応しておりません。あしからず。

ダウンロード

ダウンロードは iTunes Store から

pKizzy Browser

使い方

pKizzy Browser を利用するためには、上記「なんちゃってクラウド化計画」にしたがって、pKizzy ライブラリフォルダをクラウドストレージ上に保存しておく必要があります。

~/Library/Application Support/ フォルダ中の pKizzy フォルダは、指定の場所に置いておく必要があります。

Dropbox の場合：: Dropbox 共有フォルダ直下に配置

機能

ライブラリの閲覧
アーティクルおよびアタッチメントファイルのプレビュー（対応するファイルフォーマットの場合）

現時点では、編集する機能はありません。あしからず。

0.8 のいま (進行状況)

July 24, 2012:

iPhone アプリ pKizzy Browser が ver.1.1.0 にアップデート。
すでに App Store で入手可能です。
主な変更点は、
- Mobile Me サポートの終了
- キャッシュ処理の改善
- 不具合の修正
といったところ。
一番メインの目的は、Mobile Me サポートを外すこと。
本当は、Mobile Me のサービス終了に合わせて、それに間に合うようにリリースすることを目論んでたんだけど。
Review に落とされたりしているうちに、すっかり遅くなってしまった (^^;

January 17, 2012:

今回は pKizzy 0.9.0、待望 (誰が？) の Lionized version 公開です。
最近ようやく OS を Lion にアップデート。
で、以前に Lion では pKizzy が起動しない不具合を報告していただいていたので、さっそく試してみた。
その結果・・・起動できてしまった (^^;
結局、不具合の原因は分からず。
Lion で build し直すと deprecated の warning が出たけど、起動プロセスとは関係ないはずだし。
今のところ一番考えられるのは、OS の問題か。
僕が試したのは 10.7.2 からなので、それ以前の Lion では何かしらあった問題がすでに修正されたのかもしれない。
今までにも同じようなことがあった気がするし。
という訳で、0.9.0 へのアップデートにあたって、とりたてて何か修正した点というものは無し。
deprecated warning を潰してみた (実は Snow Leopard ですでに deprecate されてたようだけど (^^; ) ことと、Lion で build し直してみた、というぐらい。
ただ、これで、Lion でも起動するのではないかと期待されるので、公開してみます。
実は不具合をいくつか発見しているんだけど、未修正のまま。
１つ目は、table view まわり。
特に、情報パネルの Attachments テーブルまわりのドラッグ＆ドロップ絡み。
たとえば、ファイルをドロップしようとすると一瞬固まり、それ以降はどの view でもドロップを受け付けなくなる。
何も修正した覚えはないし、コードを見直しても何が問題か分からない・・・。
という訳で、今回は放置。
Lion から NSTableView (NSOutlineView も) が大幅に仕様変更されたらしい。
カスタムビューが作り易くなったらしく、その辺に今までなかなか手が出なかった僕としても大歓迎。
しかし、その絡みでの不具合かとちょっと疑い中・・・。
従来の cell-based table もちゃんとサポートされてるはずなんだけど・・・。
あとは、「アプリケーションで開く」が機能しないっぽい。
これもまた改めて・・・。

August 9, 2011:

前々回に、「なんちゃってクラウド化計画」を発表した。
pKizzy のライブラリを、複数の Mac 間で共有することができる。
これが、できてみるとなかなか快適で便利。
こうなると、モバイルデバイスからもアクセスしたくなるよねぇ・・・。
というわけで作ってみました、iPhone アプリ "pKizzy Browser"。

これで、いつでもどこでも、アーティクルを読むことができる！
名前の通り、見るだけで編集までは対応していないんだけど・・・

ちなみに、iPad 専用版はありません。
もし希望する方がいれば、実機を提供していただければ、開発される可能性が高まるかもしれません・・・。

Android にも対応する予定はありません。
Objective-C と Cocoa フレームワーク (Core Data) でコーディングできるなら考えないでもないけど・・・。

クラウドでは、SugarSync にも対応していません。
SDK が Java でしか提供されていないことと、ライセンスにややこしい条項が含まれているようなので・・・。

あしからず。
どうもバグが残っているらしいことも、パフォーマンスを向上できる余地があることも気付いてます。
ただ、とにかく承認されるまでが大変だと思うので、承認を済ませてから修正や改良を加えていく方が、結局は効率がよいんではないかなぁ、と思ってます。 (pKizzy の場合と同様に)
そんなにマメに更新するかどうかはともかく・・・ (^^;

July 28, 2011:

(誰が？)

不具合報告いただきました。
なんと、pKizzy の最新バージョン 0.8.3 は Lion で起動しない模様。
さらに情報いただきました。
旧バージョン 0.7.8 なら (多少表示の乱れ等あるようですが) 問題なく動作するようです。
というわけで、過去バージョンを試せるように、0.8.1-0.8.2 もダウンロードに置きました。 (0.8.0 は手元に見つからず・・・)
試してみたい方は、ダウンロードしてみてください。
で、その結果など報告していただけたら助かります。
0.8 から Bibliographer のバグが修正されていたりするので、できればこのあたりで起動できたらいいんだけどなぁ。
July 29, 2011: 追記
報告いただきましたが、0.8.1, 0.8.2 ともに Lion では動作しないようです。
残念。

テストがユーザーまかせになってしまうのは、申し訳ないです・・・。
もし、こちらでの検証、さらには、Lion 対応バージョン開発を希望される方がいらっしゃれば、Lion 対応 Mac を提供していただければ、早めに実現される可能性が高まるかと思います。
すみません、冗談です・・・ m(_ _)m

June 9, 2011:

「なんちゃってクラウド化計画」

巷では、クラウド化が大流行。 WWDC でも iCloud が発表されたばかり。
データはリモートサーバに置いておいて、どのデバイスからでも同じようにアクセスできる、というのがめちゃ便利。
一度使いはじめると、手放せなくなる。

そうなってくると、pKizzy もクラウド化したくなるのが人情というもの。
複数の Mac から共通のライブラリにアクセスできて、どれかの Mac で内容を変更すると、変更点は自動的に反映されて、別の Mac でも最新の情報にアクセスできる・・・。
素晴らしい！
ま、世間のクラウド化の流れからすると、３周ぐらい周回遅れな気はするけど (^^;

しかし、うちの技術力と開発リソース (要するに時間) からいって、まともに実現しようとすると、いつになるか分からない。
そこで、クラウドストレージサービスを利用した、「なんちゃってクラウド化」を試してみた。
クラウドストレージサービスとしては、たとえば、iDisk/Dropbox/SugarSync とか。
分からない人はググるなりして調べてみてください。

やり方の詳細は上の「なんちゃってクラウド化計画」に書いてます。
試してみると、めちゃめちゃ普通にできてしまった。
そして、便利！

複数 Mac 間でライブラリを共有したい人は、試してみる価値ありかも。
ただしこれは、あくまで「なんちゃって」な裏技なので、使用する場合は、自己責任の上、ご注意を。あしからず。

しかし、いずれは iCloud API を使った本格的なクラウドに移行せざるを得ないのかなぁ・・・。
API を使ったら、本格的なクラウドの実装も簡単になってるんだろうか・・・。

September 18, 2010:

今回は、要望をいただきまして、UI の動作を一部変更 (修正) しました。
メイン・ウィンドウで、アーティクルを選択した時、プレビューにフォーカスが移動しないようになった。

それで何のメリットがあるかというと、テーブルやサムネールで、カーソルキーでアーティクルを切り替えることができる。
これまでだと、いちいちプレビューの方にフォーカスを奪われてしまっていたせいで、カーソルキーだけで次々と切り替えるということができなかった。

以上。
以下、ひとりごと。
そんなフォーカスの切り替えはコーディングした覚えはなかったんだけど、調べてみると、PDFKit の PDFView がやっているようだ。
その中身には手が出ないので、PDFView に PDF をセットする前に first responder を覚えておいて、あとでフォーカスを戻してやる、という風にして解決。

June 23, 2010:

前回拡張したファイル情報編集パネルで、ファイルをサムネイルにドラッグ＆ドロップ可能に。
ファイルが登録されていないアーティクルの場合は「ファイル追加」と、すでにファイルがある場合は「ファイル置き換え」と、同等の動作になります。
要望いただきまして、インクリメンタル・サーチで検索するプロパティに「ファイル名」を含めました。
サーチ起動で現れるボタンバーで、「すべて」または「ファイル名」を選択した時に有効です。
グループ/スマートグループを新規に作成したとき、名前が "untitled" になっていた。
これを、日本語版では「名称未設定」に変更。
Bibliographer マネージャで、プロパティ・タグや HTML タグを挿入できなかった場合があった不具合の修正。

コーティングとしては、現在のテキスト選択位置を基準にして「新しいテキストを挿入」し、「新しい選択範囲を設定し直す」。この順番が逆になってた、凡ミスだった模様。
スマート検索で、ヒット数が多いとき結果の更新に時間がかかりすぎていた不具合の修正。

原因は、スマート検索ウィンドウが暗に保持している group オブジェクトは articleIndex オブジェクトを対多関係で保持している訳だけど、その逆関係で group オブジェクトを設定する処理に時間がかかっていたこと。
これまでは、追加する articleIndex オブジェクトをまとめて group 設定して、その後で group に追加していた。この順番を逆にして、まず group に addObject: してから逆関係を設定するようにすると解決したようだ。
保持していないオブジェクトに逆関係を設定すると時間がかかるってこと？スマートグループでは、同じコード (というか、同じメソッド) を使ってて問題なかったんだけど。
何がどう違うのかは、結局、よく分からないまま。

April 2, 2010:

インクリメンタル・サーチの挙動を修正。単語を複数入力した場合、それらのアンド検索が実行されるように。
これまでは、たとえば「abc def」と入力すると「abc def」という単語を含むアーティクルをヒットしていた。
今バージョンから、「abc」と「def」を両方含むアーティクルがヒットすることになる。
ファイル情報編集機能を拡張。
これまではファイル名変更だけだったけど、ファイルの追加 (PDF 無しアーティクルに)、入れ替え、削除 (して PDF 無しアーティクルに変換) が可能に。

ご利用は、これまで通り、情報パネルの「ファイル名」蘭横、「編集...」ボタンから。

想定している使い道は、たとえば、
最近の文献では、オンラインのみ先行公開されたりするものがある。そういうのは、後日、巻号頁が確定されたときに PDF が差し替えられる。
そういうアーティクルを先行公開の時点で登録してあったら、ファイルが更新された時には、ファイルの差し替えで済ませたいところ。

これまでも、手動でファイル名を合わせて入れ替えて、とやれば可能だったんだけど、やっぱり面倒だし、アプリで対応すべきところかと。
スマート・グループ/検索絡みの内部処理を最適化。

といったところ。
以下、ひとりごと。
インクリメンタル・サーチのアンド検索は、随分以前から実装したいとは思ってた。
単純にスペースで区切るだけなら、わりと簡単。 NSString の componentsSeparatedByString: でも使えばいい。
でも、真面目にやろうとすると、わりと大変。
たとえば、「abc "def ghi"」と入力されたら、「abc」と「def ghi」で検索したい。そのためには "" のくくりを判定処理する必要がある。そうすると、エスケープ「?"」も処理しないといけないし、そしたら、他のエスケープ・シークエンスにも対応しないと・・・だけど、その辺の文法は、正直、あまりよく理解していない・・・。
今回たまたま、Snow Leopard から追加されたらしい NSString のメソッドをみつけた。

- (void)enumerateSubstringsInRange:(NSRange)range options:(NSStringEnumerationOptions)opts usingBlock:(void (^)(NSString *substring, NSRange substringRange, NSRange enclosingRange, BOOL *stop))block

なんじゃこりゃ？ void (^) とか書いてるけど、何のこと？

と思って調べてみた。
実はこれは、Snow Leopard から導入された (?)、ブロック・オブジェクトというものらしい (リンク)。
僕も正直、まだよく分かってないんだけど (^^;
たとえばさっきのメソッドだと、

NSMutableArray *words = [NSMutableArray array];

[aString enumerateSubstringsInRange:NSMakeRange(0, [aString length]) options:(NSStringEnumerationByWords|NSStringEnumerationLocalized) usingBlock:^(NSString *substring, NSRange substringRange, NSRange enclosingRange, BOOL *stop ){
[words addObject:substring];
}

];

とすると、aString が単語に分解され、その数だけ block のループが繰り返される。 substring、substringRange、enclosingRange、stop がブロック内のローカル変数で、分解された文字列は substring で返される。
感覚的には fast enumeration に近い感じ？
で、ここでは単語毎に "words" array に格納する処理をしている。
分解の単位はオプション (ここでは NSStringEnumerationByWords) で指定できて、文字単位や文単位での分割もできる、らしい。

で、これだけだと componentsSeparatedByCharactersInSet: とどう違うのか、という気がするかもしれない。
enumerateSubstringsInRange: options: usingBlock: は、余分な記号やスペースを勝手に取り除いてくれる。
つまりたとえば、「abc."def..ghi"」(ただし . は半角スペース) を入力した時、components... なら「abc」「"deg」「」「ghi"」となるところが、enumerate... だと「abc」「deg」「ghi」としてくれる。

本当は、"" くくりなんかも判別してくれる検索ワード分割の様なオプションがあったらよかったんだけど。わりと需要はありそうだと思うけど、簡単にできるメソッドってないのかな？
今回は、お手軽に単語分割できただけでもありがたい、ということで、実装することにした。
ファイル操作機能も、随分以前から導入しようとは思ってた。
ただ、なかなか適当な UI を思いつかなくて、導入を見送っていた。

今回の UI も、それほどしっくりとはきてないんだけど。
ただ、とりあえず作ってみて使いながらでないとよく分からなかったりするし、公開することにした。
スマート・グループ/検索の内部処理の変更は、主に NSPredicate の扱い。
これまでは、複数条件を AND|OR で組み合わせる場合も、全部文字列で書いてから predicate に変換していた。
それを、(基本は) 単発条件の predicate を、NSCompoundPredicate で合成するにようにしてみた。

そこではまったのが、NSString と NSPredicate でのフォーマットの扱いの違い。
これまではたとえば

NSString *aString = [NSString stringWithFormat:@"%%@ like[cd] '%@'", @"value"];

NSString *bString = [NSString stringWithFormat:aString, @"property"];

NSPredicate *aPredicate = [NSPredicate predicateWithFormat:bString];

とやっていて、つまり、「property like[cd] 'value'」という predicate が作られていた。
これを単純に、

NSString *aString = [NSString stringWithFormat:@"%%@ like[cd] '%@'", @"value"];

NSPredicate *aPredicate = [NSPredicate predicateWithFormat:aString, @"property"];

としてみたところ、同じ結果になるかと思いきや、できてきた predicate は「"property" like[cd] "value"」。
つまり、predicateWithFormat: で代入された値は、value 側と見なされて、勝手に "" が付けられてしまうようだ。
これは「"property" という文字列が "value" という文字列に一致するか」ということだから、当然、結果は false になってしまう。
なので、

NSString *aString = [NSString stringWithFormat:@"%@ like[cd] '%%@'", @"property"];

NSPredicate *aPredicate = [NSPredicate predicateWithFormat:aString, @"value"];

と書けば問題ない。
もう１つ内部処理の問題で、不必要な removeObserver: が残っていた。
たぶん、実害はなかったと思うけど。

バージョン 0.7.x までは、フィルタの設定を table view で (強引に) 実現するために、observer を使ってた。
それが、rule editor を使うことになって必要なくなってたんだけど、observer まわりの不要になったコードを消すのを忘れてた。
table view でフィルタ編集を実現するためにごちゃごちゃと書いたコードがいろいろあって、それはそれで rule editor に移行するのに役に立った部分もあったんだけど。
さぼってた大掃除を、今回すませた・・・はず。

March 12, 2010:

空のグループを選択した状態でインクリメンタル・サーチの検索文字列を変更したとき、グループのカラーリングが更新されない不具合の修正。
Import Date のスマート・グループ/検索フィルタが機能するようになった。
実はさらにさかのぼって、ページ数のフィルタも機能するようになっているはず。

といったところで、以下、ひとり言。
Import Date のフィルタは、NSDate オブジェクトを評価する predicate の書式が分からないのが問題だった。
これはたとえば、ある日時 (compDate) より前かどうかを判定する場合、
~~[NSPredicate predicateWithFormat:@"importDate < CAST(%.1f, ?"NSDate?")", [(NSDate *)compDate timeIntervalSinceReferenceDate] ];~~
のようにして predicate を作ってやればよかったらしい。
CAST(%1f, ?"NSDate?") が NSDate を数値に変換してくれるので、あとは数値の評価をすればよい、らしい。
あまりちゃんとは理解できてないんだけど (^^;

April 14, 2010: 追記
NSDate の predicate の書き方は、もっとシンプルでよかったらしい。
たとえば、プロパティ importDate が NSDate オブジェクト compDate で指定される日時以前、という predicate を作りたい場合なら、

NSPredicate *pred = [NSPredicate predicateWithFormat:@"importDate < %@", compDate];

とすればよかったらしい。この predicate の description を調べると、たとえば

importDate < CAST(292734000.000000, "NSDate")

のようになっているので、内部的には CAST を使った表現になっているのかもしれない。
結局、ちゃんとは理解できてない (^^;
以前しくじっていたのは、

NSString *predStr = [NSString stringWithFormat:@"importDate < %@", compDate];

NSPredicate *pred = [NSPredicate predicateWithFormat:predStr];

のように、一度 NSString で記述しようとしていたのがいけなかったようだ。
predicateWithFormat: で右辺値を指定するのが肝、か。
ページ数フィルタは、アーティクルが暗にnumberOfPages プロバティを持っていて、pages プロバティが変更されるたびに連動して更新している。
Twitter アカウントつくってみました。 kokamOnJuno です。
開発ネタもあまりないし、つぶやく頻度は高くはならないと思うけど。
いまいち使い方もよく分かってないし (^^;

それでも作ってみた１番の目的は、要望・不具合報告なんかの受け付け窓口になればいいかな、と。
要望をもらったところで、僕の技術力や開発リソース (要するに時間) に限りがあるので、何でもすぐに対応します、というわけにはいかないだろうけど。
ただ、開発する側からすれば、案外簡単に実現できることもあったりするので、お気軽に連絡いただければと思います。

窓口としては、これまでもメールアドレスを公開してるし、掲示板やブログなんかの手もあるわけだけど。
最近流行りの Twitter の様子を見てると、お手軽でよさそうかな、と。

で、せっかくなので、いろいろフォローしてみたいとは思うんだけど、探し方がいまいちよく分からない。
アカウントをまとめてるような、電話帳のようなサイトとかってないんだろうか。そこそこ以上の有名人だけでいいから。
Cocoa 開発関係とかでいい人がいたら、教えてもらえると嬉しいです。

February 17, 2010:

スマート・グループ/検索の条件設定インターフェイスを変更。
ずっと NSTableView でお茶を濁していましたが、Leopard から導入された NSRuleEditor に変更。
それっぽくなったんではないでしょうか。

日本語だとやや表示が乱れるところもありますが。
たとえば右のスクリーンショットで、「すべて」の左や「が右の文字列を含まない」の右に無駄なスペースが・・・。

動作も完全に思い通りとはいってないですが、いちおう動いたところで公開とします。
bibliographer manager の不具合の修正が２つ。

まず、新たにトークンを挿入するとき、位置がずれる不具合の修正。
問題は、選択位置 (カーソル位置) の取得法でした。
詳細は下で。
token のメニューを選択した時、メニュー表示内容が反映されていなかった不具合の修正。
プレビューには反映されていたので、中身は変更されてました。

といったところ。
以下、ひとり言。
NSRuleEditor を使うためには、メニューの階層構造を提供しないといけない。
これがなかなか厄介で、Leopard 時代からいろいろと悩んでた。
Snow Leopard になってクラスが充実したかと思ったんだけど、よく調べてみると、実質的にはほとんど変化無し。
ただ、それとは別に、web でサンプルを見つけることができたので、それを参考にして試してみた。

サンプルなどを見ると、一番簡単な実装法は、メニュー項目 (とその他の付随情報) のツリー構造を dictionary に格納しておく方法。
これだと、dictionary の内容をリソース・ファイルに保存しておくこともできて、コードの修正無しでメニュー項目を変更できたりもする。
ただ、そのままの挙動では使い物にならないと思う。メニューを変更する度に、テキスト・フィールドに入力した文字列がクリアされてしまったりするし。もちろんコーディングで回避はできる。

僕の場合はさらに、凝ったことをやろうとした。
たとえば、スマート・グループ/検索のフィルタには独自のオブジェクトを用意しているので、Rule Editor での編集は、フィルタ・オブジェクトの構成や内容と連動しないといけない。
それから、メニュー構造は単純なツリー構造ではなくて、プロパティのタイプ (文字列とか数値とか) に依存していて、そのタイプも任意の順に並ぶ。
もちろん入力した文字列も、プロパティのタイプが変わらない限り、保存させたい。
そんなこんなを実現しようとコーディングすると、けっこうなごちゃごちゃ具合になってしまった。もっと簡単な実装法もあるかもしれない。
bibliographer manager の不具合修正。
NSTokenField には selectedRange のようなメソッドがなくて、簡単に選択範囲 (カーソル位置) を取得することはできない。
じゃどうするかというと、内部の NSText の selectedRange メソッドを使えばよい。
しかし、NSTokenField には、内部の NSText に直接アクセスできるメソッドもない。 (一時的に生成されるだけでインスタンス自体が固定されず、ころころ入れ替わるから？)
じゃどうするかというと、テキスト編集された時の notification をつかまえて、NSNotification に含まれる発信元 NSText オブジェクトに対して問い合わせればよい。

具体的には、NSTextView の notification である NSTextViewDidChangeSelectionNotification を observe する。
ただし、NSTokenField 内部の NSTextView オブジェクトを指定できないので、対象オブジェクトは nil にしておく。
そうすると、すべての NSTextView の編集に反応してしまうので、[textView isDescendantOf:tokenField] として判定する。
アプリ中のあらゆるテキスト編集に反応してしまうのは無駄なようにも思うけど、仕方がない。

これまでは NSControl の隠しメソッド textViewDidChangeSelection: を使ってたんだけど、その後仕様変更されたのか、いつの間にか (Leopard の時には) 使えなくなっていたようだ。
最近、subversion を使ったバージョン管理を使い始めた。
レポジトリは iDisk に置いて、自動で同期/バックアップできるようにしてる。
これ、なかなか便利。

ただし、.nib を編集した時に同期がうまくいかない。
何がどうしたのかとしばらく悩んだんだけど、いろいろ調べた結果、Interface Builder のファイル・フォーマットとして .nib ではなく .xib を使わないといけないことが分かった。(リンク)
ざっとまとめると、.nib は一見したところ１つのファイルに見えているけど、その実態は複数のファイルを含んだフォルダで、いわゆるパッケージというやつ。バージョン管理は .nib をディレクトリと認識して扱おうとするので、おかしくなる。 .xib は同じ内容を xml に書き下したもので、バージョン管理に必須のテキスト比較なんかの処理が適用できるようになっている。 .xib もビルドの段階で .nib に変換し直され、アプリには .nib がバンドルされることになる。
で、使い分けとしては要するに、バージョン管理するなら .xib、過去のアプリとの互換性が必要なら .nib、特に理由がなければ今後は .xib を使っとけ、ということらしい。

.xib ファイルフォーマットは最近の Interface Builder で導入されていて、.nib と何が違うんだろうかと訝しんでいたんだけど、こういう風に使い分けたらいいわけね。
今回主にやった修正は、NSRuleEditor も NSTokenField の方も、Snow Leopard 限定のやり方ではなくて、Leopard でも対応できたらしい。
ただ、成り行き上 10.6 対応の修正作業もいろいろしてしまったので、このまま Snow Leopard 専用でリリース。
まだの人も、この際、アップグレードしちゃいましょう。 Leopard 持ってるならそれほど高くもないし。別に Apple の回し者ではない (^^;