タブ付きインターフェイスを介して単一のウィンドウに複数のドキュメントを表示できるアプリケーションを作成したいと考えています。NSDocument アーキテクチャ (Cocoa ドキュメントベースのアプリケーション テンプレート) を避けるべきですか? 私が知る限り、ドキュメントごとに 1 つ以上のウィンドウしかサポートしていませんが、その逆はありません。
私はしばらくこの問題に取り組んできましたが、NSDocument アーキテクチャ上にアプリケーションの多くを構築しましたが、複数のドキュメントを 1 つのウィンドウに関連付ける良い方法がわかりません。
編集: 基本的なドキュメント ウィンドウに加えて、プロジェクト ドキュメント ウィンドウが必要です。このレベルの複雑さで、NSDocument アーキテクチャをハッキングする価値はありますか? Apple は NSDocument アーキテクチャを使用して (このように動作する) Xcode を作成しましたか?
私は同じ種類のプロジェクトを持っています — 異なる独立したドキュメントを 1 つのウィンドウに表示し、ドキュメントを切り替えることができるサイドバーを付けたい — ということで、自分で少し検索してみました。
Cocoadev のDocument Based App With One Window For All Documentsリファレンスを読んで、興味深いリードを見つけました。MikeTrent の回答から、NSDocument を使用することは非常に実行可能な方法であることがわかります。NSDocumentController をサブクラス化するだけです。
また、ボーダレスの子ウィンドウを使用するという Abhi のアイデアも気に入っています。
この場合、NSDocument ベースのアーキテクチャを使用することは必ずしも悪い考えではありません。ただし、かなりのハクエリが必要になる場合があります。
NSDocument をサブクラス化するだけでなく、兄弟の NSDocumentController をサブクラス化することはめったにありません。これが完了したら、 -makeWindowControllers やその他のウィンドウ関連メソッドの呼び出しをハイジャックして回避するのは簡単なことです。これにより、ドキュメントの「ウィンドウ」を好きな方法でラップできますが、ドキュメントの利点は保持されます-ベースのアプリケーション。
まだ試していませんが、計画している別の手法は、各ドキュメントに縁なしウィンドウを表示することです。このように、1 つのドキュメントには 1 つのウィンドウがあり、表示される場合と表示されない場合があります。
次に、実際のウィンドウの境界線を含むラッパー ウィンドウと、どの境界線のないドキュメント ウィンドウを表示するかを切り替えるコントロールを用意します。ドキュメント ウィンドウはラッパーの子ウィンドウであり、ウィンドウが移動/最小化/閉じられたときに両方がリンクされるようにします。
ボーダーレス ドキュメント ウィンドウごとに、ラッパー ウィンドウにはプレースホルダー ビューがあり、サイズを変更するとドキュメント ウィンドウのサイズが変更され、ドキュメント ウィンドウのビューがレスポンダー チェーンに挿入されます (プレースホルダー ビューに送信されたイベントはドキュメントに送信されます)。プレースホルダーの親ビューに渡される前のウィンドウのビュー)。
細かい部分はまだ解決していませんが、このアプローチはうまくいくと思います。
数年前に NSDocument アプリを 1 つのウィンドウのタブ付きインターフェイスに押し込もうとしましたが、数か月後に非常にイライラしてしまい、戻ってドキュメント アーキテクチャの部分をリファクタリングしました。不可能ではありませんが、非常に多くの問題を回避することになり、最終的な結果は適切な NSDocument アプリにほとんど似ていません。Cocoa フレームワークを破壊するためだけに大量のコードを作成するよりも、必要な部分だけを書き直す方がよいでしょう。