Leopard 上の NSTreeController は挙動不審？

Leopard において NSTreeController の挙動が素直でない現象に出くわした。 Tiger で同じバイナリは素直な動作をするので、バグなのか、仕様の変更なのか。。。さっぱいり分からない。

途中まで Tiger 上で開発して放り投げておいたものを、Leopard 上で再開した途端、地雷原に突っ込みまくっている。。。

でだ、問題は NSTreeController は、childrenKeyPath の先のモデルを、Array として扱うのか、Set として扱うのか？

簡単なサンプルを作ってみた。

MoiView.zip

1. モデルに Core Data を使わずにNSMutableDictionary を使い、newObject/newChildObject で単純な初期を行う。このとき children には NSMutableArray のインスタンスを割り当てている。
2. NSTreeController と NSOutlineView を一般的な binding をしてある。
3. 五つのボタンのそれぞれのアクションに、NSTreeController のadd:/addChild:/addInsert:/addInsertChild:/remove: を接続して、同時に、それぞれのボタンの enabled に canXXX をbindingする。
4. 別のボタンに、NSTreeController に rearrangedObjects を実行するアクションを接続する。
5. こちの挙動の対処の有無のチェックボックスをつける。

トップレベルに追加(add:)や挿入(insert:)を沢山した後、rearrangedObjects を呼び出しても、項目の順序は変化しない。これは、Tiger でも Leopard でも同じ。

トップレベルよりしたの階層で、追加(add:/addChild:)や、挿入(insert:/insertChild:)を沢山した後、rearrangedObjects を呼び出すと、項目の順序は変化しないはずなのだが、僕のLeopard の環境では変化する。

再現性もある。モデル上では insert:はadd:として、insertChild:はaddChild:として振る舞う。。。

でだ、問題は insertObject:atArrangedObjectIndexPath:でも同じように、モデル上では indexpathで指定された階層の最後尾に追加される。。。

ビューとモデルでは違うのは分かるが、Core Data を使わずに適当なクラスを使っているのだから、childrenKeyPath の先を Array として扱って、挿入位置もモデルに反映してほしいのだが、、、。

困った。 仕様なのか、バグなのか、環境なのか、分からん。 最初の話だが、childrenKeyPath の先は、Core Data のエンティティを使う場合は Set であり、クラスを使う場合は出来る限りArray であると思うのだが、違ったのか？ まぁ、抜け道はあるから良いのだけども。 そのうち、なんか出てくるかぁ。

追記 (2008/06/21)

MacOSX 10.5.3 になって直ぐには確認していないので、どの時点で改良されたか分からないが、近々の最新状態で確認したところ、insert系のビューとモデルの操作の奇妙な差異が改善された。

どうもバグだったらしい。

要求条件が 「MacOSX 10.5.3 以上」とか見るが、どうもこれらの原因なのかなぁ。。。

よきことかなぁ。