日本人なら「ココア」でしょ？

developer.apple.comにあるココアドキュメントを勝手に日本語化しちゃうスレです。
Foundationは荻原本見ればわかると思うんで、対象は「ApplicationKit」かと思うんだけどどうでしょ？

ApplicationKitのドキュメントはこちら。
http://developer.apple.com/techpubs/macosx/Cocoa/Reference/ApplicationKit/ObjC_classic/AppKitTOC.html

とにかく日本語の資料がないcocoa開発環境を、みんなで改善しちゃいましょう！
＊「Objective-c」を「客観的C」とかいう翻訳ソフトを使うのは極力なしってことで。

⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´いまだーー！！２ｹﾞｯﾄｵｫｫ
　　　　　　ｽﾞｻｰｰｰｰ

あほ。

4!

適用キット
客観的C アピ参照

あとはよろしく！

日本人なら「ﾐﾛ」でしょう。

日本人なら「メローイエロー」でしょう。

だれもやる気無しか・・・？

手始めに何からやる？　それだけでも決めてくれ >>1

これってアップルの許可を得ず、勝手にやっちゃっていいのかな？
あとやるならサイトたてて、2chに限定しないで
ボランティア形式の穴埋め形式で広くやった方がいいと思う。

できればサイト構成も訳元と同じにして、
それぞれのページから訳元ページへのリンクもはっておく。
そうしておけば、翻訳部分が不完全でも
日本人ならまずその翻訳ページをチェックするというふうになるだろう。

手始めにNSOpenPanelの日本語化に着手しました
ただ、もともとプログラミング自体初心者なんで、適切な訳ができてる自信まったくなし

まあ、翻訳サイトよりはましかと。

協力したいがどうすればいいか分からん（w
このスレに直接カキコでいいかな？

スレタイ悪過ぎ

サイト立てちゃえば楽なんだろけど、あまり目立つとアップルから文句いわれそうなんで（笑）

進行方法は、「〜やります」の宣言をして、終わったらここにコピペする・・・というのでどう？


ps.いま、携帯からなんで反応遅いです。ゴメンヨ

名スレの予感

うーん、アップルってこういうの許可出さないのかなぁ。
個人的には正式な許可を得た方が、
気持ちのすっきり具合とやる気が大きく増すと思うのだが。
無許可だと最悪の場合、削除命令されて水の泡だよ。。

じゃ、おれ取り敢えずNSToolbarやるわ。

イントロダクション

アプリケーション キットはあなたがあなたのイベント駆動のグラフィックユーザーインタフェースを
実装するために必要とするすべてのオブジェクトを含んでいるフレームワークである：ウインドウ、パネル、
ボタン、メニュー、スクローラーとテキストフィールド。 それがスクリーンで効率的に絵を描いて、ハード
ウェア装置とスクリーンバッファと通信して、描画の前にスクリーンのエリアをクリアして、そしてビュー
をクリップするにつれて、アプリケーション キットはあなたのためのすべての細部を処理する。 アプリケー
ション キットでのクラスの数は初めは気力をくじくように思われるかもしれない。 しかしながら、たいてい
のアプリケーション キットクラスがあなたが間接的に使うサポートクラスである。 あなたは同じくあなたが
アプリケーション キットを使うそのレベルにおいて選択を持っている：

＊ ユーザーインタフェースオブジェクトからあなたのアプリケーションオブジェクトへの接続を作成するために
インタフェースビルダーを使う。 この場合、あなたがする必要があるすべてはあなたのアプリケーション
クラスを実装することである- それらのアクションとデリゲートメソッドを実装する。 例えば、ユーザーが
メニュー項目を選択するとき、呼び出されるメソッドを実装しなさい。

＊ プログラム的にもっと多くのアプリケーション キットクラスとプロトコルとの精通を必要とするユーザー
インタフェースをコントロールする。 例えば、ユーザーが1つのウインドウから別のものへアイコンを
ドラッグすることを可能にすることは若干のプログラミングと NSDragging... プロトコルの精通を必要とする。

＊ NSView あるいは他のクラスをサブクラスを派生することによって、あなた自身のオブジェクトを実装する。
NSView をサブクラスを派生するとき、あなたはグラフィックス関数を使ってあなた自身の描画メソッドを書く。
サブクラスを派生することはアプリケーション キットが作動する方法のもっと深い理解を必要とする。

アプリケーション キットについてさらに多くを習得するために、デリゲートメソッドに綿密な注意を払って
NSApplication 、 NSWindow と NSView クラス仕様書を再検討しなさい。 アプリケーション キットが
作動する方法のもっと深い理解のために、 NSResponder と NSRunLoop （ NSRunLoop がファンデーション
フレームワークにある）の仕様書を見なさい。

>19
おつかれさまです。
HTMLに整形しますので、まとまったらどこかにうぷします。

>14
スレタイは、『やっぱり「Cocoa」じゃなくて日本語「ココア」がいいよね』という意味でした。
わかんにくいね・・・反省。

うお、なんだか嬉しいスレだ。

いちおう、discussion boardで聞いてみるとか。
悪いことはしてないのだから、おこられはしないと思うけど..。

何か良すれの予感だね。
何も協力できないけどとりあえず応援揚げ

アプリケーション キットクラスとプロトコル

アプリケーション キットは大きい；それは125以上のクラスとプロトコルを構成する。 クラスはすべて
ファンデーションフレームワークの NSObject クラスから派生する（図1を見る）。 次のセクションは
手短かにアプリケーション キットがそのクラスとプロトコルを通して扱うトピックスの若干を記述する。

図1　　アプリケーション キットの Cocoa Objective-C クラス階層

アプリケーションをカプセル化する

すべてのアプリケーションがメインイベントループをコントロールして、アプリケーションのウインドウと
メニューの記録を保持して、適切なオブジェクト（すなわち、それ自身あるいはそのウインドウの1つ）へ
イベントを分配して、 autorelease プールをセットアップして、そしてアプリケーションレベルイベントの
通知を受信するために NSApplication の１つだけのインスタンスを使う。 NSApplication オブジェクトが、
アプリケーションが起動するかあるいは終わるとき通知されて、隠すかあるいはアクティベートされて、
ユーザーによって選ばれたファイルを開く、などを行うデリゲート（あなたが割り当てるオブジェクト）を
持っている。 NSApplication オブジェクトのデリゲートをセットして、そしてデリゲートメソッドを実装
することによって、 NSApplication のサブクラスを派生することなしに、あなたはあなたのアプリケーション
の振舞いをカスタマイズする。

一般的なイベントハンドリングと描画

NSResponder クラスはレスポンダチェーン、ユーザーイベントに応答するオブジェクトの順序づけられた
リストを定義する。 ユーザーがマウスをクリックするか、あるいはキーを押すとき、イベントが生成されて、
そしてそれに「応答する」ことができるオブジェクトの検索においてレスポンダチェーンを上にのぼって渡される。
イベントを処理するどんなオブジェクトでも NSResponder クラスから継承しなくてはならない。 コアアプリケー
ション キットクラス、 NSApplication 、 NSWindow と NSView は NSResponder から継承する。

NSApplication オブジェクトが NSWindow オブジェクト − アプリケーションに帰属するそれぞれのウインドウの
ためのもの − のリストを維持する、そしてそれぞれの NSWindow オブジェクトが NSView オブジェクトの階層を
維持する。 ビュー階層は描くこととウインドウの中のイベントを処理することのために使われる。 NSWindow
オブジェクトがウインドウレベルイベントを取り扱って、そのビューに他のイベントを分配して、そしてその
ビューのための描画エリアを提供する。 NSWindow オブジェクトが同じくあなたがその振舞いをカスタマイズ
することを可能にしているデリゲートを持っている。

NSView はウインドウで表示されるすべてのオブジェクトのための抽象クラスである。 すべてのサブクラスは
グラフィックス関数を使っている描画メソッドを実装する；これはあなたが新しい NSView を作成するとき
オーバーライドする主要なメソッドである。

パネル

NSPanel クラスはあなたが短期的で、グローバルな、あるいは情報を催促する表示をするために使う NSWindow
のサブクラスである。 例えば、あなたはエラーメッセージを表示するか、あるいは注目に値するかあるいは異常
な状況に対する応答のためにユーザーに問い合わせるために、 NSWindow のインスタンスよりどちらかと言うと、 NSPanel のインスタンスを使うであろう。 アプリケーション キットは、書類を保存して、開いて、そしてプリント
するために使われる、セーブ、オープンと印刷パネルのような若干のあなたのための共通のパネルを実装する。
これらのパネルを使うことは共通の操作のためのアプリケーションをを越えてユーザーに一貫した
「ルックアンドフィール」を与える。

メニューとカーソル

NSMenu 、 NSMenuItem と NSCursor クラスはあなたのアプリケーションがユーザーに表示するメニューと
カーソルの外見と振舞いを定義する。

ビューのグループ化とスクローリング

NSBox 、 NSScrollView と NSSplitView クラスは他のビューオブジェクトあるいはウインドウの中のビューの
コレクションにグラフィックの「アクセサリー」を提供する。 NSBox クラスで、あなたはウインドウの中の
要素をまとめて、そしてグループ全体の周りに輪郭を描くことができる。 NSSplitView クラスはあなたに、
それぞれのビューに共通の領域の若干の量を配分して、垂直に、あるいは水平にビューを「積み重ねさせる」；
スライドするコントロールバーがユーザーにビューの間のなわばりを再分配させる。 NSScrollView クラスと
そのヘルパークラス NSClipView は、ユーザーにスクロールを始めて、そしてコントロールさせたグラフィック
のオブジェクトと同様、スクローリングメカニズムを提供する。 NSRulerView クラスはあなたが
スクロールビューにルーラーとマーカーを加えることを可能にする。

アプリケーションをコントロールする

NSControl と NSCell クラスとそれらのサブクラスは、ユーザーがあなたのアプリケーションの若干の外観を
コントロールするためにグラフィカルに操ることができるボタン、スライダーとブラウザのようなユーザー
インタフェースオブジェクトの共通のセットを定義する。 特定のコントロールが何に影響を与えるかは正に
あなた次第である：コントロールが「触れられる」とき、それはターゲットオブジェクトへアクション
メッセージを送る。 あなたのアプリケーションあるいは他のオブジェクトにコントロールオブジェクトから
コントロール-ドラッグすることによって、あなたはこれらのターゲットとアクションをセットするために
一般にインタフェースビルダーを使う。 あなたはプログラム的に同じくターゲットとアクションをセット
することもできる。

NSControl オブジェクトが描画と処理イベントの細部を実装するひとつあるいはもっと多くの NSCell
オブジェクトと結び付けられる。 例えば、ボタンが NSButton オブジェクトと NSButtonCell オブジェクト
両方を含む。 機能性のこの分離の理由は主に NSCell クラスが NSControl クラスによって再利用されること
を可能にすることである。 例えば、 NSMatrix と NSTableView は異なったタイプの複数の NSCell オブジェ
クトを含んでいることができる。

これが駄スレで終了しなければいいなぁ・・・

テーブル

NSTableView クラスはローとコラムフォームでデータを表示する。 NSTableView はデータベースレコード
を表示ために理想的であるが、そうするために限定されていない、そしてそこでローがそれぞれのレコードに
対応する、そしてコラムがレコード属性を含む。 ユーザーは個々のセルを編集して、そしてコラムを配置替え
することができる。 そのデリゲートとデータソースオブジェクトをセットすることによって、あなたは
NSTableView オブジェクトの振舞いと内容をコントロールする。

テキストとフォント

NSTextField クラスはシンプルな編集可能なテキストフィールドを実装する、そして NSTextView クラスは
もっと多くのより大きいテキスト体のための包括的な編集機能を提供する。

NSTextView 、抽象 NSText クラスのサブクラス、は Cocoa の拡張されたテキストシステムへのインタフェース
を定義する。 NSTextView はリッチテキスト、アタッチメント（グラフィックス、ファイルと他）、入力管理と
キーバインディングとマークが付いたテキスト属性をサポートする。 NSTextView はフォントパネルとメニュー、
ルーラーと段落スタイル、サービス能力（例えば、スペルチェックサービス）とペーストボードとともに働く。
NSTextView は同じく委任と通知を通じてカスタマイズすることを許す − あなたはめったに NSTextView の
サブクラスを派生する必要がない。 あなたは、 NSTextField 、 NSForm と NSScrollView のような、
インタフェースビルダーのパレット上のオブジェクトがすでに NSTextView オブジェクトを含んでいるので、
同様にめったにプログラム的に NSTextView のインスタンスを作成しない。

NSTextStorage 、 NSLayoutManager 、 NSTextContainer と関連したクラスを使っていっそう強力な、
そしていっそう創造的なテキスト操作（円の中にテキスト表示することのような）をすることは同じく可能である。

NSFont と NSFontManager クラスはフォント・ファミリー、サイズとバリエーションをカプセル化して、
そして管理する。 NSFont クラスはそれぞれの別個のフォントのための１つだけのオブジェクトを定義する；
効率のために、どちらかと言うと大きくあり得るこれらのオブジェクトはあなたのアプリケーションでの
すべてのオブジェクトによって共有される。 NSFontPanel クラスはユーザーに提示されるフォント指定パネル
を定義する。

グラフィックスとカラー

クラス NSImage と NSImageRep は、ディスクでファイルでストアされて、そしてスクリーンで表示される
イメージに容易に、そして効率的にアクセスすることをあなたを許して、グラフィックのデータをカプセル化する。
NSImageRep サブクラスがそれぞれどのようにソースデータの特定の種類からイメージを描くべきか知っている。
イメージの提示方法は大いにそれが表示したハードウェアによって影響を与えられる。 例えば、特定のイメージが
カラーモニターで良く見えるかもしれない、しかし単色のためにあまりにも「高価で」であるかもしれない。
イメージクラスを通して、あなたは、表示デバイスの特定のタイプに適しているそれぞれの表現をとる同じイメージ
の表現をまとめることができる − いずれの表現を使うべきかについての決定は NSImage クラスそれ自身に任せられ
ることができる。

カラーがクラス NSColor 、 NSColorPanel 、 NSColorList 、 NSColorPicker と NSColorWell によってサポート
される。 NSColor はカスタムのものを含んでカラーフォーマットと表現の豊富なセットをサポートする。
他のクラスはたいていインタフェースクラスである：それらはユーザーが色を選択して、そして適用することを
可能にするパネルとビューを定義して、そして提示する。 例えば、ユーザーはうまくカラーパネルからどんなカラー
でも色をドラッグすることができる。 NSColorPicking プロトコルはあなたに標準カラーパネルを拡張させる。

ドラッグする

あなたのパートで極めて少しのプログラミングで、カスタムのビューオブジェクトがどこにでもドラッグ・アンド・
ドロップされることができる。 NSDragging... プロトコルに従うことによって、オブジェクトがこのドラッグ
メカニズムのパートになる：ドラッグ可能なオブジェクトが NSDraggingSource プロトコルに従う、そして
ディスティネーションオブジェクト（ドロップのレシーバ）が NSDraggingDestination プロトコルに従う。
アプリケーション キットはマウスを追跡して、そしてドラッグされたイメージを表示することについての
すべての細部を隠す。

印刷とファクス

NSPrinter 、 NSPrintPanel 、 NSPageLayout と NSPrintInfo クラスはあなたのアプリケーションがその
ウインドウとビューで表示する情報を印刷し、ファクスで送ることのための手段を提供するために一緒に働く。
あなたは同じく NSView の EPS 表現を作成することができる。

ファイルシステムにアクセスする

ディスクでファイルあるいはディレクトリに対応するオブジェクトを作成するために NSFileWrapper クラスを
使いなさい。 NSFileWrapper はメモリの中のファイルの内容を持つであろう、それでそれが表示され、変更されて、
あるいはもう1つのアプリケーションに送信されることができる。 それは同じくファイルをドラッグするか、
あるいはアタッチメントとしてそれを表現するためのアイコンを提供する。 あるいはファイルとディレクトリ内容に
アクセスして、そして列挙するためにファンデーションフレームワークでの NSFileManager クラスを使いなさい。
NSOpenPanel と NSSavePanel クラスは同じくファイルシステムへの都合が良い、そしてよく知られたユーザー
インタフェースを提供する。

他のアプリケーションとデータを共有する

NSPasteboard クラスはペーストボード、それを使うことを望むどんなアプリケーションにとってでも利用可能な
このデータを作ってあなたのアプリケーションからコピーされるデータの倉庫、を定義する。 NSPasteboard は
よく知られたカットコピーペースト操作を実装する。 NSServicesRequest プロトコルは登録されたサービスによって
アプリケーションの間に渡されるデータを伝達するためにペーストボードを使う。

スペルチェック

NSSpellServer クラスはあなたにスペルチェックサービスを定義して、そして他のアプリケーションに対する
サービスとしてそれを提供させる。 スペルチェックサービスにあなたのアプリケーションを接続するために、
あなたは NSSpellChecker クラスを使う。 NSIgnoreMisspelledWords と NSChangeSpelling プロトコルは
スペルチェックメカニズムをサポートする。

ローカリゼーション

もしアプリケーションが世界の1以上の部分で使われるなら、そのリソースは、言語、国、あるいは文化的な区分
のために、カスタマイズされるか、あるいは「ローカライズされる」必要があるかもしれない。
例えば、アプリケーションが文字ストリング、アイコン、 nib ファイル、あるいはコンテキストヘルプの個別の
日本語、英語、フランス語、そしてドイツ語の版を持つ必要があるかもしれない。 特定の言語に特定の
リソースファイルがバンドルディレクトリ（「 .lproj 」拡張子を持っているディレクトリ）のサブディレクトリ
で集められる。 通常あなたはインタフェースビルダーを使ってローカリゼーションリソースファイルをセットアップ
する。 もっと多くのローカリゼーションについての情報に関して NSBundle 付加と NSBundle クラスの仕様書を
見なさい。（ NSBundle がファンデーションフレームワークにある）

2002年のアップル・コンピュータ社。 （2002年2月22日、発行）

>19
長文、お疲れ様〜。

ようやく、NSOpenPanelが２／３終わったとこ。
わかっちゃいたがやっぱ大変だね。

>>14
日本人なら「Cocoa」じゃなく「ココア」でしょ？
って事で邦訳を示唆したかったんでないかな。…って既に承知でしたか。

協力できないのが申し訳ないけれど、頑張ってMr.オクレ。

あとちょっと〜　花見行ってたら遅くなっちゃったよ。

このスレの1が、日本語化スレの1さんの様に神になれるかは、
きちんとしたsiteを作れるかどうかだろうな。
そうなれば協力するよ。

ただ、失礼ながら19氏の様な直訳的日本語はやめてほしい。
例えば、主語のyouを「あなたは」って訳すのは日本語として変。
普通、そんな表現は日本語ではしないだろ？

正直ですます調で書いてくれると読みやすいんですが・・・
漏れだけですか？（w

>>32
ちょっとおもうね

NSOpenPanel

以下を承継します：
NSSavePanel : NSPanel : NSWindow : NSResponder : NSObject

次のものに準拠します:
NSCoding (NSResponder)
NSObject (NSObject)

以下で宣言されています
AppKit/NSOpenPanel.h

このクラスの特徴

NSOpenPanelはココアユーザインターフェイスを用いたパネルを提供します。アプリケーションはパネルを使ってユーザーに簡単に開きたいファイルを選択させることができます。パネルはモーダルなものとしてのみ開くことができます。

プログラミング・トピックス

　FileManegement

メソッドタイプ

　　共有されたインスタンスを得る
+ openPanel

パネルを開く
-beginSheetForDirectory:file:types:modalForWindow:modalDelegate:didEndSelector:contextInfo:
- runModalForDirectory:file:types:

- runModalForDirectory:file:types:relativeToWindow:
- runModalForTypes:

　ユーザーの選択したファイル名を得る
- filenames

　パネルで選択できる対象を設定する
- setCanChooseFiles:
- canChooseFiles
- setCanChooseDirectories:
- canChooseDirectories
- setResolvesAliases:
- resolvesAliases

　複数選択の可否を設定する
- setAllowsMultipleSelection:
- allowsMultipleSelection


クラスメソッド

------------------------------------------------------------------------

openPanel

+ (NSOpenPanel *)openPanel

「リサイクルされた」NSOpenPanelを返します。いままでインスタンスが作られたことがない場合は、新しく作成した後にそれを返します。

------------------------------------------------------------------------

インスタンスメソッド

------------------------------------------------------------------------

allowsMultipleSelection

- (BOOL)allowsMultipleSelection

レシーバーとなったブラウザが、ユーザーに複数ファイル（もしくはディレクトリ）を一度に選択することを許すかどうかを返します。複数選択が許される場合、filenameメソッド（これはNSSavePanelから承継されます）は、
一つのファイルが選択された場合にのみnilでない値を返します。これに対して、NSOpenPanelのfilenamesメソッドはたとえ一つのファイルのみが選択されたのであっても、常に選択されたファイルを返します。

こちらも御覧下さい： - filename(NSSavePanel) , - filenames , - setAllowMultipleSelection:

------------------------------------------------------------------------

beginSheetForDirectory:file:types:modalForWindow:modalDelegate:didEndSelector:contextInfo:

- (void)beginSheetForDirectory:(NSString *)pathfile:(NSString *)nametypes:(NSArray *)fileTypesmodalForWindow:(NSWindow *)docWindowmodalDelegate:(id)delegatedidEndSelector:(SEL)didEndSelectorcontextInfo:(void *)contextInfo

指定されたウインドウ上でシートオープンパネルを開きます。モーダルセッションが終了したとき、didEndSelectorがデリゲートとして実行されます（この際、contextinfoを引数とします）。didEndSelectorは次の署名を行っている必要があります：

- (void)openPanelDidEnd:(NSOpenPanel *)sheet returnCode:(int)returnCode contextInfo:(void *)contextInfo

返される値はNSCancelButtonあるいはNSOKButtonのいずれかでしょう。

------------------------------------------------------------------------

canChooseDirectories

- (BOOL)canChooseDirectories

レシーバーがディレクトリーを選択することができるかを返します。

こちらも御覧下さい: - setCanChooseDirectories:
------------------------------------------------------------------------

canChooseFiles

- (BOOL)canChooseFiles

レシーバーがファイルを選択することができるかを返します。

こちらも御覧下さい: - setCanChooseFiles:
------------------------------------------------------------------------

filenames

- (NSArray *)filenames

選択されたファイルおよびディレクトリの絶対パスを含んだ配列（NSStringオブジェクト）を返します。
複数選択が許されていない場合、この配列は一つの名前だけを含みます。このfilenamesメソッドはユーザーが選択したファイルまたはディレクトリの名前を得る方法としては、NSSavePanelのfilenameメソッドよりも望ましいです。

こちらも御覧下さい: - URLs
------------------------------------------------------------------------

resolvesAliases

- (BOOL)resolvesAliases

レシーバーがエイリアスを解決するか（エイリアスをエイリアスとして返すのか、それとリンクしたファイルを返すのか）を返します。YESなら、エイリアスのリンク先のファイル名が返されるということです。デフォルトはYESです。

こちらも御覧下さい: - setResolvesAliases:
------------------------------------------------------------------------

runModalForDirectory:file:types:

- (int)runModalForDirectory:(NSString *)directoryfile:(NSString *)filenametypes:(NSArray *)fileTypes

レシーバーをパネルとして表示します。これはユーザーがOKまたはCancelを押す（返り値がNSOKButtonかNSCancelButtonとなる）までイベントループとなります。レシーバーはfileTypes（拡張子を含むNSArray）で指定されたタイプ
のファイルのみを表示します。もし、directoryがnilの場合はデフォルトでアプリケーションディレクトリが表示されます。fileTypesがnilな場合は全てのファイルが表示されます。また、ブラウザにディレクトリとファイルのどちら
が表示されるかは、setCanChooseDirectories:やsetCanChooseFilesメソッドでコントロールできます。引数filenameでは、パネルが開いたときにあらかじめ選択されているファイルを指定することができます。必要がない場合はfilenameはnilです。

こちらも御覧下さい: - runModalForTypes:
------------------------------------------------------------------------

runModalForDirectory:file:types:relativeToWindow:

- (int)runModalForDirectory:(NSString *)pathfile:(NSString *)nametypes:(NSArray *)fileTypesrelativeToWindow:(NSWindow*)window

このメソッドは推奨されません。代わりにbeginSheetForDirectory:file:types:modalForWindow:modalDelegate:didEndSelector:contextInfo:を使用して下さい。

------------------------------------------------------------------------

runModalForTypes:

- (int)runModalForTypes:(NSArray *)fileTypes

引数filenameとdirectoryをnilとして、runModalForDirectory:file:types:メソッドを起動します。詳しくは、runModalForDirectory:file:types:の記述を参照して下さい。引数fileTypesはブラウザで表示させたい
ファイルの拡張子を含んだNSArrayを指定します。なお、このメソッドはNSOKButtonかNSCancelButtonを返します。

------------------------------------------------------------------------

setAllowsMultipleSelection:

- (void)setAllowsMultipleSelection:(BOOL)flag

ユーザーに一度に複数のファイル（もしくはディレクトリ）を選択することを許可するかをセットします。

こちらも御覧下さい: - allowsMultipleSelection
------------------------------------------------------------------------

setCanChooseDirectories:

- (void)setCanChooseDirectories:(BOOL)flag

ユーザーにディレクトリーを選択することを許可するかをセットします。ディレクトリが選択されている場合、このフラグがYESの場合にのみ、ユーザーはOKボタンが押せます。

こちらも御覧下さい: - canChooseDirectories
------------------------------------------------------------------------

setCanChooseFiles:

- (void)setCanChooseFiles:(BOOL)flag

ユーザーにファイルの選択を許可するかをセットします。

こちらも御覧下さい: - canChooseFiles
------------------------------------------------------------------------

setResolvesAliases:

- (void)setResolvesAliases:(BOOL)resolvesAliases

レシーバーがエイリアスを解決するか（エイリアスをエイリアスとして返すのか、それとリンクしたファイルを返すのか）をセットします。YESなら、エイリアスのリンク先のファイル名やURLが返されるということです。
エイリアスをエイリアスとして選択させたい場合はNOをセットして下さい。

こちらも御覧下さい: - resolvesAliases
------------------------------------------------------------------------

URLs

- (NSArray *)URLs

選択されたファイルの、URLとして表現された絶対パスを含んだ配列を返します。複数選択が許されない場合は、配列のもつ要素は一つのファイル名のみです。

こちらも御覧下さい: - filenames



ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
はぁ〜、やっと終わったよ・・・
コピペするのも一苦労だわ（笑）

大したもんだ。

おお、すげえ！

少し要望を。

最初はReferenceより下にあるProgrammingTopicsの内容を優先した方がいいと思います。クラスのメソッド全て翻訳するのは大変なわりにメソッド名で機能は判断できる場合が多いと思うので。
ProgrammingTopicsにはトピックごとにクラスの使用方法が書かれています。

それと委任とか通知とかはdelegate、notificationとかで統一した方がいいと思います。その方がsetDelete:メソッドやNSNotificationとの対応が分かりやすいでしょう。

個人的に直訳的日本語で(とりあえずは)いいと思います。

なんだ、この長文コピペ荒しは？

コピペ荒しかよっ！

と、期待に応えてツッコミを入れてみるテストの書き込み練習

それではコピペ荒らし、逝きます（w
1

＊＊＊
[NSToolbar]

　継承：NSObject
　準拠：NSObject(NSObject)
　宣言：Appkit/NSToolbar.h

＊＊＊
クラスの概要
NSToolbarとNSToolbarItemはタイトル付きウィンドウのタイトルバーの下に、下図のようなツールバーを表示するための仕組みを提供します。
（図）

＊＊＊
定数
NSToolbarによって以下の定数が定義されており、これらはdisplayModeとsetDisplayModeによって使用されます。

NSToolbarDisplayModeDefault　デフォルトの表示形式です。
NSToolbarDisplayModeIconAndLabel　ツールバーにアイコンとラベルを表示します。
NSToolbarDisplayModeIconOnly　ツールバーにアイコンのみを表示します。
NSToolbarDisplayModeLabelOnly　ルールバーにラベルのみを表示します。

2

＊＊＊
メソッドの種類

・NSToolbarを作成する
　-initWithIdentifier:

・ツールバーの属性
　-displayMode
　-setDisplayMode:
　-allowsUserCustomization
　-setAllowsUserCustomization:
　-identifier
　-items
　-visibleItems

・デリゲートの取り扱い
　-delegate
　-setDelegate:

・ツールバーを表示する
　-isVisible
　-setVisible:

3

・ツールバーのカスタマイズ
　-runCustomizationPalette:
　-customizationPaletteIsRunning

・設定を自動保存する
　-autosavesConfiguration
　-setAutosavesConfiguration:
　-configurationDictionary
　-setConfigurationFromDictionary:

・ツールバーアイテムの照合
　-validateVisibleItems

4
＊＊＊
インスタンスメソッド

allowsUserCustomization
- (BOOL) allowsUserCustomization
ユーザーがツールバーをカスタマイズすることを許可されているかど
うかを返します。デフォルトの値はNOです。値がNOだと「ツールバー
のカスタマイズ...」メニューは使用不可となります。値がYESのとき
はユーザーの設定を保持するため、autosavesCustomizationの値がYES
になっていることを確認して下さい。
この属性はユーザーがツールバーの表示、非表示を切り替えられるかど
うかには影響しません。
参照：-setAutosavesCconfiguration: , -configurationDictionary

autosavesConfiguration
- (BOOL) autosavesConfiguration
レシーバが設定を自動保存するかどうかを返します。YESの場合、レ
シーバはツールバーの設定が変更されると自動的にそれをユーザーデ
フォルトに保存します。デフォルトの値はNOです。
ツールバーの設定に関する情報はユーザーデフォルト内で、ツールバー
識別子によって認識されます。同じ識別子を持ったアクティブなツール
バーが複数ある場合、それらは同じ設定を共有するので、保存されるの
はこの共通の設定となります。
参照：-setAutosavesConfiguration: , -configurationDictionary

5

configurationDictionary
- (NSDictionary *) configurationDictionary
レシーバの設定を、辞書オブジェクトとして返します。displayMode、
isVisible、現在ツールバーにあるアイテムの識別子のリストが含まれ
ますが、必要であれば自分で項目を追加することもできます。
Configuration Dicrionaryの通常の内容の詳細には依存しません（訳
注：すいません、ここよく分からないので適当です）。
参照：-setConfigurationFromDictionary:

customizationPaletteIsRunning
- (BOOL) customizationPaletteIsRunning
レシーバのカスタマイズパレットが使用中であるかどうかを返します。
参照：-runCustomizationPalette:

delegate
- (id) delegate
レシーバのデリゲートを返します。どのツールバーにもデリゲートが必
要であり、それには必要なデリゲートメソッドが実装されていなければ
なりません。
参照：-setDelegate:

displayMode
- (NSToolbarDisplayMode) displayMode
レシーバの表示形式を返します。これは「定数」で述べた値の一つで
す。
参照：-setDisplayMode:

6

identifier
- (NSString *) identifier
レシーバの識別子を返します。これはツールバーの種類を示すもので
す。アプリケーション内で、同じ識別子を持つ全てのツールバーは同じ
状態に保たれます。例えば表示形式、項目の並び順などです。また、
ツールバーが設定を自動保存するようになっている場合、アイテム識別
子が自動保存の際の名前として用いられます。

insertItemWithItemIdentifier:atIndex:
- (void) insertItemWithItemIdentifier: (NSString
*)itemIndentifier atIndex: (int) index
itemIdentifierが示すアイテムを、indexの示す場所に挿入します。
ツールバーに新しいインスタンスが必要な場合はtoolbar:
itemForIdentifier:willBeInsertedIntoToolbar:から自動的に取得しま
す。重要な情報についてはidentfierの項を見て下さい。
参照：-removeItemAtIndex:

initWithIdentifier:
- (id) initWithIdentifier: (NSString *) identifier
identifierによって新たにアロケートされたNSToolbarを初期化しま
す。identifierはツールバーの種類を決定するためにツールバーによっ
て使用されます。通常identifierがユーザーの目に触れることはなく、
したがってローカライズの必要はありません。重要な情報については
identifierの項を見て下さい。
参照：-identifier

7

isVisible
- (BOOL) isVisible
レシーバが可視状態かどうかを返します。
参照：-setVisible:

items
- (NSArray *) items
レシーバの中にある全てのアイテムを、順番に返します。

removeItemAtIndex:
- (void) removeItemAtIndex: (int) Index
indexの示すアイテムを取り除きます。通常はこのメソッドを呼ぶので
はなく、ユーザーにツールバーを再設定させるべきです。重要な情報に
ついてはidentifierの項を見て下さい。

runCustomizationPalette:
- (void) runCustomizationPalette: (id) sender
レシーバのカスタマイズパレットを表示します。ユーザーがカスタマイ
ズを終了するとパレットは閉じられます。
参照：-customizationPaletteIsRunning

8

setAutosavesConfiguration:
- (void) setAutosavesConfiguration: (BOOL) flag
レシーバが設定を自動保存するかどうかを決定します。flagがYESの場
合、レシーバはユーザーが行った変更を自動的にユーザーデフォルトに
書き込みます。カスタマイズ可能なツールバーの場合flagがYESである
ことが必要です。NOにすることは設定が自動保存されないことを意味し
ますが、configurationDictionaryを用いて自前で行うこともできま
す。
参照：-configurationDictionary

setDelegate:
- (void) setDelegate: (id) delegate
レシーバのデリゲートをdelegateが示すものに設定します。どのツール
バーにもデリゲートが必要であり、それには必要なデリゲートメソッド
が実装されていなければなりません。
参照：-delegate

setDisplayMode:
- (void) setDisplayMode: (NSToolbarDisplayMode) displayMode
レシーバの表示形式を設定します。displayModeは「定数」で述べた値
の一つです。
参照：-displayMode

setVisible:
- (void) setVisible: (BOOL) shown
レシーバが可視か不可視かを決定します。
参照：-isVisible

9

validateVisibleItems
- (void) validateVisibleItems
ウィンドウのアップデートの際、それぞれの可視アイテムを照合するた
めに呼ばれます。このメソッドはサブクラス内でオーバーライドして使
用します。直接呼ぶことは避けて下さい。ツールバーはこのメソッドを
可視アイテムのリストに従って繰り返し呼び、それぞれの項目に
validateメッセージを送ります。これがいつ起きるかを知りたければ
オーバーライドしてスーパークラスを呼んで下さい。

visibleItems
- (NSArray *) visibleItems
レシーバの、現在可視であるアイテムを返します。アイテムはオーバー
フローメニューに入る（訳注：ツールバーの長さに対してアイテム数が
多いと、右端に矢印が表示されるアレでしょうか）と不可視になること
があります。
参照：-items

10

＊＊＊
デリゲートによって実装されるメソッド

toolbar:itemForItemIdentifier:willBeInsertedIntoToolbar:
- (NSToolbarItem *) toolbar: (NSToolbar *) toolbar
itemForItemIdentifier: (NSString *) itemIdentifier
willBeInsertedIntoToolbar: (BOOL) flag
与えられたツールバーアイテム識別子によって識別されるツールバーア
イテムを返します。新たなツールバーアイテムのインスタンスはこのメ
ソッドによって作成されます。toolbarItemForItemIdentifierはツール
バーのインスタンスのためにlazyに（訳注：すいません、訳を思い付き
ません）呼ばれ、このツールバーのインスタンスがツールバーアイテム
の唯一のオーナーとなります。ツールバーは既に与えられたツールバー
アイテムをもう一度要求する可能性があり、その場合
toolbarItemForItemIdentifierは前に返したのと同じツールバーアイテ
ムを返すことができ、またそうするべきです。ただし要求されたアイテ
ムが重複を許すものである場合はこの限りではありません。重複を許す
場合には最初に返したアイテムの新しいインスタンスを渡してやる必要
があります（おそらくcopyを使って）。
アイテムがカスタムビュー・アイテムである場合、NSViewはアイテムが
返される時点で完全に構築されていなければなりません。返されたアイ
テムがアクティブなアイテムとしてツールバーに追加されると決め込ま
ないで下さい。カスタマイズパレット内だけで使用されるということが
あり得るからです（カスタマイズパレットは返されたアイテムのコピー
を作成します）。
返り値がnilであるということは、指定された種類のツールバーアイテ
ムがサポートされていないことを意味します。
flagがYESである場合返されたアイテムはツールバーに挿入され、
toolbarWillAddItemが呼ばれるということが予想できるでしょう。
このメソッドの実装は必須です。

11

toolbarAllowedItemIdentifiers:
- (NSArray *) toolbarAllowedItemIdentifiers: (NSToolbar *)
toolbar
カスタマイズパレットにあるアイテムの内容と順番を表す、ツールバー
アイテム識別子の配列を返します。使用可能な全てのアイテムは、たと
え標準的なものであっても明示的に列挙されていなければなりません。
返される識別子はtoolbarDefaultItemIdentifiers:で返されるものを全
て含んでいなければなりません。
このメソッドの実装は必須です。

toobarDefaultItemIdentifiers:
- (NSArray *) toolbarDefaultItemIdentifiers: (NSToolbar
*)toolbar
デフォルトのツールバー設定におけるアイテムの種類と順番を表す、
ツールバーアイテム識別子の配列を返します。このメソッドはツール
バーの初期化中、ユーザー初期設定の中にツールバーの識別子が見つか
らなかったときのみ呼ばれます。またカスタマイズパレットの初期化の
際にも呼ばれます。
このメソッドの実装は必須です。

toolbarDidRemoveItem:
- (void) toolbarWillRemoveItem: (NSNotification *) notification
アイテムがツールバーから取り除かれた直後にポストされます。このこ
とによって、キャッシュされているアイテムに関する情報を取り除く機
会が出来ます。notificationのobjectはアイテムが追加されているツー
ルバーを表します。notificationのUserInfo辞書は@"item"というキー
のもと、追加されているアイテムを格納します。このメソッドが実装さ
れている場合、ツールバーのデリゲートを設定する際にツールバーは自
動的にこのメソッドをNSToolbarDidRemoveItemNotificationに登録しま
す。
このメソッドの実装はオプションです。

12

toolbarWillAddItem:
- (void) toolbarWillAddItem: (NSNotification *) notification
新しいアイテムがツールバーに追加される直前にポストされます。ツー
ルバーアイテムへの参照をキャッシュしたり初期状態を設定する必要が
ある場合、ここで行います。notificationのobjectはアイテムが追加さ
れようとしているツールバーを表します。notificationのUserInfo辞書
は@"item"というキーのもと、追加されるアイテムを格納します。この
メソッドが実装されている場合、ツールバーのデリゲートを設定する際
にツールバーは自動的にこのメソッドを
NSToolbarWillAddItemNotificationに登録します。
このメソッドの実装はオプションです。

＊＊＊
告知（Notification）

NSToolbarDidRemoveItemNotification
ツールバーからアイテムが取り除かれた直後にポストされます。

NSToolbarWillAddItemNotification
ツールバーに新しいアイテムが追加される直前にポストされます。


終了。最後の方、昨夜寝ながらやったから訳ぐちゃぐちゃかも（w

Cocoa、さっぱりわからんよ。
漏れ的には慣れ親しんだToolBox（Carbon API）のほうが楽。

>>60
CocoaはともかくObjective-Cはいいっすよ。
そういや昔どこかのMLでToolBoxって書いたらToolboxじゃｳﾞｫｹ！と
劇しく罵られまして、結構ショックでした。

>>61

Objective-Cってどういうメリットがありますか？
覚え安いですかね。

漏れはMacintoshアプリケーションプログラミングっていう本で
Toolbox勉強しながらプログラム覚えたのでそっちに慣れてしまって（汗

＞そういや昔どこかのMLでToolBoxって書いたらToolboxじゃｳﾞｫｹ！と
＞劇しく罵られまして、結構ショックでした。

それはRbMLもですねぇ。
別に書き方ぐらいどうだっていいのに。
揚げ足取りは気持ち悪いです。

あ、ID変わってるけど62=60っす。

皆様、おつかれさまです。

当初つくらないつもりだったWebですが、やっぱり成果が見えた方がやる気も出るんでこちらにうぷしました。
http://members.tripod.co.jp/cocoa_j/index.html

リンクに「＊」がついているところが、日本語訳されたリンクです。

>>64
良さげですねー。お疲れ様です。
次はNSCursor逝かせてもらいます。

>>62
Objective-CはCの基本が出来ていて、C++に詳しくない（笑）人なら
結構簡単にマスターできるような気がします。自分はメッセージの考え方が
気に入りました。

>>64
ごくろうさまです。やはりHTMLにまとめるとすごく見やすいですね。
Webページでちょっと気になったところなんですが、
余分な<br>の改行は入れない方がよいということと、
翻訳済みの場合でも、原文へのリンクを参照できると便利ということと、
ソースの日本語が全てエスケープされているのは何ごとかと思いました(^_^:

ココアよりホットチョコレートが好きです。

＞ソースの日本語が全てエスケープされているのは何ごとかと思いました

ほんとだ、なんだこりゃ。
ネスケ６のコンポーザーで形を整えただけだったんですが、これ直さなくちゃいけないですねぇ。
原文のリンクも足しておきます。

名スレ、激しく応援します。

HTMLの整形なんかは、頼まれたらいくらでも出来ますので、
（そして、まわりにも出来る人は沢山いるので）
>>1さんや翻訳者諸氏にはバリバリ翻訳していって欲しいです。

ちなみにCocoaのドキュメントはAppleのサイトにアクセスしなくても
PBの「ヘルプ→Cocoaヘルプ」のApplication Kitの項から辿れますんで、
回線細い方もヨロシク！

http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/ProgrammingTopics/AppArchitecture/index.html

プログラミングトピックの概要：アプリケーションアーキテクチャ

このトピックは Cocoa アプリケーションの基本的な構成要素を記述するコンセプトとそれらが一緒に作動する方法を含みます。
同じく Cocoa アプリケーションの機能とそれらのデザインと関連した原理も論じます。


ディスカッション

ココアフレームワークの3つの重要機能− スクリプティング、ドキュメントアーキテクチャそしてundoと redo − が多くの共通概念を持ちます。
このトピックはそれらの共有された概念的な支柱を説明します。 これらの機能を実装しているクラスあるいはそれらを使う方法の詳細については詳しく述べません。
その代わりに、アプリケーションの推薦された構造とその構造がこれらの機能をサポートする方法に集中します。

ココアフレームワークは AppKit.framework と Foundation.framework です。/System/Library/Frameworks/ でそれらを調べることができます。

このトピックは、モデルビューコントローラー（ MVC ）デザインパターンを記述することによって始まります。
なぜならこのパターンがスクリプティング、ドキュメントベースのアプリケーションと undo を支えるためのアプリケーションデザインを性格づけるからです。
どんな正式の仕方での MVC デザインパターンも完全には記述しません。それが実際の目的ではないからです。しかし、論議のための若干の背景を与えるのに十分なパターンを論じます。

このトピックは特定の API を記述するために Objective-C を使います。 しかしながら、すべてのスクリプティング、ドキュメントと Undo API は Java でも利用可能です。
適切である場合は、 Java と関連がある特別な問題が論じられます。もし Java が特に言及されないなら、特別にそれについて言うべきことが何もないからです。

「アプリケーションデザイン」の下で期待されるかもしれない若干のトピックスが、概念的、アーキテクチャ的つながりが強い所で見つけられます。
これらの関連したトピックスは「関連したトピックス」の下で見いだされます。

2002 Apple Computer, Inc. （2002年2月19日、発行）

Cocoa アプリケーションの内容

Cocoa アプリケーションがアプリケーションバンドルとして流通されます。 アプリケーションバンドルはバンドルの特別なタイプです： Finder でユーザーにそれ自身をシングルファイルとして提示するディレクトリ。
アプリケーションバンドルの場合、ファイルは実行可能プログラムです。 それをダブルクリックすることは Finder にアプリケーションを起動させます。 アプリケーションバンドルが .app の拡張子を持っています。

アプリケーションバンドルがその実行可能プログラムによって必要とされるアプリケーション実行可能プログラムとリソースを含んでいます。
もっと多くのバンドルとアプリケーションパッケージについての情報のために、インサイド Mac OS X ：システム概要の「バンドル」と「アプリケーションパッケージ」章を見てください。

2002 Apple Computer, Inc. （2002年2月19日、発行）

ネタスレと思ったらとんだ良スレだった。
名前悪いなあ。
Cocoaドキュメント日本語化計画とか何とか、
センスなくていいからやりたいことのわかるスレタイだったら良かったのにな。
このスレに気付いてない人まだ多いと思うよ。

終わりましたので一気に逝かせていただきます。
1

[NSCursor]

継承：NSObject
準拠：NSCoding,NSObject(NSObject)
宣言：Appket/NSCursor.h

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊クラスの概要

NSCursorクラスのインスタンスはカーソルの外見を取り扱います。さらに詳しい情
報を得るためには「Overview of Programming Topic:Cursor Management」を
お読み下さい。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
採用されているプロトコル

NSCoding
- encodeWithCoder:
- initWithCoder:

2

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
メソッドの種類

新しいカーソルを初期化する
- initWithImage:hotSpot:
- initWithImage:foreGroundColorHint:backgroundColorHint:hotSpot:
カーソルの属性を設定する
- image
- hotSpot
+ hide
+ unhide
+ setHiddenUnitMouseMoves:
現在のカーソルがどれかを決定する
+ pop
- pop
- push
- set
- mouseEntered:
- setOnMouseEntered:
- isSetOnMouseEntered
- mouseExited:
- setOnMouseExited:
- isSetOnMouseExited
カーソルのインスタンスを取得する
+ arrowCursor
+ currentCursor
+ IBeamCursor

3

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
クラスメソッド

arrowCursor
+ (NSCursor *)arrowCursor
デフォルトのカーソル、つまり先端にホットスポットを持つ傾いた矢印（アロー
カーソル）を返します。アローカーソルはウィンドウシステム上のボタンやスク
ロールボックス、その他多くのオブジェクトの上で見慣れているはずです。
参照：+ IBeamCursor, + currentCursor, - hotSpot

currentCursor
+ (NSCursor *)currentCursor
現在画面上に表示されているカーソル（カレントカーソル）を返します。
参照：- set, - push, + pop, - mouseEntered:, - mouseExited:

hide
+ (void)hide
カレントカーソルを不可視にします。他のカーソルがカレントカーソルになった場
合にはそれも不可視になります。この不可視状態はunhideメソッドが呼ばれるまで
続きます。
このメソッドはsetHiddenUntilMouseMoves:をオーバーライドしています。


IBeamCursor
+ (NSCursor *)IBeamCursor
中程に小さなクロスビームを伴った、大文字のIに似たカーソル（Iビームカーソル）
を返します。このカーソルは編集可能、あるいは選択可能なテキストの上でよく目
にしていることでしょう。Iビームカーソルのデフォルトのホットスポットはクロス
ビームがIの字を分割している部分にあります。
参照：+ arrowCursor, + currentCursor

4

pop
+ (void)pop
カレントカーソルをスタックの一番上からポップします。スタックの一番上にある
新しいオブジェクトがカレントカーソルになります。カレントカーソルがスタック
にある唯一のカーソルであるときは何も起こりません。
参照：- push

setHiddenUntilMouseMoves:
+ (void)setHiddenUntilMouseMoves:(BOOL)flag
flagがYESの場合はカーソルを不可視にします。カーソルは以下のことが起こるまで
不可視のままです：
・マウスが動かされる
・このメソッドがflagをNOとして再び呼ばれる
このメソッドで隠されたカーソルをunhideを呼ぶことで再表示しようとしないで下
さい。結果は定義されていません。
参照：+ hide

unhide
+ (void)unhide
それ以前に呼ばれたhideを無効にし、カレントカーソルを表示します。
参照：+ setHiddenUntilMouseMoves:, + hide

5

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
インスタンスメソッド

hotspot
- (NSPoint)hotSpot
カーソルの逆16×16座標系に従って、ホットスポットの位置を返します。より完全
な説明についてはクラスの概要を見て下さい。
NSCursorクラスのオブジェクトは可変ではない（immutableである）ことに注意し
て下さい。一度作成してしまったらホットスポットの位置を後から変更することは
できません。代わりにinitWithImage:hotSpot:を用いて新しい設定でカーソルを作
成して下さい。
参照：- initWithImage:hotSpot:

image
- (NSImage *)image
レシーバの画像イメージを返します。
NSCursorクラスのオブジェクトは可変ではない（immutableである）ことに注意し
て下さい。一度作成してしまったらイメージを後から変更することはできません。
代わりにinitWithImage:hotSpot:を用いて新しい設定でカーソルを作成して下さ
い。

initWithImage:foregroundColorHint:backgroundColorHint:hotSpot:
- (id)initWithImage:(NSImage *)newImage foregroundColorHint:(NSColor *)fg
backgroundColorHint:(NSColor *)bg hotSpot:(NSPoint)hotSpot
レシーバを初期化し、画像イメージとしてnewImage（16×16ピクセルでなくては
なりません）を割り当てるとともに、そのホットスポットをhotspotに設定します。
前景色と背景色は現在のところ無視されます。自分自身を返します。
参照：- initWithImage:hotSpot:

6

initWithImage:hotSpot:
- (id)initWithImage:(NSImage *)newImage hotSpot:(NSPoint)aPoint
このクラスの指定イニシャライザです。レシーバを初期化し、画像イメージとし
てnewImageを割り当てるとともに、そのホットスポットをaPointに設定します。
自分自身を返します。
参照：- hotSpot, - image, -
initWithImage:foregroundColorHint:backgroundColorHint:hotSpot:

isSetOnMouseEntered
- (BOOL)isSetOnMouseEntered
レシーバがmouseEntered:メッセージを受け取った場合、カレントカーソルになる
ときはYESを返します。それ以外の場合にはNOを返します。
そうしたメッセージを受け取るためには、レシーバはカーソル矩形を割り当てられ
ている必要があります。この割り当てはNSViewのaddCursorRect:cursor:メソッド
を用いて行います。より詳しい説明はクラスの概要を見て下さい。
参照：- setOnMouseEntered:, - isSetOnMouseExited

isSetOnMouseExited
- (BOOL)isSetOnMouseExited
レシーバがmouseExited:メッセージを受け取った場合、カレントカーソルになると
きはYESを返します。それ以外の場合にはNOを返します。
そうしたメッセージを受け取るためには、レシーバはカーソル矩形を割り当てられ
ている必要があります。この割り当てはNSViewのaddCursorRect:cursor:メソッド
を用いて行います。より詳しい説明はクラスの概要を見て下さい。
参照：- SetOnMouseExited:

7

mouseEntered:
- (void)mouseEntered:(NSEvent *)anEvent
マウスがレシーバのカーソル矩形に入ったとき、このメッセージが自動的にレシー
バに送られます。前もってsetOnMouseEntered:が引数をYESとして呼ばれている場
合、mouseEntered:でレシーバをカレントカーソルにすることができます。
自作のプログラムでは、mouseEntered:を明示的に呼ぶことはないでしょう。クラ
スインターフェースのみに含まれているので、オーバーライドすることはできま
す。
より詳細な説明はクラスの概要を見て下さい。

mouseExited:
- (void)mouseExited:(NSEvent *)anEvent
マウスがレシーバのカーソル矩形から出たとき、このメッセージが自動的にレシー
バに送られます。mouseEntered:と同じようにクラスインターフェースの一部なの
で、オーバーライドすることができます。

pop
- (void)pop
レシーバのクラスにpopメッセージを送ります。
参照： - push, + pop

8

push
- (void)push
レシーバをカーソルスタックの一番上に置き、カレントカーソルにします。
参照： - pop, + pop


set
- (void)set
レシーバをカレントカーソルにします。
参照： + currentCursor

setOnMouseEntered:
- (void)setOnMouseEntered:(BOOL)flag
flagがYESの場合、レシーバは将来mouseEntered:イベントメッセージを受け取る
ことができるようになります。そうでない場合は同メッセージを無視しま
す。mouseEntered:メッセージを受け取ることで、マウスがビューのカーソル矩形
に入ったときにレシーバがカレントカーソルになることができます。

setOnMouseExited:
- (void)setOnMouseExited:(BOOL)flag
flagがYESの場合、レシーバは将来mouseExited:イベントメッセージを受け取るこ
とができるようになります。そうでない場合は同メッセージを無視しま
す。mouseExited:メッセージを受け取ることで、マウスがビューのカーソル矩形か
ら出たときにレシーバがカレントカーソルになることができます。


以上です。疲れたのでちょっと休みますが誤訳などありましたらｺﾞﾙｧして下さい。

お疲れ様〜

うっ、「クラスの概要」の行頭で改行ミスしてた。欝打氏脳

おっと良スレ。
自分の勉強がてら、NSActionCell逝かせて頂きます。
時間かかると思うけど。

モデルビューコントローラーデザインパターン

モデルビューコントローラーデザインパターンは非常に古いです。 少なくとも Smalltalk の初期から存在していました。
プログラムの全体的なアーキテクチャにかかわるという点で、それはハイレベルパターンであり、アプリケーションを作り上げるオブジェクトのさまざまな種類の分類を提供しようとします。

パターンに従うオブジェクトに3つのタイプがあります：モデルオブジェクト、ビューオブジェクトとコントローラーオブジェクト。
パターンはこれらのオブジェクトのタイプがアプリケーションで演ずる役割を定義します；開発者として、あなたはクラスがこれらの3つのグループに分類されるよう設計します。
3つのオブジェクトのタイプのそれぞれが観念的な境界線によって他のものから切り離され、その境界線を横切って他のタイプのオブジェクトと通信します。

モデルオブジェクトがデータと基本的な振舞いを表現する

モデルオブジェクトが特別な知識と専門的知識を表現します。 それらはアプリケーションのデータを保持して、そのデータを操作するロジックを定義します。
うまく設計された MVC アプリケーションがモデルオブジェクトにカプセル化された形でそのすべての重要データを持ちます。
アプリケーションの持続的な状態の部分であるどんなデータでも（その持続的な状態がファイル、データベースあるいはパンチカードのいずれに保存されるかにかかわらず）、
データがアプリケーションにロードされる途端にモデルオブジェクトの中に存在するべきです。

理想的には、モデルオブジェクトはそれを表示し編集するために使われたユーザーインタフェースへの接続を持ちません。
例えば、もしあなたが個人を表すモデルオブジェクトを持つ（アドレス帳を書いているとします）なら、生年月日を保管することを望むかもしれません。
それはあなたの Person モデルオブジェクトで保管するには良いものです。
しかしながら、どのようにその日付が提示されるはずかについての日付フォーマット文字列あるいは他の情報を保管するのは、どこかほかにした方が恐らくより好都合です。

実践上、この分離は常に最も良いものではありません。ここに柔軟性のための若干の余地があります。しかし一般にモデルオブジェクトがインタフェースと提示方法問題に関係するべきではありません。
例外が合理的である1つの例は、表示されたグラフィックスを意味するモデルオブジェクトを持っているドローイングアプリケーションです。
グラフィックのオブジェクトがどのようにそれら自身を描くべきか知っていることは意味をなします。なぜならそれらの存在の主な理由が視覚に訴える事柄を定義することだからです。
けれどもこの場合でさえ、グラフィックのオブジェクトは特定のビューあるいはいかなるビューにあらわれるかについても当てにするべきではありませんし、
いつそれ自身を描くべきかを知ることの責任を持つべきではありません。
それを提示することを望むビューオブジェクトによってそれ自身を描くように依頼されるべきです。

1が長い。
ブラウザが妙になるな。

ビューオブジェクトはユーザーに情報を提示する

ビューオブジェクトがどのようにアプリケーションのモデルからデータを表示し、ことによると編集するべきか
知っています。 ビューは表示しているデータを保管することに責任があるべきではありません。
（もちろん、これはビューが実際には表示しているデータを決して保管しないことを意味しません。
ビューは、パフォーマンス上の理由のためにデータをキャッシュするか、あるいは類似のトリックを使うことが
できます）
ビューオブジェクトはただ1つのモデルオブジェクト、あるいはモデルオブジェクト全体、あるいはさらに多くの
さまざまなモデルオブジェクトを表示することの責任を持ち得ます。
ビューは多くのさまざまな多種多様さで入ります。

ビューオブジェクトは再利用可能であり、アプリケーション間の一貫性を提供する傾向があります。 Cocoaで、
アプリケーション キットは多数のビューオブジェクトを定義します。 NSButton のような、アプリケーション
キットのビューオブジェクトを再利用することによって、アプリケーションでのボタンが、多くのアプリケー
ションにわたる振舞いでのハイレベルな予測可能性をユーザーに提供して、正にどんな他の Cocoa アプリケー
ションでのボタンとも同じように振る舞うことを保証します。

ビューは、モデルを正確に表示していることを保証するべきです。 従って、通常、モデルに対する変更について
知る必要があります。 モデルオブジェクトが直接ビューオブジェクトに結び付けられるべきではないから、
それらが変更されたことを示すための一般的な方法を必要とします。 このために、それらが変更されるとき、
NSNotifications をポストするか、または、通常コントローラー層を通してビューに変更通知を渡すための別の
汎用的な方法を定義することができます。

お疲れ様です！
NSMovieいきます。

整形が結構手間かかる。
有志の方にお任せしちゃおうかな〜？

sageでやってくれない？

>>88
いいっすよ。整形。

整形しようと思ってHTML取りに行ったらサイトが変わってたｗ
少し待ちます。

あ、新しい構成わかった。
これ全部やる気っすか？　1さん。。。

[NSActionCell] --#1

継承元:
NSCell : NSObject

準拠:
NSCoding(NSCell)
NSCopying(NSCell)
NSObject(NSObject)

宣言:
AppKit/NSActionCell.h



クラスの概要
NSActionCellは、コントロール(NSControlあるいはそのサブクラスのインスタ
ンス)の内のアクティブエリアを定義します。NSControlのアクティブエリアと
して、NSActionCellは3つのことを行います:
通常テキストもしくはアイコンの表示を実行します。
NSControlに目標および行為を供給します
適切にそのエリアを強調しカーソル移動に基づいたそのターゲットへアク
ション・メッセージを送ることにより、マウス(カーソル)トラッキングを
扱います。


Programming Topic
→Action Messages

[NSActionCell] --#2

メソッドタイプ

NSActionCellの形成
- setAlignment:
- setBezeled:
- setBordered:
- setEnabled:
- setFloatingPointFormat:left:right:
- setFont:
- setImage:


セルの値の取得とセット
- doubleValue
- floatValue
- intValue
- stringValue
- setObjectValue:

NSActionCellの表示
- controlView

ターゲットとアクションの割り当て
- setAction:
- action
- setTarget:
- target

タグの割り当て
- setTag:
- tag

いやいやまさか（笑）
Appleと同じにした方が見やすいかな、と
とりあえずひと段落つきました。

＞いいっすよ。整形。
具体的なやり方ですがどうしましょ。

・・・私がメールアドレス公開してHTMLを送ってもらったほうが楽かなぁ？

[NSActionCell] --#3

インスタンス・メソッド

action
- (SEL) action
レシーバーのアクションメッセージセレクターを返します。

参照:
- setAction:
- setTarget:
- target

controlView
- (NSView*) controlView
(通常NSControlの)レシーバーが最後にdrawされたビュー、またはレシーバー
がコントロールビューを持たない場合nil値(通常ビューヒエラルキーに配置さ
れていないため)を返します。

doubleValue
- (double) doubleValue
セル内容を編集、評価後にdoubleとしてレシーバーの値を返します。レシーバー
がテキストタイプセルでないか、セルの値が分割可能でなければ、メソッドは
0を返します。

参照:
- validateEditing (NSControl)

floatValue
- (float) floatValue
セル内容を編集、評価後にfloatとしてレシーバーの値を返します。レシーバー
がテキストタイプセルでないか、セルの値が分割可能でなければ、メソッドは
0を返します。

参照:
- validateEditing (NSControl)

intValue
- (int) intValue
セル内容を編集、評価後にintとしてレシーバーの値を返します。レシーバー
がテキストタイプセルでないか、セルの値が分割可能でなければ、メソッドは
0を返します。

参照:
- validateEditing (NSControl)

[NSActionCell] --#4

setAction:
- (void) setAction: (SEL) aSelector
アクション・メッセージのために使用されたセレクターをaSelectorにセット
します。

参照:
- action
- setTarget:
- target

setAlignment:
- (void) setAlignment: (NSTextAlignment) mode
レシーバー中のテキスト配置をセットします。 modeは5つの定数:
NSLeftTextAlignment, NSRightTextAlignment, NSCenterTextAlignment,
NSJustifiedTextAlignment, NSNaturalTextAlignment(デフォルトのテキスト
配置)のうちの1つです。メソッドは、セル・テキストに行なわれていたすべて
の編集を廃棄した後に再描画のためにレシーバーをマークします。

/*
setBezeled:
- (void) setBezeled: (BOOL) flag
レシーバーがベゼル・ボーダーででそれ自体を描画し、再表示のためにマーク
します。その setBezeled:とsetBordered:メソッドは相互排他的にボーダーは
プレーンまたはベゼルにしかなり得ません。

setBordered:
- (void) setBordered: (BOOL) flag
レシーバーがプレーン・ボーダーででそれ自体を描画し、再表示のためにマー
クします。その setBezeled:とsetBordered:メソッドは相互排他的にボーダー
はプレーンまたはベゼルにしかなり得ません。
*/


setEnabled:
- (void) setEnabled: (BOOL) flag
レシーバーがenableでもdisableでもセットされます。disableのセル内のテキ
スト色はグレイに変更されます。セルがdisableな場合、それはハイライトす
ることができず、マウス・トラッキング(またしたがってターゲット/アクショ
ン機能に参加することができない)をサポートせず、編集することができませ
ん。メソッドはセル・テキストに行なわれていたすべての編集を廃棄した後で
の再表示のためにレシーバーをマークします。

[NSActionCell] --#5

setFloatingPointFormat: left: right:
- (void) setFloatingPointFormat:(BOOL)autoRange
left:(unsigned int)leftDigits
right:(unsigned int)rightDigits
レシーバーの浮動小数点フォーマットをNSCellクラス定義に記述されるような
"setFloatingPointFormat:left:right:" メソッド向けのものにセットします。
NSActionCellのメソッドインプリメンテーションはセルテキストへの編集の破
棄後の再表示のためにレシーバーをマークすることでNSCellを補足します

setFont:
- (void) setFont: (NSFont*)) fontObj
レシーバーがテキストを表示する場合の使用すべきフォントをセットします。
レシーバーがテキストタイプセルでなければ、メソッドはレシーバーをテキス
トタイプに変換します。fontObjがnilであり、かつレシーバーがテキストタイ
プセルの時、レシーバーによって現在保持されたフォントは自動リリースされ
ます。
/*
NSActionCellはNSCellでのこのメソッドのインプリメンテーションを更新され
たセル(再表示が必要)をマークすることで補います。
*/
レシーバーがテキストタイプセルに変換されかつ選択されている場合、fontOb
jでフィールド・エディターを更新します。

setImage:
- (void) setImage: (NSImage*)) image
imageをにレシーバーに表示させます。もしimageがnilの場合、現在レシ−バー
によって表示されているイメージは削除されます。

setObjectValue:
- (void) setObjectValue: (id) object
レシーバーのテキストのどんな編集も廃棄し、そのオブジェクト値をオブジェ
クトにセットします。 オブジェクト値が、メソッドが起動される前と最終的
に異なる場合、メソッドは再表示のためにレシーバーをマークします。

setTag:
- (void) setTag: (int) anInt
レシーバーのタグをanIntにセットします。

参照:
- tag

setTarget:
- (void) setTarget: (id) anObject
レシーバーのターゲットオブジェクトをanObjectにセットします。

参照:
- action
- setAction:
- target

[NSActionCell] --#END

stringValue
- (NSString *) stringValue
レシーバーの値を(設定されている場合)セルのフォーマッタによって変換され
た文字列オブジェクトとして返します。フォーマッタが存在せず、値がNSStri
ngの場合、プレーン、書式付き、またはローカライズされた文字列を返します。
値がNSStringでないか、NSStringに変換することができない場合、空の文字列
を返します。メソッドはセル・テキストに行なわれている、どんな編集も有効
にし、保持してNSCellのインプリメンテーションを補います。

参照:
- validateEditing (NSControl)

tag
- (int)tag
レシーバーのタグを返します。

参照:
- setTag:

target
- (id) target
レシーバーのターゲットオブジェクトを返します。

参照:
- action
- setAction:
- setTarget:

----kokomade
コメントアウトした部分、自信ないっす。どなたか補足きぼんぬ。

拙い訳ですんません＞All

>>95
つーかどこかにCVSリポジトリほしいっすね。その方が楽になるような気が。

…今日はもう寝ます。

>>95
> 具体的なやり方ですがどうしましょ。
> 私がメールアドレス公開してHTMLを送ってもらったほうが楽かなぁ？

とりあえず、それでまかなえるうちは、それでも良いかと。

>>100
> つーかどこかにCVSリポジトリほしいっすね。
CVSサーバの建て方はわからないんで、識者にお任せします。

とりあえず、整形のサンプルを用意してみました。

表紙（どうでもいいんだけど）
http://nasi2ch.tripod.co.jp/cocoa_j/
イントロダクションの整形例
http://nasi2ch.tripod.co.jp/cocoa_j/ApplicationKit/ObjC_classic/IntroAppKit.html

「原典に忠実にレイアウトすること」と、
「日本語版完成までは英語版へのリンクを保持する事」を意識しました。
これから、>>100までの整形に取りかかってみるつもりです。

>>66
どうよ？

頑張れ>>1氏、頑張れ、梨！

ああ、なるほどいい感じですね。
梨氏がサイトももっておられるなら、整形からうぷまでお任せできそうですね。

というわけで、私も一訳者となってばりばり（というほど速くない・・）進めます。

訳者のみなさん、がんばりましょ〜

でも、今日は寝ます（笑）

コントローラーオブジェクトはモデルをビューに結び付る

コントローラーオブジェクトは、アプリケーションのビューオブジェクトとそのモデルオブジェクトの間の
仲介者の役を務めます。 一般にコントローラーオブジェクトはアプリケーションに特定のロジックを持ちます。
コントローラーは、しばしばビューが表示するためのモデルオブジェクトへのアクセス持つことを確実にする
責任を持ち、しばしばビューがモデルに対する変更について情報をつかむ導管の役を務めます。

コントローラーオブジェクトにアプリケーション特定のコードを閉じ込めることによって、いっそう汎用的かつ
再利用可能なモデルとビューオブジェクトを作ります。 コントローラーはしばしばアプリケーションでの最も
再利用可能にしにくいオブジェクトですが、しかしそれは適切です。 あなたはすべてを再利用することができる
わけではありません。そしてもしコントローラー層の中に再利用可能でないコードを留めるなら、他のオブジェクト
を再利用することについてのずっと良い機会を持ちます。

コントローラー層はしばしば多くのコードの行を含みます。 コードのこの量をいっそう扱いやすくするために、
コントローラーレイヤをさらに「モデルコントローラー」と「ビューコントローラー」に細分することが有用な
場合があります。

モデルコントローラーはたいていモデル層にかかわるコントローラーです。 それはモデルを「所有します」；
その主要な責任はモデルを管理し、どんなビューコントローラーオブジェクトとも通信することです。
全体としてモデルに適用するアクションメソッドが一般にモデルコントローラーで実装されるでしょう。
ドキュメントアーキテクチャはたくさんのこれらのメソッドをあなたに提供します；例えば、 NSDocument は
ファイルをセーブすることに関連したアクションメソッドを自動的に扱えます。

ビューコントローラーはたいていビュー層にかかわるコントローラーです。 それはインタフェース（ビュー）を
「所有します」；その主要な責任はインタフェースを管理し、モデルコントローラーと通信することです。
ビューで表示されたデータに関わっているアクションメソッドが一般にビューコントローラーで実装される
でしょう。

セクション「ドキュメントアーキテクチャ」はモデルコントローラーとビューコントローラーの間の区別について
もう少し多くの詳細を提供します。

NSOpenPanel
http://nasi2ch.tripod.co.jp/cocoa_j/ApplicationKit/ObjC_classic/Classes/NSOpenPanel.html

次>>48

>>106
おお、いいですね。

しかし、訳したいとこを訳しはじめたら、>>71 からの部分は
浮いちゃってますね。。。

＞梨たん
（・∀・）ｲｲ！　でもアポーに怒られない程度の再現でお願いします〜

NSApplicationやろうかと思ったけど、ヘタレなのでNSBrowserくらいで
お茶を濁します。では

>>48
NSToolbar
http://nasi2ch.tripod.co.jp/cocoa_j/ApplicationKit/ObjC_classic/Classes/NSToolbar.html

簡潔な訳があったため、NSOpenPanelの内容を一部こちらに準拠し統一しました。

次>>71

眠いから突然練るかも知れないけどｗ

>>109
48ﾀﾝ、訳漏れがあるので確認してみてね。
あえて訳すのを回避したなら、それはそれで良いけれど。

>>107
1さんの新表紙に対応させるのは大変だと思うので、
訳のついている所だけのリンク集を作ろうと思います。

>>108
本音言うと、今のうちにアポーに確認するのに1票。
悪いことしてるわけじゃないし。>>10-11 >>17を確認してみてね。

いちばん嫌なシナリオは「ある日見に行ったら全部日本語になっていた」とかｗ
そりゃないか。

>>109
お疲れ様です。訳漏れですが、「Constants」のところのas convenienceは
これまた訳を思い付かず、後で訳注入れようと思ってたら忘れてしまいました（恥

＞いちばん嫌なシナリオは「ある日見に行ったら全部日本語になっていた」とかｗ
デベツールの新バージョンで全部日本語になってるというシナリオだったり。
まあInside Macintosh日本語版のこととか考えると、あと３年間はAPIリファレン
スの公式訳は出ないと思いますが（w

「HTML係その2」氏の登場を期待し、>>71は後回しにします。

次>>74
今日はこれが済んだら寝ます。


旧板のこのスレで応援しています。念のためご紹介まで。
主旨（翻訳）に関係ない議論等あれば、旧板にスレ立てる用意もあります。

あえて旧板で旧iMacとMacOSX
http://pc.2ch.net/test/read.cgi/jobs/1016604130/

>>74
NSCursor
http://nasi2ch.tripod.co.jp/cocoa_j/ApplicationKit/ObjC_classic/Classes/NSCursor.html

下に「HTML化の手順」を示しますので、
「こいつでいけそうだ」という訳者さんは是非直接HTML化してください。
「わしゃだめだ」「めんどくさい」という人は、引き続きこちらで整形いたします。

HTML開発手順。

前提
・改行記号を含めた一括置換が出来る程度には賢いエディタを持っている。
・電子メールやFTP等、何らかの「成果物を送る手段」を持っている。

1. 翻訳対象のドキュメントをダウンロードしてくる。
http://developer.apple.com/techpubs/macosx/Cocoa/Reference/ApplicationKit/ObjC_classic/AppKitTOC.html

2. エディタでダウンロードしたドキュメントを、改行記号LF設定で開く。

3. 改行記号CRを、すべて改行記号LFに置換する。
　（要するに、s/\r/\n/gと同じ事をする）

4. とりあえず、BASEタグをHEADの下あたりにでも仕込む。
<BASE href="http://developer.apple.com/techpubs/macosx/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/">

5. あとは、エディタを使って、原文のタグを壊さないように入れ替えをおこなう。
　（慣れないうちは、ファイルと原文のプレビューウィンドウを開いて確認する）
　※　HTMLエディタは、癖があるため、手慣れたもの以外はかえって避けた方がよい。

6. 「See Also」は「参照」に一発置換したりして、効率化の工夫をする。
　（s/See\sAlso/参照/g）（s/See\nAlso/参照/g）

技術者としての我が儘。

翻訳は、極力ボールドとイタリックを崩さないで欲しいです。
開発ドキュメントの凡例として意味があるので、通りがいいです。
（とかいっても、原文自体いいかげんなんで、てきとーでいいですが）

あと、デフォルト値の説明や、無いときはnilを返すとかいう説明も、
極力省略しないで欲しいです（実際コード書く時は気になるんで）

ドキュメント共通の言い回しは、良い物を決めて統一して欲しいです。
特によく使われる表現は簡潔で構わないと思います。

訳せなかった部分は英語で残して（併記して）欲しいです。


内容までは吟味してる余裕無かったですが、
なんか、Objective-Cはややこしそうだなあ、と思いましたｗ

寝る前に一覧。

表紙（どうでもいいんだけど）
http://nasi2ch.tripod.co.jp/cocoa_j/
イントロダクション
http://nasi2ch.tripod.co.jp/cocoa_j/ApplicationKit/ObjC_classic/IntroAppKit.html
NSOpenPanel
http://nasi2ch.tripod.co.jp/cocoa_j/ApplicationKit/ObjC_classic/Classes/NSOpenPanel.html
NSToolbar
http://nasi2ch.tripod.co.jp/cocoa_j/ApplicationKit/ObjC_classic/Classes/NSToolbar.html
NSCursor
http://nasi2ch.tripod.co.jp/cocoa_j/ApplicationKit/ObjC_classic/Classes/NSCursor.html

未整形 >>71-72 >>85 >>87 >>93-99 >>105
整形方法（HTML書ける人手伝って！） >>114

それでは、おやすみなさい。

梨さん、翻訳ページで上のツールバー部分やUpボタンの画像などまで、
本家から借用するのはいかがなものかと。。
ビジターが勘違いすることのないように、
Apple 及び アップルとは無関係にやっていることを、
これはぜひ明確にしておかなければなりません。

う。そだね。頭の方に書いておきます。

注釈追記対応。
>>114の作成手順4の後に、次の手順を追加してください。

BODYタグの下あたりにでも、次の文章をコピペする。

<font color="red">このドキュメントは、「新Mac板＠２ちゃんねる」のスレッド「<a href="http://pc.2ch.net/test/read.cgi/mac/1016716727/" target="_blank">日本人なら「ココア」でしょ？</a>」参加者有志で、<br>
http://developer.apple.com/techpubs/macosx/Cocoa/Reference/ApplicationKit/ObjC_classic/ のドキュメントを非公式に邦訳したものです。<br>
このドキュメントに対する連絡はスレッドにておこない、Apple Computer社への翻訳に関するお問い合わせはしないでください。</font>

皆さん翻訳作業お疲れ様です。

正直な話、日本語に翻訳して開示するのもアップルの義務（？）の様な気がする。
もっとちゃんと情報を公開してくれれば、我々が苦労して翻訳しなくて済む話な訳だし。
キチッと仕事しる！アップル！

>>120
Appleが将来的には当然行うだろうけど、それを待ってられないから
1氏他のみなさんが自発的に翻訳作業をしているのでしょう。
自発的かつ自然発生的な部分に潔さを感じる部分もあるので
Appleの義務云々の文句は他のスレで議論して貰いたいです。

例えばココ↓
http://pc.2ch.net/test/read.cgi/jobs/1016604130/l50

>>114-115, 118
了解。次はHTMLで逝きます。＞梨さん
順繰りに攻めるとして次はNSAffineTransformかな。仕事の合間にちまちまやります。

#ところで文字コードはShift-JISで統一、で良いですか?

とりあえず>>71
http://nasi2ch.tripod.co.jp/cocoa_j/TasksAndConcepts/ProgrammingTopics/AppArchitecture/AppArchitecture.html
ディレクトリも本家に見習ったんだが、
本家のProgrammingTopics見習ってindex.htmlも作った方が良いかな？
※本家：http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/ProgrammingTopics/AppArchitecture/index.html

ﾐﾐｶｷで改行全部LFにした ハ ズ w
タグは全部原文のまま使ってますが、サイズとかはある程度調節した方がいいのかしら。
# 日本語になるとちょっと見出しが見苦しい感じがする...

# いつも辞書片手にﾁﾏﾁﾏ読んでたﾃﾞﾍﾞﾛｯﾊﾟｺﾈｸｼｮﾝが日本語で読めるなんて（感涙
# 翻訳者の皆様頑張ってくだちぃ
# そしてやはり整形関連は別スレ進行の方が望ましい予感w
# 旧板か旧板の避難所使います？w>>1さん、梨さん、翻訳者各位

>>120 どうせなら、成果が認められるといいね。と思ったけど、
>>121 いいこと言った！　潔くやっていきますか。

>>122
さんくすです！　>>93はこっち(梨)でやります。仕事の合間に。
文字コードは原文がSJISなので、って、んな訳ないかｗ
とりあえずSJISで良いと思います。

>>123
お疲れ様です。ばっちりです。
えーと、じゃあ、旧板の「あえてOSX」スレでｗ

71さんが翻訳中のプログラムトピック:アプリケーションアーキテクチャのindexﾂｸﾀﾖ
http://nasi2ch.tripod.co.jp/cocoa_j/TasksAndConcepts/ProgrammingTopics/AppArchitecture/
目下>>71-72終了。次>>85ｶﾅ

とりやえずHTML化してないとこは404になりますw
本家は>>123のリンク参照
分担してややこい事になるとアレなので、
71さんがやってるｱﾌﾟﾘｹｰｼｮﾝｱｰｷﾃｸﾁｬ関連のHTML整形は
私が一括して担当しようと思いますがどうでしょ

>>124
ADCのディレクトリ構成に習ってディレクトリ作ろうとしたら
「レベル４階層以下は作っちゃイヤン★」って鳥さんに怒られたよw

>>125
よろしくです。
その壱さんは>>93を担当するです。

鳥さん、嫌だよね。。。移るか？　移れる？ｗ

　「甘すぎた、ココア」

　ま、「モザイク」と同じ運命をたどるかな？
　

>>125
あ、よろしくです。
じゃこのままチマチマと続けさせてもらいます。

なぜ MVC が重要か？

Apple社は Cocoa フレームワークに多くの新しい機能を加えています。 スクリプティングと Undo のような、
これらの機能のいくつかは、アプリケーション キットとファウンデーションフレームワークが過去に提供した
ものとくらべると幾分ハイレベルです。 さらに多くのもっとハイレベルな機能がフレームワークに加えられるとき、
その前提はこれらの機能を使うアプリケーションが MVC のようなハイレベルデザインに基づいていることと
なるでしょう。 開発者として、あなたはこれらの機能に関連があるアプリケーションデザインの領域にいっそう
関与する必要があります。

開発者は常に MVC パターンを使うよう推奨されてきましたが、ドキュメントアーキテクチャ、undoサポートと
スクリプティングのような新しい機能の出現によって、MVC パターンを中心に置くことはアプリケーション
デザイナーにとって今までよりいっそう重要です。 もしアプリケーションデザインが MVC パターンに従うなら、
これらの新しいハイレベル機能のすべては最も良く働くでしょう。 もしアプリケーションが行儀の良い MVC 分離
を持っているなら、これらの新しい機能を使うためにほとんど努力を要さないはずです。しかし、もし妥当な分離
がなされていないなら、新しい機能を使用するためにもっと多くの労力を要するでしょう。

（アプリケーション キットは、新しいクラスのいくつかはコントローラー層に入り込み始め、同様に少数のモデル
オブジェクトもありますが、たいていはビューフレームワークです。 ファンウデーションフレームワークは、
いくつかのコントローラーオブジェクトと共に、たいていはモデルオブジェクトです。）

他スレから飛んできた。
スレタイ見た時は糞だと思ってたんで見もしなかったが、良スレじゃねぇかよ。

どうもスレタイに対する非難がいっぱいみたいで申し訳ないっす（笑）

ところで、アヒャさんも梨さんのWebに手を加えられるんですか？
・・・うーん、事態をつかんでないのは私だけ？

とりあえず、翻訳ができたらどうすればいいのでしょう？ここにコピペする以外により良い方法があれば教えて下さいませ。
でも、昼間はMac使えないので作業は滞りまくり・・・

マジで応援してます。期待アゲ。

スレタイは半ば諦めてますｗ

>>131
> ところで、アヒャさんも梨さんのWebに手を加えられるんですか？

たまたまnasi2chの垢をｱﾋｬ氏とシェアしていただけなので、
もし本家cocoa_j垢にアクセス出来たら、たぶんそちらを更新していたでしょう。
1さんのメールアドレスが公開された時点で、ファイルとして送付できるかと。

> とりあえず、翻訳ができたらどうすればいいのでしょう？
> ここにコピペする以外により良い方法があれば教えて下さいませ。

フリーのCVSリポジトリを用意するのは難しいと思うので、
アップデート対応の担当1名を選出して（責任感のある暇人が望ましい）
メールなどのファイル受け取り体制を作り、
手前でバージョン管理出来れば良いのですが、
参加者用の共有アカウントを作り、気を使いながら管理するのも手です。

おおまかには1さんの判断にお任せっす。

>>133
とりあえずでよければ俺やろうか？＞梨
普通のHTTPサーバーなら用意出来るし。

>とりあえずでよければ俺やろうか？＞梨
>普通のHTTPサーバーなら用意出来るし。

そうですねぇ
私はあまり時間がとれないので、ぜひお願いしたいです。
以降は、梨さん主導ですすめちゃってくださいな。

とりあえず、NSMovieできました。
送り先が公開されれば送ります。

>>135
了解。梨と話してみます。

で、翻訳権はAppleと話がついてるんだろうね？

メール来ました。
（梨の連絡先は旧板に晒してます）

ちょっと今日は仕事でこれから徹夜なんで、
今日>>93が出来るかどうかは微妙です。ｽﾏｿ。

で、>>134の件、素晴らしいと思います。是非開始したいかと。
アカウントの件で相談されましたが、個人的には、
・mac.comアカウント
・メールでの受付
の両方に対応して貰うと有り難いです。

細かくは>>134氏にお任せします。

cocoaで「Hello world!」アプリをコンパイルしたら、サイズが1MBという巨大なものができた。
せいぜい10KBくらいにしたいんだけど？

cocoaってゴミ？

あぷ＆管理担当になりました「の」です。
整形済みHTMLファイルの受付ルールです。

・とりあえず「メールでの受付」のみとします。
・HTMLファイルは必ず「添付」形式で送付してください。
　その際自己解凍形式では無く「書類」形式で添付してください。
・「タイトルにディレクトリ（パス）名」を記入してください。
　URLアドレスは以下になります（タイトルにはcocoa_jproject/以下のパスを表記）
　http://homepage.mac.com/cocoa_jproject/
・ファイル管理上、連絡・問い合わせは単独のメールでお願いします。

送信メールアドレス　[email protected]

>>139
OS X初心者スレでCocoa叩きをしてた方ですか？　ほどほどに・・・（笑）

>>140
ここまで標準テキストで訳してしまった者ですが、HTML整形ってかなり負担に
なりますかね？　自分でHTMLにして送った方が良いのでしょうか。

ドキュメントアーキテクチャ


アプリケーションキットのドキュメントアーキテクチャは3つのクラスに基づいています：NSDocument、
NSWindowControllerとNSDocumentController。NSDocumentは主要なクラスです。それはアプリケー
ションで１つのドキュメントに相当します。開発者がそれにアプリケーションのモデル層の知識を与え、
持続性（ロードとセーブ）を実装するためにNSDocumentのサブクラスを派生しなくてはなりません。
NSWindowControllersはアプリケーションのユーザーインタフェースを所有し、コントロールします。
NSDocumentが1つ以上のNSWindowControllerを持っています。開発者は、コントローラーが管理する
責任があるビュー層の特定の知識を加えるために、しばしばNSWindowControllerのサブクラスを派生します。
NSDocumentControllerはsingletonクラスです。それぞれのドキュメントベースのアプリケーションは、
すべての開かれたドキュメントを記録し、管理するためにNSDocumentControllerのひとつのインスタンスを
持っています。開発者は、一般にNSDocumentControllerのサブクラスを派生する必要がありません。

NSDocumentsはモデルコントローラーである


NSDocumentはモデルコントローラークラスです。その主な仕事は、ドキュメントを構成するモデル
オブジェクトを所有し管理すること、と、ファイルにそれらのオブジェクトをセーブし、後に再ロードする
方法を提供することです。ドキュメントの持続的な状態の部分であるすべてのオブジェクトは、そのドキュメント
のモデルの部分であると考えられるべきです。時々NSDocumentそれ自身は、モデルの部分であると
考えられるであろう若干のデータを持っています。例えば、サンプルアプリケーションのSketchは、
SKTDrawDocumentという名前のNSDocumentのサブクラスを持っています；このクラスのオブジェクトは、
ドキュメントのモデルを構成するSKTGraphicオブジェクトの配列を持っているかもしれません。
実際のSKTGraphicオブジェクトに加えて、SKTDrawDocumentオブジェクトは、技術的にモデルの部分で
あると考えられるべき、若干のデータを含んでいます。SKTGraphicsのfront-to-backの順序付けを決定する
ことにおいて、ドキュメントの配列の中のグラフィックスの順序が重要であるからです。

NSDocumentは、アプリケーションのユーザーインタフェースに特定な、どんなオブジェクトの存在も含むべき
ではありませんし、それを必要とするべきでもありません。ドキュメントは、NSWindowControllerオブジェクト
- 視覚的にドキュメントを提示し、ユーザーがそれを編集することを可能にする - を所有し、管理することが
できますが、これらのオブジェクトがそこにあることに依存するべきではありません。例えば、視覚的に表示
されることなく、アプリケーション内に開いているドキュメントを持つことが望まれるかもしれません。
例として、スクリプトがそれで若干の処理をするためにドキュメントを開くかもしれません。もしスクリプトが
ユーザーが処理に関与することを必要としないなら、スクリプトは、それがけしてスクリーン上に現われること
なく、ドキュメントが、開かれ、操作され、セーブされ、再び閉じられることを望むかもしれません。

NSWindowControllersはビューコントローラーである


NSWindowControllerはビューコントローラークラスです。その主な仕事は、ドキュメントを表示し、
編集するために使われるビューオブジェクトを所有し、管理することです。ユーザーに見えるドキュメントは、
視覚的なプレゼンテーションを所有し、管理するために1つ以上のNSWindowControllersを持っています。
NSWindowControllerのインスタンスを使うことができますが、たいていの場合、インタフェースの詳細な
知識を加えるために、NSWindowControllerのサブクラスを派生しなくてはなりません。NSWindowControllerは、
通常nibファイルからそのインタフェースを得ます。サブクラスは、しばしばnibファイルの中のコントロールと
ビュー用にアウトレットとアクションを加えます。そして、NSWindowControllerは、通常、nibの「ファイルの
所有者」の役を務めます。

ドキュメント用にただ1つだけのウインドウがある非常に単純なケースでは、NSDocumentクラスがnib用の
アウトレットとアクションを持つことを望むかもしれません。この場合は、NSDocumentサブクラスがnibの
「ファイルの所有者」の役を務めます。しかし、nibからロードされるオブジェクトを所有し、管理するために
まだNSWindowControllerを作ります。もし、素速くアプリケーションのプロトタイプを作るとき、この
アプローチを採用することを選択するなら、ユーザーインタフェースを扱うコードの部分をローカライズする
ように気を使うべきです。それで、アプリケーションがより複雑になるにつれて、後でドキュメントからそれら
を抽出し、それらをカスタムのウインドウコントローラーの中に置くことができます。

タイプ情報とNSDocumentController


NSDocumentControllerオブジェクトは、ドキュメントを管理します。それはすべての開いている
ドキュメントを追跡記録します；それはどのように新しいドキュメントを作成するべきか、そして
どのように既存のドキュメント開くべきか知っています。ウインドウコントローラーは、そのドキュ
メントを参照しているウインドウか、あるいはそのドキュメントがロードされるファイルのパスの条件
のもとで、開いているドキュメントを見いだす方法を知っています。開発者は、一般にそれが何をする
か心配しなくてもよいでしょう。NSDocumentControllerは、ドキュメントベースのアプリケーション
が開くことができるドキュメントのタイプについて規定するメタデータを読んで、使う方法を知っています。
NSDocumentControllerは、アプリケーションによってサポートされるファイルタイプのリスト、
そして、いずれのNSDocumentサブクラスがそれらのために使われるのかなどの、そのメタデータに
基づいた情報を提供することができます。

すべてのドキュメントベースのアプリケーションは、アプリケーションの情報プロパティリスト（Info.plist）
で、サポートするドキュメントタイプについての情報を宣言します。ProjectBuilderは、このメタデータを
作成し変更するためのエディタを提供します。ドキュメントアーキテクチャによって必要とされる、
Info.plistのキーと、アプリケーションプロジェクトに、このメタデータを含める方法の詳細は、
NSDocumentControllerクラス詳述を見てください。

情報プロパティリストのメタデータは、アプリケーションによってサポートされるドキュメントのタイプを
宣言します。Cocoaは、抽象タイプのセットを定義します；これらのタイプは、通常、そのようなデータを
表現するペーストボードタイプと同じです。それぞれの抽象タイプのために、Info.plistは、以下の詳細情報
をリストします：

＊そのタイプのファイルを識別するために使われるファイル拡張
＊そのタイプのファイルのHFSの4文字のタイプコード
＊そのタイプのファイルを表示するためにFinderが使うべきアイコン
＊そのタイプのファイルを扱うためにアプリケーションによって使われるNSDocumentのサブクラス

NSDocumentControllerは、このすべてのタイプ情報をロードし、それを使います。NSDocumentController
がオープンパネルを作動させるとき、それはアプリケーションが読むことができるドキュメントタイプのための、
すべてのファイル拡張子のリストを得ます。開くことができるファイルをリストすることができるように、
オープンパネルにそのリストを渡します。ユーザーが実際に開くべきファイルを選択するとき、
NSDocumentControllerはドキュメントを作成し、そのデータをロードするために使うべきNSDocumentの
サブクラスを識別するために、メタデータを使います。

典型的な使用パターン


3つの汎用的な方法でのドキュメントアーキテクチャを使うことができます。次の論議は最も単純なもの
で始まって、最も複雑なものに進みます。

ドキュメントアーキテクチャを使う最も単純な方法は、ただ1つだけのウインドウを持ち、コントローラー
層をモデルコントローラーとビューコントローラーに分けることにたくさんの利益がないほど、十分単純な
ドキュメントに適切です。この場合は、開発者は、ただNSDocumentのサブクラスを作成することだけを
する必要があります。NSDocumentサブクラスは、モデルのためのストレージとドキュメントデータを
ロードし、セーブする能力を提供します。同じく、ユーザーインタフェースのために必要とされる、どんな
アウトレットとアクションでも持っています。このタイプのドキュメントのために使われたnibファイル名
を返すためにwindowNibNameをオーバーライドします。NSDocumentは、そのnibファイルを管理する
ために自動的にNSWindowControllerを作ります。しかし、NSDocumentそれ自身がnibファイルの
「ファイルの所有者」として役目を果たします。

もしドキュメントがただ1つだけのウインドウを持ち、しかし、コントローラー層でのロジックのいくらかを
分割したいほど十分複雑であるなら、NSDocumentと同様、NSWindowControllerのサブクラスの派生する
ことができます。この場合は、ユーザーインタフェースの管理に特定な、どんなアウトレットとアクション
と他の振舞いもNSWindowControllerサブクラスに入れます。NSDocumentサブクラスは、
windowNibNameの代わりにmakeWindowControllersをオーバーライドしなくてはなりません。
makeWindowControllersメソッドは、NSWindowControllerサブクラスのインスタンスを作成し、管理
されたウインドウコントローラーのリストにaddWindowController:でそれを加えるべきです。
NSWindowControllerは、nibファイルの「ファイルの所有者」であるべきです。これがビュー関連のロジック
とモデル関連のロジックのいっそう良い分離を作り出すからです。このアプローチは、最も単純なケース以外
のすべてで推奨されます。

もしドキュメントがひとつのドキュメントについて複数のウインドウを必要とする（か、あるいは複数のウイン
ドウを許す）なら、NSDocumentと同様、NSWindowControllerのサブクラスを派生するべきです。
NSDocumentサブクラスで、ちょうど上に記述された2番目の手続きのように、makeWindowControllersを
オーバーライドします。しかしながら、この場合、NSWindowControllerの1つ以上のインスタンスを、多分
NSWindowControllerの異なったサブクラスから、作成するかもしれません。あるアプリケーションは、いろ
いろな異なったウインドウが1つのドキュメントを表現することを必要とします。それ故に、恐らく
NSWindowControllerのいくつかの異なったサブクラスを必要とします。そしてmakeWindowControllersで
それぞれのものを作成しなくてはなりません。あるアプリケーションは、ドキュメント用にただ1つだけの
ウインドウを必要としますが、ユーザーがひとつのドキュメントのためのウインドウのいくつかのコピーを作成
することを可能にすることを望みます（これはmultiple-viewのドキュメントと呼ばれる）。それで、ユーザー
がそれぞれのウインドウが異なった位置にスクロールされるようにしたり、異なった方法で表示したりできます。
この場合は、makeWindowControllersはただ1つのNSWindowControllerを作成するだけかもしれません。
しかしそこでユーザーが他のものを作成することを可能にするメニューコマンドあるいは類似のコントロールが
あるでしょう。

ドキュメントとスクリプティング


スクリプティングサポートは、いくつかの理由のために、新しいドキュメントアーキテクチャに基づいた
アプリケーションについて、たいていは自動的です。最初に、ドキュメントアーキテクチャのNSDocument
と他のクラスは、標準ドキュメントスクリプティングクラス（AppleScriptによって期待されるような）
を直接実装し、ドキュメントに適用するスクリプティングコマンドの多くを自動的にサポートします。第二に、
ドキュメントアーキテクチャがMVC分離を使うアプリケーションデザインで作動するように意図されるから、
そして、スクリプティングサポートが同じデザインポイントの多くに依存するから、ドキュメントアーキテク
チャを使うアプリケーションは、そのように設計されない他のアプリケーションより、スクリプティングを
サポートするためにすでにいっそう良い状態になっています。最後に、ドキュメントは、たいていのアプリ
ケーションのスクリプティングAPIにおいて、重要な役割を演じます；NSDocumentはどのようにその役割を
果たすべきかを知っていて、アプリケーションのモデル層へのスクリプティングされたアクセスを許すための
良いスタート地点を提供します。

もしアプリケーションがドキュメントアーキテクチャに基づいていないなら、それをスクリプタブルにする
ことは、さもなければただでできるであろう作業を繰り返すことを要求します。TextEditアプリケーション
プロジェクト（MacOSXで配られた）は、NSDocumentに基づいていないドキュメントベースのアプリケー
ションをスクリプタブルにする方法を示します。スクリプタブルなNSDocumentベースのアプリケーション
を実装する方法の例のためにSketchサンプルプロジェクトを参照してください。

>>139
それProjectBuilderの問題。
最初にコンパイルされたオブジェクトファイルに余分なのがくっついてるみたい。
いったんクリーニングしてから再ビルドしてやると
それなりのサイズになるよ。
昔どっかのスレで書いたとき放置されたから
オレのとこだけかと思ったけど他でも起きるのね。
>>141
あれはCocoa叩きじゃなくてCarbon擁護だと思うけどなぁ。

>>141
経験則だと、まとめてやっちゃった方が効率的といえば効率的。

テキストのどの部分がどの訳なのかソースと照らし合わせて確認したり、
テキストの一部分のみを抜粋してHTMLと整合をとったりするから。

HTMLに整形する事は負担になるんだけれど、
HTMLへの整形をはしょれば翻訳が進むなら、整形係としてはテキスト歓迎。
あと、HTMLわからない人なんかもお気軽に頼め、ってのが、個人的なスタンス。

さて、力尽きるまで>>93いきます。

02/03/26縲�4:00 迴ｾ蝨ｨ縲?驍ｦ險ｳ竊檀tml謨ｴ蠖｢縺ｮ貂医ｓ縺ｧ縺?繧九ヵ繧｡繧､繝ｫ繧旦pload縺励∪縺励◆縲?

http://homepage.mac.com/cocoa_jproject/index.html

謨ｴ蠖｢貂医∩HTML繝輔ぃ繧､繝ｫ縺ｮ蜿嶺ｻ倥Ν繝ｼ繝ｫ縺ｧ縺吶�?

繝ｻ繝輔ぃ繧､繝ｫ邂｡逅?縺ｮ驛ｽ蜷井ｸ翫�後Γ繝ｼ繝ｫ縺ｧ縺ｮ蜿嶺ｻ倥�阪?ｮ縺ｿ縺ｨ縺励∪縺吶�?
繝ｻHTML繝輔ぃ繧､繝ｫ縺ｯ蠢?縺壹�梧ｷｻ莉倥�榊ｽ｢蠑上〒騾∽ｻ倥＠縺ｦ縺上□縺輔＞縲?
縲�縺昴?ｮ髫幄?ｪ蟾ｱ隗｣蜃榊ｽ｢蠑上〒縺ｯ辟｡縺上�梧嶌鬘槭�榊ｽ｢蠑上〒豺ｻ莉倥＠縺ｦ縺上□縺輔＞縲?
繝ｻ縲後ち繧､繝医Ν縺ｫ繝?繧｣繝ｬ繧ｯ繝医Μ?ｼ医ヱ繧ｹ?ｼ牙錐縲阪ｒ險伜?･縺励※縺上□縺輔＞縲?
縲�URL繧｢繝峨Ξ繧ｹ縺ｯ莉･荳九↓縺ｪ繧翫∪縺呻ｼ医ち繧､繝医Ν縺ｫ縺ｯcocoa_jproject/莉･荳九?ｮ繝代せ繧定｡ｨ險假ｼ?
縲�http://homepage.mac.com/cocoa_jproject/
繝ｻ繝輔ぃ繧､繝ｫ邂｡逅?荳翫�?騾｣邨｡繝ｻ蝠上＞蜷医ｏ縺帙?ｯ蜊倡峡縺ｮ繝｡繝ｼ繝ｫ縺ｧ縺企｡倥＞縺励∪縺吶�?

騾∽ｿ｡繝｡繝ｼ繝ｫ繧｢繝峨Ξ繧ｹ縲�[email protected]

いたい！omni attackだ！（ｗ

02/03/26　4:00 現在、邦訳→html整形の済んでいるファイルをUploadしました。

http://homepage.mac.com/cocoa_jproject/index.html

整形済みHTMLファイルの受付ルールです。

・ファイル管理の都合上「メールでの受付」のみとします。
・HTMLファイルは必ず「添付」形式で送付してください。
　その際自己解凍形式では無く「書類」形式で添付してください。
・「タイトルにディレクトリ（パス）名」を記入してください。
　URLアドレスは以下になります（タイトルにはcocoa_jproject/以下のパスを表記）
　http://homepage.mac.com/cocoa_jproject/
・ファイル管理上、連絡・問い合わせは単独のメールでお願いします。

送信メールアドレス　[email protected]

>>151
お疲れさん。かなり良いね。沢山要望述べていい？　優先度低で。

・一覧の[邦訳]の隣に[原文]へのリンクを張って欲しい。
・表紙にこのスレで活動してる旨の説明が欲しい（赤文字以外にも）
・>>119, >>114, >>151の案内ページを作ってリンクして説明できるようにしたい。
　（何度も張るのアレだから）

>>93
NSActionCell
http://nasi2ch.tripod.co.jp/cocoa_j/ApplicationKit/ObjC_classic/Classes/NSActionCell.html

同等の内容をメールしました。
眠いので変なところがあったらごめん。

>>152
わかった。でも寝て起きてからね（ｗ

あと万が一（突然ｻｸｰｼﾞｮの危険が無いとも・・・）のためにミラー立てました。
http://hoboking-electric.net/cocoa_jproject/
滞納で切られる可能性大でイヤなんだが・・・（ｗ

>>137
過去ログ参照♪

>ALL
梨さんにNSMovieをメールで送りました。
次はNSMovieViewに逝きます。
引き続き、がんばっていきましょ〜

HTMLについて、ちょっと細かい希望ですが、
ページ上部の注意書きは赤色にしないでﾎｽｨ…
赤だとうるさいので、黒かグレーがいいです。
あとHTMLでは段落中に（少なくとも一センテンス中に）<br>の改行を
入れるのはあまりよくないです。
（例えば、"参加者有志で、<br>"ってところ）

一応02/03/26　7:30現在アプしました。
http://homepage.mac.com/cocoa_jproject/
http://hoboking-electric.net/cocoa_jproject/

>>156
一応非公式なんで明記してるよ、という意味で赤なんですよ・・・
確かにうるさいはうるさいですよねぇ・・
まぁ、今日中に梨と話して善後策を検討しますんで、それまでご容赦を。

頭痛い梨です。

>>155
お疲れ様です。「の」氏に転送しておきました。

>>156
注釈は読み飛ばされるよりはうるさくいく方針がいいな、と。
あと、W3C準拠は、人手がいれば解決できるかも知れませんｗ

NSNibAwakingを訳したんだが、一部意味が通らないところがあるんだよね。
その部分は英文と併記してるけど、
これそのまま送っちゃっていい？

#検索しやすいように英文は、たぶん他で使われていないと思うsmallタグで囲ってある。

何箇所かのリンク不良を修正しました。
http://homepage.mac.com/cocoa_jproject/
http://hoboking-electric.net/cocoa_jproject/

>>160
html整形前の翻訳データなら
　梨：[email protected]まで。
html整形後のデータなら
　http://homepage.mac.com/cocoa_jproject/info.html
の送付のルールに従って「の」に送って下さい。

>>160
おけです。

遅くなりましたがNSBrowser出来ましたので、梨さん宛に送らせていただきます。

次はNSBrowserCellをちょちょいと仕上げさせてもらいます。

現在の残作業: NSMovie, NSBrowser
（71氏関連は、ｱﾋｬ氏担当の予定）

整形完了予定: 水曜朝（ほんとか？

'02/03/27　2:00現在アプしました。

http://homepage.mac.com/cocoa_jproject/
http://hoboking-electric.net/cocoa_jproject/

・今回追加されたページ
　http://homepage.mac.com/cocoa_jproject/ApplicationKit/ObjC_classic/Protocols/NSNibAwaking.html

>>166
NSMovie送りました。

NSBrowserは、ちょっとボリューム多いので、板徘徊しながら書けるか不明ｗ

'02/03/27　3:00現在アプしました。

http://homepage.mac.com/cocoa_jproject/
http://hoboking-electric.net/cocoa_jproject/

・今回追加されたページ
　http://homepage.mac.com/cocoa_jproject/ApplicationKit/ObjC_classic/Classes/NSMovie.html

>>168
お疲れ様です。たぶん今日はこのへんでｗ

お前ら最高！

>>166
NSBrowser送りました。

NSEvent取り掛かり中です。

注釈というか用語説明に
http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/ProgrammingTopics/BasicEventHandling/Tasks/HandlingMouseTracking.html
ここにリンク貼りたい、もしくは
"tracking-rectangle"
の一般的日本語訳を知りたい。
上のリンクには〜〜で知られているって書いてるけど漏れは始めて知ったよ。（鬱

リンク貼るとすれば、
../../../../TasksAndConcepts/ProgrammingTopics/BasicEventHandling/Tasks/HandlingMouseTracking.html
でいいのかな？

で、入れようと思う注釈
<span style="font: italic smoller;">
（訳注：参照 <a href="hoge">Handling Tracking-Rectangle and Cursor-Update Events in Views</a>）
</span>

>>173
> リンク貼るとすれば、

Classesからのリンクならたぶんそれで合ってますが、
とりあえず絶対パスで指定してもいいような気もします。

# 先見性が無いから嫌だって？

>>173
>"tracking-rectangle"
>の一般的日本語訳を知りたい。

俺も一般的日本語訳は、聞いたことないです。
この場合、trackingは「追跡」か「マウス追跡」、
rectangleは「矩形」か、思いきって「領域」ですかね？
追跡矩形で知られる、と言い切るのは辛いかもw
やっぱり、トラッキングレクタングルかな。

>>175
「マウストラッキング」はカタカナ語になってるし、Rectangleは
一般的に矩形と訳されている（領域だとRegionを想起しやすいので…）から、
トラッキング矩形でいいのでは。
まあこの文書でTracking-Rectangleに対する解説を行っているわけだから
何でもいいっちゃあ何でもいいかも知れない（w

'02/03/27　23:00現在アプしました。

http://homepage.mac.com/cocoa_jproject/
http://hoboking-electric.net/cocoa_jproject/

・今回追加されたページ
http://homepage.mac.com/cocoa_jproject/ApplicationKit/ObjC_classic/Classes/NSBrowser.html

皆様、お疲れ様でございます。
Webのほう、いいですねぇ。

わたしの翻訳の方ですが、ただいま自分のプログラミング経験のなさが、いたく足をひっぱっております（笑）
でもNSMovieViewはなんとか明日には終わらせますね〜（内容はともかく）

Appleに「著作権侵害されてまっせ」ってメールしときました。
お咎めあるかもね(藁。

>>179
かまわないよん。明記してあるし。

いやぁ、明記していても法的にはクロになるよ。
Apple or アップルが訴えればね。

>>181
別に訴えられても構わないってば。
で、そういう話はこっちのスレでね。煽りじゃないならば。
http://pc.2ch.net/test/read.cgi/jobs/1016604130/

煽りじゃないよ、、どういう了見かはわからないけど、
訴えられてもいいという態度はどうかな。。とそれだけこっちで言っとく。

「入門Cocoa」では"Tracking-Rectangle"は"追跡矩形"と訳されていたよ。
参考までに。

>>183氏に同意です。
現在、>>182のリンク先で議論を行い、誠実な対応を行いたいと思っています。
>>179の件に関しては協議中の上、今暫くお待ち下さい。

協議の結果が出ましたら、こちらのスレッドで報告させていただきます。

296 ：の ：02/03/28 00:01
威張ってる話ではないの。

で、どこを取って「友好的でない」と解釈しているの？

179 ：名称未設定 ：02/03/27 22:54 ID:HuCVSZ3Y
Appleに「著作権侵害されてまっせ」ってメールしときました。
お咎めあるかもね(藁。

っていう煽り厨に

180 ：の ：02/03/27 22:57 ID:YZqdkg3n
>>179
かまわないよん。明記してあるし。

ってレスしたから？

ケツ持つつもりが無い状態でいろいろ言われても
こちらとしては対応する気は無いって事です。
それともあなたが管理してあなたがアップルと対応しますか？
訴えられる云々をあのスレで論じてボランティアの人間の意気が上がるとでも？

その手の事への対処をするべく当方も動いています。
当然、当方も30過ぎの社会人として常識的にアップルと対応します。

これ以上この話題を進めるのなら上記のメールアドレス宛でメールで行ってください。
具体的な対応策をお持ちならば是非伺いたいですし

開発関係の翻訳はアップルの対応の不味さが出てるよね。

ttp://www.zdnet.co.jp/macweek/0112/12/c_mdkoike.html

ここでも有志による翻訳を提言しているわけだけども、自分の知る限り
この件に関しては続報が無かったと思う。
これってYESでもNOでもなく、答えていないってことなんじゃないかな。
つまりは保留って感じで。

classicの時みたく日本語書籍ほぼ全滅、もしくは情報古すぎってな感じに
ならなければいいけど。

どうも皆さん乙カレ様です。
>174
リンクは貼る必要ないみたいです。お騒がせしました。

>175-176,
いろいろ考えてくださってありがとうございます。

>184
ありがとうございます。
僕の持ってるCocoaの文献って今までオンラインドキュメント、
ついこの間、荻原本を買ったばかりなんです。
やっぱり訳書くには日本語文献がないとしんどいですね。
「入門Cocoa」の著者に合わせて"追跡矩形"でいきます。

>>85から>>129までの71さんの翻訳分整形終わりました。
３日程留守にしていたので遅くなりまして申し訳ない
http://nasi2ch.tripod.co.jp/cocoa_j/TasksAndConcepts/ProgrammingTopics/AppArchitecture/MVC.html
同内容のものをの氏にメールで送りました。
確認よろ

>>142以降も順次取りかかっております
今週少し事情で慌ただしいのでアップだけやや遅れる可能性を先に謝罪します（苦

1さん、71さん、他翻訳者諸氏、引き続き翻訳頑張って下さいne!!

>>189
お疲れ様です。

未整形のテキスト確認。

>>142-147

あ、これだけかな？　随分前進したなあ。。。

旧板のスレッドで、権利関係の協議に関して一段落つきましたので、
興味のある方はご覧下さい。
また、「の」氏と、>>1氏には、対応戴く形になりますので、よろしくお願いします。

あえて旧板で旧iMacとMacOSX
http://pc.2ch.net/test/read.cgi/jobs/1016604130/

>>191
サイトはいったん閉めるということになるのですか？
でしたら定期的に翻訳済みドキュメントと未翻訳ドキュメントを
貼っていただけると助かります。

>>192
未翻訳ドキュメントは本家を参照くださいな。
個人的には、訳したテキストはここに貼っていって構わないと思う。

過去のものについては、暫くはメールで対応したいです。
インデックスだけなら、ここに定期的に張れるかも。それでいいかな？

>192
とりあえず、漏れの場合Wedアーカイブで保存した
PDFでもよいかも

梨様、NSBrowserCellをnasi2chのアカウントに送らせて頂きました。

権利関係の議論でちょっと畏縮しておりましたが、結論が出たということで
喜ばしい限りです。

次はNSForm関係を順次やらせて頂きます。

　甘いよー！

　http://www.toshiba-emi.co.jp/yusa/release/index_j.htm

　聞！（←中日辞書で調べてね！）

>>195
旧板で返答しましたｗ

なにやらAJから返答があった模様。
状況を把握次第、こちらで報告させて戴きます。

http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/ProgrammingTopics/AppArchitecture/Concepts/Scripting.html

スクリプティング

このセクションは、Cocoaのスクリプティングサポートを記述します。もしAppleScriptとスクリプティング
に不慣れであるなら、最初に「Mac OS XのAppleScript」を読むべきです。


スクリプティングとモデル層


Cocoaフレームワークでのスクリプティングサポートは、アプリケーションがそのモデルオブジェクトを
通してスクリプティングを実装することを容易にする方向に向けられます。AppleScriptは、一度もアプリ
ケーションのユーザーインタフェースをスクリプティングすることを奨励したことがありません。回数多く、
スクリプトが何かをする最も効率的な方法は、ユーザーがアプリケーションで同じことをする方法ではない
からです。もしスクリプティングがもっぱらユーザーインタフェースにアクセスを供給することに関わって
いたなら、（それは、ただ見せかけの journaling でしょう。 it would just be glorified journaling.）

モデルオブジェクトで動作するスクリプトは、バッチ処理に似ています。それは、オペレーションを実行し、
ユーザーの関与を必要としなかったり、必要としたりします。データベースからデータを抽出し、他のアプリ
ケーションを通してそれを処理して、それから、新聞のための案内広告ページを生成する、ページレイアウト
プログラムにそのすべてを送る、スクリプティングシステムは、そのようなバッチ処理の例です。バッチ処理
での目標は、ユーザーを巻き込むことではなく、作業がなされるために、直接アプリケーションのモデルオブ
ジェクトのところに行くことです。

しかしながら、時々、スクリプティングする間に、ユーザーインタフェースのある特定の外見を装うことを望む
かもしれません。ビューオブジェクトで動作するスクリプトは、マクロに似ています。それは、アプリケー
ションの非常に特定の操作、通常比較的小さい、独立のものをします。その目的は、ユーザーのために小さい
反復的な仕事を自動化することです。例えば、ページレイアウトプログラムで、選択されたグラフィックを得て、
その下に見出しを置き、整列を手伝うために、結果として生じているグループの外のエッジに沿って青いライン
ガイドを組み立てる、スクリプトは、このタイプのスクリプトでしょう。

ユーザーが少しの準備（グラフィックを選択するような）をして、スクリプトを呼び出して、それから、
それが完了したとき繰り返すという点で、このようなスクリプトはマクロのようです。このタイプの
スクリプトのために、アプリケーションは、そのユーザーインタフェース構造のいくらかをスクリプタブル
にしなければなりません − 例えば、ウインドウと選択をスクリプタブルにする必要があるかもしれません。
しかしながら、これらのユーザーインタフェース構造をスクリプタブルにすることは、直接モデルオブジェ
クトをスクリプティングするために提供するサポートの付け足しであるべきです。

スクリプティングのために、アプリケーションのモデル層を設計することにおいて避けるべき、ある特定の
プログラミングの習慣があります。多くの単純なアプリケーションは、そのビュー層で（すなわち、ユーザー
インタフェースオブジェクトで）状態を保持します。例えば、プリファレンスパネルコントローラーは、
Booleanの属性の状態がプリファレンスパネルのチェックボックス内で「ストアされ」、取り出され、stateと
setState:メソッドで割り当てるように、実装されるかもしれません。しかしながら、ビューオブジェクトで
状態を保持することは、一般にMVCパターンと対照的ですから、ドキュメントのモデルの部分であるデータの
ための良い方策ではありません。もしスクリプトが状態にアクセスし、変更が可能である必要があるなら、
状態値はビュー層から切り離されて、モデルオブジェクトで、あるいは、もしそれがモデル層に属さないなら、
コントローラーオブジェクトで、保管されるべきです。しばしば、この分離は、スクリプティングを考慮しない
場合でさえ、必要、あるいは望ましいです。

例えば、もしプリファレンスパネルコントローラーがパネルのコントロール内にだけ、現在のプリファレンス
設定を保管するなら、パネルをロードしない限りは、現在の設定についての質問に答えることができません。
もし、たとえユーザーがプリファレンスパネルを持って来なかったとしても、アプリケーションの他の部分が
プリファレンスについて発見する必要があるなら（ありそうな状況です）、プリファレンスコントローラー
自身が設定をストアしたほうが、もっとずっと良いでしょう。これは、それが実際に必要とされるまで、
nibファイルをロードする（幾分高くつく動き）ことを避けることを可能にするでしょう。

同じ議論が同様に基本的な振舞いのために真です。例えば、もし検索パネルを持っているなら、Find Next
ボタンによって呼び出されるアクションメソッドで、実際に検索を実行するためのロジックを実装する
代わりに、おそらくドキュメントクラスで、あるいは、検索を実行することができるモデルオブジェクトで、
若干のAPIを定義するべきです。Find Nextボタンのアクションメソッドは、その時このAPIを呼び出すで
しょう。このスキームの利点は、スクリプトがドキュメントを検索することが可能であることを望むとき、
スクリプトを、検索パネル自身の使用を必要とする代わりに、ドキュメントあるいはモデルAPIを通して
動かせることです。


スクリプティングとキー値コード化


Mac OS Xのスクリプティングは、AppleScriptコマンドを実行するための自動的なサポートを提供する
ために、キー値コード化に非常に頼ります。キー値コード化では、それぞれのモデルオブジェクトは、
それがサポートするキーの集合を定義します。キーは、モデルオブジェクトが持っているデータの特定の
部品を表現します。スクリプティング関連のキーの若干の例は、「words」、「font」、「documents」
と「color」です。

キー値コード化APIは、そのキーの値についてオブジェクトに問い合わせて、それらのキーの新しい値を
セットする一般的な、そして自動的な方法を提供します。キー値コード化のプリミティブなメソッドは、valueForKey:とtakeValue:forKey:です。NSObjectは、キーに基づいた標準アクセッサーsetとgetメソッド
を使うために最初に期待される、これらのメソッドの汎用的な実装を持っています（「color」という名前
のキーのためのcolorとsetColor:のような）。もしオブジェクトのクラスがアクセッサーメソッドを実装し
ないなら、キー値コード化は、直接インスタンス変数（「color」）の値をセットするか、取得します。
キー値コード化は、2つのプリミティブに関して実装される、多くの他の拡張されたメソッドを定義します。
しかし、スクリプティングサポートを実装することについて、ほとんど関係を持ちませんから、ここで論じ
ません。

アプリケーションのオブジェクトを設計するとき、モデルオブジェクトのためのキーの集合を定義して、
アクセッサーメソッドを実装するべきです。それから、アプリケーションのためのスクリプトスイート
を定義するとき、それぞれのスクリプタブルなクラスがサポートするキーを指定することができます。
もしキー値コード化をサポートするなら、「ただで」多くのスクリプティングサポートを手に入れる
でしょう。

キーは、3つのカテゴリーに分類されます。それはリレーショナル・データベースに起源を持っています。
キーは、属性のキー（例えば、「color」）、to-one関係のキー（ドキュメントのNSTextStorageオブジェ
クト）、あるいはto-many関係のキー（アプリケーションのドキュメント）のいずれかです。この分類は、
スクリプティングも含めて、リレーショナル・データベース以外の状況でも意味をなします。AppleScript
の用語では、これらのキータイプは明らかに属性(properties)と要素(elements)にマッピングされます。
AppleScript要素を関係のキーであると考え（to-oneとto-many関係の間が区別されない）、AppleScript
属性を属性のキーであると考えてください。

それで、なぜキー値コード化はスクリプティングのためにそれほど重要なのでしょうか？AppleScriptでは、
「オブジェクト階層」がアプリケーションでのモデルオブジェクトの構造を定義します。例えば、ドローイング
アプリケーションがドキュメントを持ち、それらのドキュメントはグラフィックのオブジェクトを持って
います。グラフィックのオブジェクトはそれぞれ流し込みカラーとラインの太さを持っています。たいていの
AppleScriptコマンドは、親コンテナから子要素へと、このオブジェクト階層を下方に掘り下げることによって、
アプリケーションの中で1つ以上のオブジェクトを指定します。

例えば、若干のグラフィックスが文 graphics 5 thru 7 of the document 'MyDocument' of application
'MyDraw' （アプリケーション「 MyDraw 」の書類「 MyDocument 」のグラフィック5から7）によって
識別されるかもしれません。それらが作用されることができるように、これらのグラフィックスを見いだす
方法がなければなりません。キー値コード化は、すべて自動的にこの検索をします。アプリケーションは、
キー「documents」を持ち、それはto-many関係です（アプリケーションが複数のドキュメントを開くこと
ができるから）。それぞれのドキュメントは、それが表現するファイルを識別する「name」のキーを持って
います。MyDocumentという名前のドキュメントを見つけるために、フレームワークは、そのアプリケー
ションのすべてのドキュメントを要求して、そして、MyDocumentという名前のものを見つけるまで、
それぞれの名前をチェックすることができます。キー値コード化は、キーの値を求めることについての一様
な方法（valueForKey:）を定義しますから、このすべての作業は、開発者からの追加の努力なしに、自動的
に果たすことができます。同様に、キー値コード化-駆動のスクリプティングシステムは、ドキュメントを
見つけた後に、「graphics」のキーを得て、それから5から7の要素を得ます。

もしあなたがAppleScriptについて前に経験を持っているなら、Carbonアプリケーションで、その仕事が
正にMac OSのオブジェクトサポートライブラリで記述されていることを知っています。オブジェクトサポー
トライブラリのCocoaバージョンは、どのようにオブジェクト指定(object specifiers)を評価するために
キー値コード化を使うべきかを知っています。特にライブラリを呼び出して、あらゆる種類の評価ハンドラ
に渡す代わりに、Cocoa開発者は、単にキー値コード化メカニズムを当てにできます。もちろん、もし
パフォーマンス理由のためにそうする必要があるなら、あるいは、もしスクリプティングのモデルが自動的な
サポートのために作動するのに十分密接に内部的なモデルと一致しないなら、評価にいっそう直接関与し得ます。

キー値コード化の有用性は、オブジェクト指定の評価にとどまりません。AppleScriptによって定義された
コアコマンドの大部分が、キー値コード化に基づいたCocoaでのデフォルト実装を持っています。例えば、
Get DataとSet Dataコマンドは、もしそのオブジェクトのクラスが適切にそのキーを定義し、標準アクセッ
サーを実装するなら、サポートのために、オブジェクトの追加のコードを必要としません。同じことがMove、
Clone、Delete、Create、CountとExistsコマンドについて当てはまります。たいていのスクリプトコマンドは、
キー値コード化で包括的に実装されています。それで、たいていのモデルオブジェクトはまったくそれらの
ことで心配しなくてもよいでしょう。もしモデルクラスが特別な方法で特定のコマンドを取り扱わなくては
ならないなら、たとえコマンドがデフォルト実装を持っているとしても、そうすることができます。

オブジェクト指定(object specifiers)


スクリプトコマンドは words whose color is red of the fourth paragraph of the front document of
application 'TextEdit' （アプリケーション「TextEdit」の前面の書類の4番目の段落のカラーが赤である単語）
のようなAppleScript表現です。Cocoaアプリケーションの中で、このコマンドの要素は、
NSObjectSpecifierクラスのオブジェクトによって表現されます。そして、それらが表す、潜在的な
オブジェクトを評価するためにキー値コード化を使います。この抽象クラスの具体的なサブクラスが、
インデックスリファレンス（word 5）とフィルターリファレンス（words whose color is red のような、
テストあるいは「whose」節）のような、AppleScriptによってサポートされる、さまざまなリファレンス
形式を表現します。

NSObjectSpecifierはネストされることができます。それで、前の段落での例は、実際に3つのリファレンス
の連鎖によって表現されるでしょう：単語のためのもの、段落のためのもの、ドキュメントのためのもの。
（指定は、コマンドが実行される時点でTextEdit内に存在しますから、フレーズ application 'TextEdit'
は表現を必要としません）NSObjectSpecifierは、どのようにそれらを含んでいる指定の中でそれら自身を
評価するべきか知っています。明示的なトップレベルの指定（例での前面の書類）は、通常アプリケーション
自身であるデフォルトトップレベルコンテナの中でそれ自身を評価します。

アプリケーションをスクリプタブルにするために、指定について多くを知る必要はありません。なぜなら
Cocoaの組込みのスクリプティングサポートは自動的に指定を作成し、解決することができるからです。
しかしながら、もしアプリケーションが組込みのサポートから拡張されたスクリプティングの必要性を持って
いるなら、どのようにそれらの元に動作すべきか知る必要があるでしょう。例えば、記録をサポートすること
を望むアプリケーションは、記録されたアクションのためのオブジェクト指定を作成する必要があるでしょう。

スクリプトコマンド


スクリプト作成者がアプリケーションにコマンド（set the height of the first rectangle to 37
（最初の矩形の高さを37にセットしなさい）のような）を送るスクリプトを実行するとき、アプリケー
ションは、スクリプトコマンドをカプセル化するAppleイベントを受け取ります。Cocoaの組込みの
スクリプティングサポートは、AppleイベントをNSScriptCommandクラスに基づいたスクリプト
コマンドオブジェクトに変換します。アプリケーションが多くの連続したスクリプトコマンドを受け取る
かもしれません。しかし、それぞれが個々で、別個で、完全です。

スクリプトコマンドは、NSScriptCommand自身のインスタンスであるかもしれません。しかしCocoaは、
同様に、Get Data、Set Data 他のような標準AppleScriptコマンドを取り扱うために、そのデフォルト
実装がキー値コード化を使う、NSScriptCommandのいくつかのサブクラスを提供します。もしコマンド
が有効な形式に変換されるための特別な処理を必要とする引数を持っているなら、サブクラスが同じく
必要とされるかもしれません。

NSScriptCommandは、コマンドのレシーバ（１つあるいは複数の）を識別するオブジェクト指定を持ち、
コマンドによって定義されたどんな引数も、別のオブジェクト指定を持つことができます。コマンド引数は、
実際の値か、あるいは、アプリケーションのオブジェクト階層の中のどこで実際の値を見いだすべきかに
ついて明らかにする、オブジェクト指定であり得ます。

スクリプタブルなクラスは、何のコマンドをサポートするかについて意志表示します。デフォルト実装を
持っているコマンドのために、スクリプタブルなクラスは、それを使うことを選択することができます。
あるいは、それら自身がコマンドによって必要とされる振舞いを実装することを選択することができます。
デフォルト実装がないコマンドのために、スクリプタブルなオブジェクトは、コマンドを処理するメソッド
を実装し、指定しなくてはなりません。

スクリプトコマンドがそれらをサポートするクラスから分けられていることは、奇妙に思われるかもしれません。
これは標準のオブジェクト指向のスタイルとは違うけれども、AppleScriptは、オブジェクトの広範な集合
に対して作用する、コマンドの小さい集合を持つように設計されます。これはある利点を提供します − 例えば、
もしコマンドがキー値コード化を通して実装されるのに十分汎用的であるなら、それはCocoaフレームワーク
にコマンドのためのデフォルト実装をサポートする能力を与えます。

スクリプトスイート


AppleScriptは、「スイート」にスクリプティング情報をまとめます。スイートは、クラス記述の集合、
コマンド記述の集合、そして、それぞれのサポートされるAppleScript方言のための用語の集合から
成り立ちます。Mac OSで、アプリケーションがサポートするスイートは、アプリケーションの「aete」
リソースで定義されます。Cocoaフレームワークで、スイートは、プロパティリストで定義されます。
Mac OS Xと一緒に配付された、Property List Editorアプリケーションで、プロパティリストを作成し、
調べることができます。

どんなフレームワーク、アプリケーション、あるいはロード可能なバンドルも、スクリプトスイートを
宣言することができます。アプリケーションがサポートするスイートの集合は、アプリケーション自身、
それがリンクするフレームワーク、そして、それが動的にロードするバンドルで定義されたすべての
スイートの結合の結果です。Cocoaフレームワークは2つのスイートを宣言します。それで、どんな
スクリプタブルなアプリケーションも、自動的にこれらのスイートをサポートします。これらのスイートは、
コアスイートとテキストスイートです。それで、もしオブジェクト階層を通してNSTextStorageオブジェ
クトへのアクセスをさらすなら、そのNSTextStorageオブジェクトは、標準テキストスイートを通して、
完全に、自動的にスクリプタブルです。もしアプリケーションがアプリケーション キットのドキュメント
アーキテクチャ（下に論じられた）を使うなら、ドキュメントに適用されることができる、すべてのコア
スイートコマンドを自動的にサポートします。

スイートを記述するプロパティリストは、スクリプティングフレームワークによって必要とされる、その
スイートのクラスとコマンドについてのすべての情報を含みます。クラスのために、これは、クラスと
それらのタイプのために、すべてのサポートされるキー（属性と関係のキー）を含みます。同様に、クラス
がサポートするすべてのコマンド（クラス自身のスイートと他のものからの両方とも）を含みます。コマンド
のために、これは、引数の数とタイプ、それらが必須とされるか否か、そして、リターンデータタイプを含み
ます。スイート定義は、同様に、クラスとコマンドを、スクリプトコマンドを表現するAppleイベントで
データを構造化するために使われた適切な4文字のコードにマップするために、必要な情報を含みます。

Cocoaアプリケーション開発者は、一般に、スクリプティングをサポートするために、直接Appleイベント
を扱わなくてもよいです。なぜなら、Cocoaが、入ってくるAppleイベントをスクリプトコマンドに変換
するからです。しかしながら、クラス、コマンド、キー、関連した情報を、Appleイベントで使われる
コードにマップするために、必要な情報を提供しなければならないでしょう。

言語非依存のリソースであるスイート定義に加えて、スイート用語は、さまざまなクラスとコマンドで
使われた実際のスクリプティング語彙を識別する、方言特定の用語情報を含みます。

スイート定義とスイート用語は、スクリプタブルアプリケーションでさらに詳細に記述されます。


組込みのスイート


Cocoaフレームワークは、2つの標準スイート、コアスイートとテキストスイートを定義します。加えて、
Cocoaクラスは、これらの標準スイートのためのスクリプティングを実装します。それで、例えば、
NSTextStorageオブジェクトはテキストスイートを使って完全にスクリプタブルです。そして、
NSDocumentControllerとNSDocumentオブジェクトは、ドキュメントのために意味をなす、
コアスクリプティングコマンドをサポートします。



カスタムのスイート


どんなアプリケーションも、それ自身のスイートを定義することができます。このスイートで、
新しいスクリプトクラスと新しいスクリプトコマンドを定義することができます。

主催はWebページ閉じたのに、まだ著作権侵害行為を続けてる奴がいるな…。

CoreGraphics関係2件だしましたが、
リファレンスは翻訳の優先度が低いので、
かんばってください。
http://developer.apple.com/ja/techpubs/

>>207
(・∀・)ｶｴﾚ!!

>>207はMSの工作員か。

>>209-210
ほんと2chは著作権意識が希薄だね…。
あきれられてもしょうがないよ。
アップルから回答が来るまで、
掲示板には書き込まず、メールで送った方がいい。
俺は207じゃないよ。

言い方に少々刺があるが、211に同意。

ちょっと目を離してたんですが、権利関係について、かなりの進展があったのですね
すばらしいです

あきれられ云々はおいといて、今の状況からすると私も、しばらくここには出さない方が良さそうかなと思います。

しかし、71さん仕事早いっすねぇ・・・
私もがんばらないと。

NSForm送らせていただきました＞梨様

そろそろ用語統一とか考えた方がいいかも、と言ってみるテスト

ageage

>>213=1さん
本当はこの企画の発起人である１さんに御相談してから、
ADC@JPと話を進めたかったのですが、時間のある時にやってしまおう、
という事で勝手ながら著作権二次使用承諾と再配布（公開）承諾の申請をさせて頂きました。
詳しい顛末は旧板の方のスレにありますが、
ADC@JP側から、米ADCの担当部署の方へ直接申請をしてくださるそうです。
尚、日本語でのCOCOA開発環境支援が目的であること、非営利であることを前提に申請してあります。

ADC@JPから、申請を受け付けた事と、時差等の関係上解答が多少遅れるので待って欲しい、
という主旨の報告が来ておりますので、週明けには結果がいただける事を期待して待ちたい所存です。

うちの弁護士曰く、こういった掲示板に書かれている内容に関して、
著作権侵害を定義するのが難しいので何とも言い難いとの事ですが、
正式解答が得られるまで表立って掲示しない方が得策かもしれません。

>>214
正式解答が出るまで、翻訳は各自ローカルで行って、
こちらで用語統一ともし可能ならオリジナルの用語集作るというのは如何でしょうか？
弱輩の意見なので恐縮ですが、
例えば各専門用語の日本語訳の定義をまとめた参照ライブラリがあれば、
今後楽かな、と思うのですが...


# 今回、ADC@JPが非常に好意的な対応をしてくださっているので、
# よいお返事をいただけることを切に願います。

NSForm届きました。

>>214
協議の対象になりそうな単語と、既出の中で個人的にいいと思った訳。

Inherits from:　継承
Conforms to:　準拠
Declared in:　宣言
Class Description　クラスの概要
Adopted Protocols　採用されているプロトコル
Programming Topics　プログラミング・トピックス
Method Types　メソッドの種類
Class Methods　クラスメソッド
Instance Methods　インスタンスメソッド
See Also:　参照

もっといい言葉や、共通化すべき言葉があると思うので、
是非みなさんの意見を賜りたく。

>>216
って、そういう事じゃないの？ｗ

そんなことより、MFCなりActiveXの勉強でもした方が良いのでわ(w。

2.1.0α出てます。αなので危険です。（用語統一）
ttp://DesireForWealth.com/software.shtml

# nanchara kancharaってな語句は「ナンチャラ・カンチャラ」の
ように「・」を入れる or 入れない等も統一した方が読み易そう。

あと些事なんですがNSBrowser訳してて疑問に思ったのが
データのヒエラルキーを表現する「branch」と「leaf」です。
文字どおり「枝」と「葉」で、英語ではそのまま使えるらしい
のですが日本語ではどうも変なので「分岐部」と「末端」と
訳してます。

何かいい訳ありませんかね？

>221
俺は、枝と葉の方がしっくり来るんだが・・・

>>222
禿頭胴太い

木の枝葉でわかりやすいと思うが。
ふつーに使うけど。

NSFormCell送りました＞梨様

>>222-223
単独だとヒエラルキーの枝葉で分かりやすいんですが、「枝のセル」「葉のセル」
と書くと途端に分かりにくくなってしまうんです。

NSFormCell届きましたー。

>224
>単独だとヒエラルキーの枝葉で分かりやすいんですが、「枝のセル」「葉のセル」
と書くと途端に分かりにくくなってしまうんです。

なるほど
しかし、個人的には枝と葉の方が
ツリー型のデータ構造なんかとイメージが合ってしっくりくる

うーんセルを細胞と訳して「枝の細胞」「葉の細胞」だと、なんだかなぁだし

翻訳ってﾑｽﾞｶｼｲ
某スレでもローカライズで議論してるが、やっぱﾑｽﾞｶｼｲ

みなさまお疲れさまでございます。
NSMovieViewがようやくできたんで、梨氏に送りました。

次はNSTableViewあたりいってみようかな。

>>216　= ｱﾋｬ氏
>本当はこの企画の発起人である１さんに御相談してから、
>ADC@JPと話を進めたかったのですが
いえいえ、全然ＯＫです。
結果の方は来週始めに期待ですね。
いい方に行くといいなぁ。

NSMovieView届きました。

って、思わず旧板に書いてた。。。

age!

で、結局あれからどうなったの？

>>230
返答待ちのまま、返答が来ないで止まってるよ。

訳者のみなさまは、気兼ねなく訳文メールをください。
たぶん今週中には良い結果が届いている事でしょう。

NSToolbarItem、シコシコ訳させて貰ってます〜

>>231
なんとなく、返答の確認が来週になるっぽいです。

メールでは無くここに乗せてくれる訳者の方々には
待ち遠しいかと思いますが、いましばらくご辛抱ください。

来週頭の段階で返答が来ていなければ、
成果物を不特定多数へは非公開のまま、
プロジェクトだけでもなんとか進めたいと思っています。
（たぶん、やるとしたら、ユーザグループかメーリングリストベースです）

それについてもご意見など戴けたら光栄です。よろしくです。

祭の後の寂しさが〜♪嫌でもやってくるのなら〜♪

別に祭りじゃないし
とりあえず回答待ちか・・・
(*ﾟ∀ﾟ)ｱﾋｬも忙しいみたいだし
梨も来週までは忙しいみたいだ・・・梨の場合いそがしくても旧板来るが。。。

いくよー

遅ればせながらNSToolbarItem上がりました。4月からは仕事が始まってしまい
それほど速いペースでは出来ないと思いますが、ﾏﾀｰﾘと続けて行きましょう。

sage

>>238
なんじゃそりゃ

　　　| ＼
　　　|Д｀)　ﾀﾞﾚﾓｲﾅｲ･･ｵﾄﾞﾙﾅﾗ ｲﾏﾉｳﾁ
　　　|⊂
　　　|


　　　　　♪　　Å
　　　♪　　　／ ＼　　　ﾗﾝﾀ ﾀﾝ
　　　　　　ヽ(´Д｀;)ﾉ 　　ﾗﾝﾀ ﾀﾝ
　　 　 　　　 (　 へ) 　　　ﾗﾝﾀ ﾗﾝﾀ
　 　 　 　 　　く 　　　　　　ﾀﾝ



　　　♪　　　　Å
　　　　　♪　／ ＼　　　ﾗﾝﾀ ﾗﾝﾀ
　　　　　　ヽ（;´Д｀）ﾉ　　ﾗﾝﾀ ﾀﾝ
　　 　 　　　 (へ　 ) 　　　ﾗﾝﾀ ﾀﾝﾀ
　 　 　 　 　　　　 >　　　　ﾀﾝ

(・∀・)ﾐﾀﾖｰ!!

理　あれど　利　吾等に在らず
志　高かろうとも　私事の範に没す
注がるる　ココアの苦さ味わへど
何時の日か　薫風猛からむとぞ

>>242
うまい！　おーい山田君、一枚やっとくれ。

487 ：(*ﾟ∀ﾟ)ｱﾋｬ ：02/04/05 22:21
お久しぶりにございます。
あまり良く無い報告を携えて今戻りました...
ADC@USのﾊﾞｶｧｱｱｱｱ!!ｳﾜｧｧｧﾝ
490 ：●~* ：02/04/05 22:32
>>487
その悲しみを乗り越える為にも「出直しﾇｰﾄﾞ」ｷﾎﾞﾝﾇ
492 ：●~* ：02/04/06 01:13
見たら夢から覚めて大人になっちゃうよ・・・
493 ：梨 ：02/04/06 01:23
>>492
それでも良かったんだけどね。
はっきりした方が、出来る限りの対策が可能だったから。
ま、曖昧であれ、こういう結論が出てしまった以上、しかたないな。
大きな動きが無い限り、ここでプロジェクトを解散せざるを得ない。
無理に続けても、新板の潔癖君が追いうちをかけてくる事請け合いだ。
いままでの成果物は、まとめてアーカイブにして持っておくよ。
参加した人で、このアーカイブが欲しい人は、メールくださいな。

記念age

翻訳者ならびに参加者の皆様へ


旧板でのADCに対する質問の結果です。

>大変恐縮ではございますが、TechNoteへのリンクをされることは自由なのですが、
>本文自体をApple Technote以外のサイトにて公開することは許可できないとのことです。
byADC@US
http://pc.2ch.net/test/read.cgi/jobs/1016604130/529

との事で、>>244氏の紹介もありますが、
「翻訳」したドキュメントを公開する事は出来ないという話になってしまいました。

現在、下記のスレで、ここの>>1氏の
「とにかく日本語の資料がないcocoa開発環境を、みんなで改善しちゃいましょう！」
という目標に対して、「活路」を相談中ですので、
興味のある方は一度目を通してみてください。

あえて旧板で旧iMacとMacOSX
http://pc.2ch.net/test/read.cgi/jobs/1016604130/

ちょっと残念な結果となりましたね・・・。

旧板のほうも見てみたいと思います。
訳者のみなさまもお疲れ様でした。

腑甲斐無いAJめ....

>大変恐縮ではございますが、TechNoteへのリンクをされることは自由なのですが、
>本文自体をApple Technote以外のサイトにて公開することは許可できないとのことです。

こんな事言うくらいならさっさと公式翻訳しる！

別に続けても問題はないと思われ。
アポーが訴訟しようともアポーのイメージが悪くなるだけだから訴訟はされない。

任務…完了。

こういう話はアメリカのMac系メディアや
Wired辺りに垂れ込むとうまく進むかもしれん。
一般のアメリカのMacユーザーやデベロッパーが
圧力をかけてくれるかも。
彼らの方がアップルジャパンよりAppleに対する
影響力が強そうだ。

2ちゃんなんだから続ければ？どうせ匿名掲示板でしょ。
なんか問題出てもひろゆきが勝手に裁判に行ってくれるよ。
消されてもGoogleのキャッシュにしばらく残るし（ﾜﾗ

>>252
もう少しこちらがきちんとした組織になっていればあらゆる方面から
圧力をかけるという意味でアリなのかもしれませんが･･･。
一応まだAJとの交渉を続ける事になったのでその結果を待った方がいいかも。
まあたれ込みは最終手段ということで。

こういう案は旧板の方で出していただけるとレスのつながりが良いかと。

>>253
実行委員の人達や訳者の方々は「2ちゃんねら」としてではなく
「Macユーザー」として翻訳活動をしたいと考えています。
他人が尻拭いしてくれることを当てにしていないと思います。


ログだけでも残せればそれはそれで有意義だとは思いますが･･･。

牛乳入れすぎた。

最初は無許諾で行こうと思ってた私がいうのも何ですが、許可を取りに行ってもらえな
かったからだまってやる、というのはちょっと一貫性を欠くような気がします。

とりあえず、あのリファレンスと同じ情報を持つ、新しいAPI解説ページを作る、とい
うのに一票。
翻訳自体が目的ではないですもんねー

>>257
でもやっぱ純正ってのに憧れる。
たれ込みが最適じゃないか？それこそユーザの意見って感じで。

まあ同時に二つ以上の手段をとってバランス良く交渉事を運ぶのが
普通なんだろうけどな。
こうするのが正しい筋だとか、自分の行動を自分で制限するのは、
既にその時点で交渉相手に一歩譲ってるわけだし。
アップルジャパンとかは、きちんと複数同時進行をやるはずだよ。
一応まともな企業なんだし。

こういうのはどうよ...
メーリングリスト立てて、翻訳なり、作った資料は、そちらで配布。
「保存先は、みんなのHDD」ていうのは。

>>260
なるほど。

私は、アップルとの交渉を継続するのを前提としつつ、暫定処置としてなら賛同します。
ＭＬなら、大学のゼミで教科書を訳すみたいなのに準じるとして、法との抵触の問題
を回避し得る・・・かもしれないし（笑）

ただ、やっぱり、開発環境を改善するという趣旨からは、単なる翻訳にしろ、新しい
リファレンスにしろ、結果物を広く公開することに意味があると思うので、ウェブに
上げるという点は、できる限り維持したいです。

そんなわけで、このセンでいくとしても、あくまで臨時であることを望みます。

MSの爪の垢でも煎じて飲め>Apple

>>261
現状webで公開しないにせよ、成果物のまったく見えない状況では
テンションも上がらない。
はやめに、ML立ち上げておくのがとりあえずベストかも。

正直、やる気無くした。

age

アポー、頭にくるな。

アップルの微妙な立場を考えてこそ「無許可でやる」という方法があったのに。

アップルは「やらせておきたいけど、知らないふりをしていたい」と思っていたはず。
わざわざ「やっていいですか？」と言われたら断らざるを得ない。

相互の利益を考えて、アップルの立場を思いやるからこその「無断」という手段を
とるべきだったと思う。

荒れるし、アップルへ報告（ちくり）がいくだろ。

つーわけで、最初の主旨どうり勝手に翻訳する勇者キボン

っているわけねーか

それにアップルが「知らない振りをしていたい」なんてどこで言ったんだ。
そりゃ思いやりじゃなくて思い込みだ。

こういう点でもWindows>>>>MacOSですな。

もう終わりか？

7年程前、NeXT関係の書籍丸ごと一冊訳したけど、出版社に売れなくて
没ったなぁ。500ページくらいあったっけ。

せっかくだから、>>271のソースを希望しよう。
どんな実例が出てくるのか楽しみだ。

早く答えろ>>271。

>>274
日本人へのプログラミング環境がWindows>>>>MacOSだってことは、
MSDN日本語版の存在だけで充分証明されてますが(藁。

>275
そうだそうだ。
MDJとMacTechJapanを復刊しる！

>>273
ついでにこっちも訳して。

>>273
とりあえず、それ公開しる！

過去の成果物をアーカイブにまとめました。

参加者のみなさんにお送りいたしますので、
欲しい方は [email protected] までご連絡下さい。

収録物

・テキスト形式
9,134 NSToolbarItem.txt
4,142 NSFormCell.txt
4,635 NSForm.txt
3,387 NSBrowserCell.txt
NSMovieView.txt

・プログラミングトピックス
AppArchitecture.html
AppContents.html
MVC.html

・Obj-C APIの概要
IntroAppKit.html

・Obj-C APIのクラス
28,551 NSToolbar.html
19,840 NSOpenPanel.html
23,142 NSCursor.html
56,647 NSBrowser.html
15,295 NSMovie.html
20,503 NSActionCell.html


配布形式
lzh, zip, tar.gzの中から指定の圧縮アーカイブ形式。100kb程度です。

利用条件
・個人的使用にとどめ、公開や転載や配布をしないでください。

翻訳に参加してない人でもいいの？
ﾎｽｨ…

梨にメアド知られるのはちょっとなぁ…。
捨てでもケチが付きそうで嫌。

ちなみに今回の配布は、あくまで今後の活動では無く、
今までの活動に対する成果の共有を目的としたものです。

>>280
配布規定とかは考えてないけど。
「不特定多数」にならない程度に配布したいんだけど、
厳密に考えると「直接の参加者」だけの配布になるかも。

>>281
君が参加者なら、他の信頼できる参加者を経由して手に入れる方法があるかと。

要するに敗北かよ。
使えない結論だな…

梨は今回もまたおいしかったということさー

まあ勝手翻訳を許すと、誤った訳が広まる可能性があるなど
品質保持が難しくはなる危険性はあるのだが、
自分とこで翻訳する度量もない癖に、固いことだけいうAppleはもうほんとにああクソ。
iPodに名前入れサービスなんかしてんじゃねぇヴォケが。

>285
勘違いしてるようだから書いておく
許可をクレないのは、AJじゃなくUS
あと、翻訳に度胸は必要無いと思われ、ただ人手があれば・・・

>286
勘違いしてるようだから書いておく
AJに足りないのは度胸じゃなくて度量

>>287
確かに、、、

>>286
別に勘違いしてないよ。
許可を出さないApple
Appleの言うことをヘコヘコ聞くだけのアップル

プログラマへのサポートの手厚い偉大なるマイクロソフトとはエライ違いだな。

だから勝手にやってたのにな…
手続き主義は弊害にしかならんよ

このｽﾚが落ちるとき、Appleが落ちる。...sage

一気に寂れたな。
手続き主義の弊害って批判は違うだろう。
勝手にやればそれはそれで問題が出てくる。
たらればはもういい。一応あげとこ。

Cocoa APIドキュメントが完成したらしいです。
日本語版はこれから翻訳するのだろうか？

あぁ〜、なんでMacって日本製じゃないんだろう？
だったら、リファも最初っから日本語なのに。
っていうか、頑張ってくださいよ、完訳。
もうAppleが何を言おうが無視だ！無視！

>>295
自分でやろう、とは露ほども思わない辺りがマッカー

>>296
このスレの存在が296には見えないらしい。

age

300

>>275
MSDNは自動翻訳に毛が生えた程度。意味わかんねぇよ！

今さらだけど、正式に申し入れれば、そりゃ不許可にせざるを得ないと思うなあ。
黙って続けても、わざわざ潰しにかかりはしないと思うけど。
そしたら実質OKということで。

>>302
ん、同意。

ただ、その場合に出てくるであろう煽りさんたちを
どうしたらいいかが問題になってたんだよね。

というか、実際に出てきてたし。

ここで勝手に翻訳やってるんですけど、こういうのはいいんですか？
なんて第三者にわざとらしく聞かれたら、
アップルもそれなりの対応せなならんわけで、
実質OKという見方も甘いといえる。
ならば正面から当たった方が、どう転ぼうといいじゃないかということだった。
アップルの方針もはっきりと分かるわけだしね。

＞なんて第三者にわざとらしく聞かれたら、
＞アップルもそれなりの対応せなならんわけで、
ここは全く違うと思うんだよね。
すべての質問にご丁寧に答えてくれるような企業なんて稀で、
ふつうは定型文的な返答がいいとこでしょ？
「確認されて頂きます」的な。

公に「許可」を与えるというのは一般に向けて「アップル御墨付き」を与える
行為になる（そう見られる）可能性が高いわけだから、そうそう安易に認める
わけにいかないのは企業としては当たり前ですよ。

ただし自社に不利益を与えるなら「拒否」するだろうが、利益になる（少なく
とも不利益にはならない）ものなら「黙認」という選択肢はあるんだから。
いずれにせよ不許可ならまずは「公開停止せよ」と言ってくるんだろうから、
それまでは実質OKと見なしてよいと思うんだけど。
（まあ、たぶん公開停止命令ということは無いと思うけど。

＃このスレの存在知らなかったんで、話蒸し返すようでスマン。

堂々回りやな。

>>305
後学のために、許可されずに進めた時に問題提起があったら、
どう対処すれば良いのかを教えて戴きたく。

>>306
＞問題提起があったら、
の意味がよく分からないんだけど、
アップルが「公開停止せよ」と言ってきたらという意味なら、
そりゃ少なくとも「公開」は「停止」するしかないわけだし、
「こんなことしていいんですか？」と煽りが言ってきたらという意味なら
「どうぞアップルにちくってね」と言えばよいだけだと思うけど。

>>305
翻訳ではないが、Appleがユーザサイトに対して削除命令、
もしくは要請を出したことは過去に何度もある。

今回は確か弁護士に相談したところ、「許可」じゃなく「承諾」なら
いけるかもしれないという判断があったんじゃなかったかな。

まあ、この件に限らず基本的な著作権を大事にしたい自分としては、
例え実質OKだろうとグレーな行為は好まないもんで、
そこらへんの判断は性格の違いということもありそうだけど。

＞翻訳ではないが、Appleがユーザサイトに対して削除命令、
＞もしくは要請を出したことは過去に何度もある。
それは主にスクープ的なサイトでしょ。全然話が違うじゃん。

＞基本的な著作権を大事にしたい
仮に同様の「承諾くれ」的な問い合わせが殺到したとしたら、いちいちそれに
対応してくれるような企業はないと思う。やるとしたらノーだけ。

簡易辞典的なものならどうなんでしょう？
翻訳ではなく「英文リファレンスなどを読みながら、使って理解したものを記録した」ような形で

このマイクロソフトを見習えよ…>アップル
http://www.microsoft.com/japan/developer/library/

>>311
少なくとも>>301にはどっちもどっちらしい w

漏れには月とすっぽんだがなぁ。Apple、日本軽視し過ぎ。

NSTextの仕様がわからなくて途方に暮れる梨です。

>>307
> 「こんなことしていいんですか？」と煽りが言ってきたらという意味なら
> 「どうぞアップルにちくってね」と言えばよいだけだと思うけど。

でもそれって、
「御社の著作権を侵害して御社に不利益を与えてる人がいますよ」
「御社の情報を無断転載されるとユーザとして迷惑なんで対処してください」
という問い合わせにもAppleは応じない、という前提が無いと駄目だよね。

今回、AJには一応実名で電話までして、
結果はともかく、誠実な回答は戴いているのだよ。
Appleが苦情の問い合わせに対して対処しない事は出来ないと思うぞ。

粘着煽りなら、尚更催促の電話とか入れそうだしな。どうよ？

そういうのは、AJ通さないで本社の
デベロッパーサポートに直接いうといいよ
配付を公認で許してくれるとは思えないけど、こうするといい
とか、ここまでなら黙認するとか教えてくれると思う

対応した人によって反応が違うのが気掛かりだけど
AJよりは融通が利く。AJは人の話聞いてるとは思えない
ほど、的外れで一本調子な解答しかしてこないからね。

>>315
旧板のスレにある経緯は見てないの?
それに黙認だと、結局は煽られると思うけど。
その辺はあちらの国のほうが厳しいだろうし。

結論：Microsoft >>>>>>>>>>>>>>>>>>> Apple

あふぉ

>>317
「>>>>>>>>>>>>>>>>>>>」＝">"×19＝シェアの比率、という意味だ罠。

そんな結論は聞き飽きたよ〜

>>319
いや、シェアもさる事ながら、プログラマへの配慮がその>と思われ。
まぁそういった配慮がアプリケーションソフトの数の差、
ひいては今日のシェアの差に結びついたワケだが。

なんだ、そうなの。てっきりMSがAppleをチクチク攻撃
している図かと思っちゃった。てへ。

>>320
そうか？

>>320
そうだよ。あとはVBの存在も大きいね。プログラム板では馬鹿にされてるけど。

>>323
いよいよもって、そうかぁ？

わかりますた。プログラム板でバカにされるような
開発環境が出るように頑張ります。

VBクソだってば

いや、DevToolsは十分VB並の役割を果たしている。
現にVBが出始めた頃みたいにショボすぎるソフトがちらちらと。

>>327
むしろREALbasicだろ。

>>324
そうだろ？
MS-DOSとの互換性だけで当時のWinがMacに勝ちぬけたとは思えないな。

>>329
「依らば大樹の陰」的、安心感を求める人間がいかに多いか、だけで
説明できちゃうでしょ。正解だったのかもしれないが、最近は、本当に
そうか？、と思うことが多いよ。

ちなみに、大樹とは元々はIBM のことな。IBMが判断を誤った結果が
MSと言うもう一つの大樹さ。うまく取り入ったとは言えても、それが
MSである必然性が有ったとは言えないだろーな。

小型コンピュータの開発言語環境を作らせては
AppleはMicrosoftどころか、Borlandの足元にも
及ばなかったからなぁ。
大樹は始めから大樹だったワケでもなかったワケで。

なにいってんの？

>>331
だから、IBMに寄り掛かろうとする人間が、MSを大樹にした
と言ってるんだろ。

age

結局ここは寂れたのか？

>>333
IBMの大樹の陰は、せいぜいMS-DOSまで。
OS/2と決別後は、紛れも無く、　実　力　と思われ。

Macには、メモリ最適化ツールや高速ダウンローダー2000みたいな
すばらしいアプリって存在しないの？

>>337
それはどの程度すばらしいの？

>>336
だから、MSはMS-DOSで大樹になったんだろ。
大樹は、大樹だってだけで依り掛りたい人間が
大勢いるんだよ。何を指して実力なんだ？

>>338
( ゜Д゜）y─┛~~
ttp://page.freett.com/hachikou/

>>340
これはさすがにmacにはないかもしれない。
そういえばxboxのエミュレーターもwinではあるんだよな、うらやましいな。

>>340
すばらしい。

OSXを速くするソフト作ることにしますた。

・・・HSPで作れってことですか？

>>340
被害者には悪いけどﾜﾛﾀﾖ

おいらもハイパーカードでメモリ最適化するか。

>>337
高速ダウンローダー2000！なつかしいなぁ。
プ板で大評判だったねぇ。
当時Winマシンにインストロールしておおいにﾜﾗﾀもんです。

hage

保守

くちおしや。。。

俺は著作権侵害反対派なんだけど、
正式に、しかし、たいした理由説明もなく断られた今は、
Appleのふがいなさに抗議する意味も含めて、
ゲリラ翻訳をしてもいいかなと思うね。