目次

• 「「Wonderful Server Life」　　　第32回　田畑 英和
• 小池邦人の「Carbon API 徒然草」
• SqueakではじめるSmalltalk入門　　第76回　　鷲見 正人
• ニュース・解説　　　　　　　　　　　　　　 木下 誠

目次

• 「Wonderful Server Life」　　　　　　 第31回　　田畑 英和
• 藤本裕之のプログラミング夜話　#105
• 高橋真人の「プログラミング指南」　 第103回
• ニュース・解説　　　　　　　　　　　　　　　 小池 邦人

「Wonderful Server Life」　　第31回　　田畑 英和

　 〜AFP編〜

　前回まででAFPを利用したネットワークホームの設定方法について解説してきました。今回はこれまでのまとめとして、ネットワークホームを使用するさいの挙動について解説いたします。ネットワークホームの処理の過程を理解しておくことにより、問題が発生したときのトラブルシューティングに役立ちます。

□マウントレコードの読み込み
　クライアントコンピュータが起動すると、まずディレクトリサーバを参照して、マウントレコードを読み込みます。ディレクトリサーバを参照するためには、クライアントコンピュータはあらかじめ「ディレクトリアクセス」を使用してディレクトリサーバにバインドしておく必要があります。
　マウントレコードを読み込めばどのファイルサーバのどの領域をマウントすればよいかが決まります。ちなみに、ユーザを管理するOpen Directoryのマスターと、ネットワークホームを管理するファイルサーバを別々のマシンで運用することも可能です。サーバを分けることによって負荷を分散させることができます。

□ユーザのログイン
　ログインウインドウで認証を行うと、あらかじめ「ディレクトリアクセス」で設定しておいたディレクトリドメインの検索順に従い、各ディレクトリ上に該当するユーザが存在するかどうかを確認します。このときユーザの確認は、必ずクライアントコンピュータ上のNetInfoで管理されているローカルディレクトリから行います。ですので同じユーザ名をもったローカルユーザとネットワークユーザが存在していた場合、ローカルディレクトリ上のローカルユーザのほうが優先されます。
　ローカルディレクトリに該当するユーザがいなければ、Open Directoryのマスターなどのネットワーク上のディレクトリドメインに該当するユーザが存在するかどうかを確認します。
　該当するユーザが存在すればユーザ認証が行われ、ユーザ認証に成功するとログイン処理が継続されます。

□ネットワークホームのマウント
　ログイン後は直ちにネットワークホームが使用できる必要がありますので、ログイン時にネットワークホームが自動的にクライアントコンピュータ上にマウントされます。
　ログイン時にまずユーザごとに設定されたホームの情報が読み込まれます。ホームのパスとしてファイルサーバ上のネットワークホームが設定されていれば、自動的にクライアントコンピュータ上にファイルサーバ上のホームがAFPを使ってマウントされます。このときネットワークホームのマウントはログインしたユーザとしてマウントが行われ、自動的に認証が行われます。

□トラブルシューティング
　このようにネットワークホームを使用したときには、様々な情報を読み込み、背後で自動的に処理が行われます。正しく設定が行われていないとネットワークホームが正常に機能しないことがあります。例えば、ログインウインドウで正しいユーザ名とパスワードを入力しても、ネットワークホームが正常に機能していないとログインに失敗することがあります。
　ログインに失敗した場合は、まずは問題点の切り分けを行いましょう。問題があるとすればたいていの場合、ユーザ認証に問題があるか、あるいはネットワークマウントに問題があるかのどちらかです。
　ログインウインドウからログインする場合は、ネットワークホームが機能していないとログインそのものが出来ない場合がありますが、ローカルユーザでログインしてから「Terminal」上でloginコマンドを使えば、ネットワークホームが使えなくてもネットワークユーザの認証は行えます。
　ですので、「Terminal」上で認証できた場合、おそらく問題はネットワークマウントにあるのではないかという推測ができます。ユーザ認証に問題がないことが確認できましたら、例えば手動でAFPのマウントが出来るかなどを確認して、AFPの動作を確認するようにしましょう。また、複数のユーザで動作確認を行えば、問題が特定のユーザに依存する問題なのかどうかを切り分けることができます。
　問題が発生する場合は、たいていどこかに設定ミスがあるはずですので、落ち着いて設定内容を見直しましょう。

つづく

藤本裕之のプログラミング夜話　#105

　承前、年の瀬で忙しいのでさくさく行こう。前回掲載したリストの解説である。まずビューオブジェクトのロードが終わった awakeFromNib でregisterForDraggedTypes: を呼んでいるのは自分がドラッグ用ペーストボードに入れたデータを自分で受け取る必要がある場合のため。今回のサンプルはこれがなくても動くんだが、例えば NSTableView におけるアイテムの順番変更などをドラッグ＆ドロップで実現する場合、自分の入れたデータを自分で受け取ることが必要になる。その場合、ここでレジストしておかないと受け取れない。

次の drawRect: でやってることはドラッグ＆ドロップに直接関係ないので割愛。で、その次、mouseDown: の時点で「今ドラッグしてますフラグ」をオフにして、mouseDragged: のなかでこれがオフの時だけドラッグデータをセットする部分は私の勘違い。……つうかソースの使い回しが原因のミスであります。これについては後述。

で、肝心カナメの mouseDragged: 。まずは「ドラッグされるデータ」として文字列　@”Data to be dragged”　を用意し、次にドラッグ用ペーストボードへのリファレンスを獲得。次にこのペーストボードに対して、declareTypes: owner: を送り、これから入れるデータのタイプを申告する。このメソッドの第2パラメータ、owner: には、ここで申告したタイプのデータをこのボードに入れる責任を負うオブジェクトを……回りくどいな。このサンプルでは NSStringPboardType 1個しかデータのタイプを申告していないし、しかも次のステートメントですぐにそれをセットしているのでここは nil でも構わないんだが、そのデータを用意するオブジェクトがこのビュー自身ぢゃない場合など、ここにそのオブジェクトがどれかを申告しておいて、そいつに対して pasteboard: provideDataForType: メッセージが来るのを待ってセットするということが出来るわけ。……なんだけど、このサンプルでは簡単に文字列　@”Data to be dragged”　をペーストボードにセットしてこの処理はおしまい。

さあ次、これが結構大切、実際に画面上をドラッグされて動くイメージを作らなくちゃならない。ああ、見た目の問題ねと思うかも知れぬが、実はこれを端折ると、いくらマウスボタンを押してドラッグを始め、押したまま他のアプリケーションのウインドウの上までポインタをドラッグして行き、そこでマウスボタンを放してデータをドロップした……つもりになっても何も起きないのだ。うそだと思ったらやってみなさい。まぁサボれるとしてもサボったらユーザの顰蹙を買うことは必至だけどね。
　ではその詳細。ペーストボードに入れた文字列をデフォルトの属性で描けるだけのサイズの NSImage オブジェクトを作り、そこに描画する。ここでは描画もデフォルトの属性のままでやっているが、それっぽくしたければフォントの色をグレイにしたり半透明にしたりすることも可能。なお、サンプルでは属性を持たない NSStringPboardType しか入れてないのでこれでいいが、リッチテキスト（NSRTFPboardType）などをサポートした場合にはこのイメージにもそれなりの見た目のものを用意するべき。
　イメージができ上がったら、NSViewのdragImage: at: offset: event: pasteboard: source: slideBack: メソッドを使ってこれを……なんというのかな、「ドラッグされるイメージ」としてセットする。at: にはイメージを最初に表示する左下の座標をこのビューの座標系でセット。次の offset: はmouseDown: が発生した場所を基準にした現在のmouseの位置……なんだが、Mac OS X 10.4以降では無視されるので気にしない。event: は現在のイベント。ペーストボードも今データをセットしたペーストボード。source: にセットするのはこのドラッグ・オペレーションのコントローラ・オブジェクトで、NSDraggingSource プロトコルに適応している必要がある。具体的には最低限以下のメソッドをインプリメントしておけと……いうんだが、これ無くても別に支障がないみたいなんだけどね。

- (unsigned int)draggingSourceOperationMaskForLocal:(BOOL)isLocal;

とにかく、普通はビュー自身、場合によってはビューを含むウインドウをセットする。上のメソッドが何を返すべきかは NSDraggingSource プロトコルのドキュメントを参照のこと。最後の slideBack: はこのデータのドロップが拒否されたとき、つまり NSStringPboardType のデータを受け取らないオブジェクトの上でドロップされた場合にこのビューまで跳ね返されるアニメーションを行うかどうかのフラグである。
　で、さっきの「後述」部分、このメソッドを呼ぶと、これはドラッグが終わる（どっかでmouseボタンがリリースされる）まで戻ってこないので、ドラッグペーストボードにデータが入ったままこのmouseDragged:が重複して呼ばれることはない。なので、前回リストのフラグのことは忘れてくだされ。

はぁはぁ、駆け足したがなんとか年内にここまでこぎつけたぞ。来年1月からは NSTableView に話題を絞って上にも出てきたアイテムの順番変更などのやり方を説明する予定。それではみなさま、よいお年を。
（2006_12_14）

高橋真人の「プログラミング指南」第103回

プログラマのためのオブジェクト指向再入門(11)

〜カプセル化について(2)〜

　こんにちは、高橋真人です。
　さて今回は、前回お話ししたMLTEの例でカプセル化ということについてのお話をしたいと思います。
　MLTEはかなり大きな機能のセットです。そのため、「お任せ」で使う分にはかなりラクができます。つまり、使う側は余り多くのコードを書かなくてもいろいろな機能を実現できるのです。しかし、MLTEが標準で提供しているものと違ったことをしようとすると複雑な手間を強いられることがあります。
　PowerPlantでは、多くのクラスがMac OSが提供している機能を包んだ（ラップした）形で設計されています。たとえば、LWindowというクラスは、WindowRecordという構造体をラップする形でクラスが構成されています。こうすることで、フレームワーク利用者は、WindowRecord（もしくはWindowRef）を直接扱うよりも、少ない手順でウインドウを操作することができるようになるわけです。
　さらにLWindowが提供する機能では足らない場合には、オブジェクト指向の仕組みを利用してサブクラス化することで、利用者独自の機能を追加することができます。
　ところでMLTEをラップしたLMLTEPaneは、とても簡単に使うことができます。これは、最初に言った「MLTEはラクができます」というのとはラクさの度合いが違います。
　PowerPlantが標準で用意するConstructorというGUI編集ツールを使って、部品パレットからウインドウ上にLMLTEPaneを持ってきて配置するだけで主な作業は完了。あとはコードの方にRegisterClass_(LMLTEPane);という1行を加えるだけで、表示したWindow上にちゃんとMLTEが生成されます。MLTEが備えるオプションを利用したい場合にもConstructorの設定パレットでいくつかのチェックボックスを選択する程度の手間しかかかりません。
　「MLTEはラクができます」と言っても、普通にCでMLTEを使う場合には、書かなければならないコードがそれなりにあるので、それに比べても相当に「ラクができる」と言えるでしょう。
　ところで、MLTEをカスタマイズする必要が出てきた場合、どうすればよいのでしょうか？
　Cによるアプローチの場合、MLTEの仕組みが提供する機能を適宜利用して、自分のカスタマイズの用途に合わせたコードを書いていきます。
　では、オブジェクト指向の場合はどうでしょうか？
　先ほども言いましたように、PowerPlantでは、MLTEをラップした形でLMLTEPaneというクラスが構成されています。しかし、この「ラップした仕組み」がカスタマイズの邪魔をすることがあるのです。
　今回私が取り組んだプログラムの場合、複数の写真を切り替えながらキャプションを編集する仕組みになっています。このキャプションを表示・編集する部分にMLTEを使用しているわけなのですが、ここで問題が出てきました。
　ユーザーが写真を切り替えた場合、新たに選択された写真のキャプションがMLTEの中に表示されるわけですが、内部的にはそれまで表示されていたテキストにさしかえて新しいキャプションをセットすることになります。
　すると、ユーザーが編集メニューから取り消しを選んだ場合、キャプションフィールドは以前に選択されていた写真のキャプションを表示してしまうのです。これは、MLTEが無限回数のアンドゥをサポートしているために発生する現象ですが、ユーザーからすればこの動作はちょっと不自然です。（選択されている写真も前のものに切り替わるならばまだしも）
　そんな時にどのように対処すべきか、アプローチはいくつか考えられるでしょうが、私は、写真が選択し直される場合にMLTE自体を一度消去し再度作り直すという方法を取ることにしました。（このやり方自体の是非はここでは議論しません）
　ところがMLTEというのは少しクセのあるコントロール（ボタンやフィールドなどのパーツのこと）で、生成時にしか指定のできないオプションがある上、これらのオプション値は既に生成されているMLTE自体から読み取ることができないのです。
　私の取った「新規に作り直す」というアプローチのためには、それらのオプション値をどこかから得なければなりません。MLTEのコントロールから取れないとなれば、再度リソースデータから読み出してくる必要があります。
　ところが、Constructorというツールによって作られているPowerPlantのWindowは、Windowの上に配置されているコントロールがWindow自身と共に一つの固まりとなってリソースに格納されています。
　新規にWindowを生成する場合には、そのリソースの固まりを頭から順番に読んでいき、コントロールを一つずつ生成していくようになっています（もちろん、これらは「Windowを生成する」という作業の裏側でPowerPlantが勝手にやることです）が、Window上の任意のパーツを特定して読み出すとなると話はそんなに簡単ではありません。
　パーツの数が少なければ、とりあえず全部のデータを読み出して、必要ないものは捨ててしまうというアプローチもあったのでしょうが、今回のケースではWindow上のパーツがかなりの数に上ったので、その方法は取りませんでした。
　そうなると、最初にLMLTEPaneのオブジェクトが生成される際に、リソースから読み込んできた各種設定値をどこかに保存しておけばよいということになるわけですが、あいにくLMLTEPaneはこのような機能は持っていません。
　サブクラス側から、このLMLTEPaneの初期化動作を横取りできればよいのですが、残念ながら初期化のための関数はprivate指定です（サブクラスからもアクセスができない指定。もう少しあとの回で説明します）。
　仕方ないので、サブクラスの生成関数の中で、途中まで読み出されたWindowのリソースのデータをLMLTEPaneが読み出した分だけ巻き戻して、再度読み込み直す、という回りくどいアプローチをすることで、結局実現に至ったのでした。

少し話が複雑すぎたかもしれません。PowerPlantの経験者でもないと、ちょっと理解するのは難しかったかな？
　どういうことが言いたかったのかは、次回でまとめて説明します。

ニュース・解説

　今週の解説担当:小池邦人

● Carbon ドキュメント & サンプル ＆ SDK ナビゲーション（2006/12/15）

【開発環境】

アップル社から「Leopard Tech Talk」開催の案内が届きました。アップルのエンジニアやエキスパートからリリース間近のMac OS X Leopardについての最新情報と技術知識を得られる機会だそうです。大阪で1回、東京では4回開催されるのですが、登録手続きにもたついていたら、最後の開催日（2/15）しか空いていない状況になっていました。すごい人気ですね（笑）。具体的なセッションの内容は「Mac OS X “Leopard” テクノロジー概要」「グラッフィックス概要」「新しいCocoaとObjective-C 2.0の概要」「Toolsの概要」などだそうです。

http://developer.apple.com/jp/events/techtalks/japan.html

多分、サンフランシスコExpoの基調講演ではLeopardの新機能（WWDCでは未紹介）がデモされるでしょうから、この場においても、WWDCで入手した情報よりも「さらに新鮮な情報」が入手できると嬉しいですね。期待いたしましょう！

【テクニカルドキュメント】

前回から12月15日の期間中、Apple社のGuidesとReferenceサイトには幾つかのドキュメントが登録されました。しかし、そのほとんどがマイナーチェンジの改訂です。Guidesサイトに登録された以下の2つのドキュメントだけが、内容の大幅な更新がなされています。また、デベロッパ向け読み物がひとつだけ登録されています。こちらについては、前号の木下さんの記事も参考にしてください。

「Quartz Composer Web Kit Plug-in JavaScript Reference」（PDFあり）
「Quartz Composer Programming Guide」（PDFあり）

http://developer.apple.com/documentation/index-rev-date.html

「Leopard Application Technologies Overview」（読み物）
http://developer.apple.com/leopard/overview/apptech.html

前回から12月15日の期間中、新規テクニカルノートと新規テクニカルQ&Aがひとつずつ登録されました。両方ともAudio関連です（最近多い）。

TN2113「Using AudioDeviceRead in Mac OS 10.4」

http://developer.apple.com/technicalnotes/index-rev-date.html

QA1437「Standard Audio – Parsing the kQTSCAudioPropertyID_
CodecSpecificSettingsArray property」（初版）

http://developer.apple.com/technicalqas/index-rev-date.html

【サンプルソースコード】

前回から12月15日の期間中、Apple社のSample Codeサイトには、サンプルソースコードがひとつも登録されませんでした。全体的にクリスマス休暇の影響で情報の更新が少ないです（嵐の前の静けさか？）。

http://developer.apple.com/samplecode/index-rev-date.html

【デベロップメント SDK】

前回から12月15日の期間中、Apple社のSDKサイトには新しいSDKがひとつも登録されませんでした。

http://developer.apple.com/sdk/

　◇MOSAからのお知らせと編集後記は割愛します◇

目次

• 「Wonderful Server Life」　　　　　　第29回　　田畑 英和
• 藤本裕之のプログラミング夜話　#104
• 高橋真人の「プログラミング指南」　 第102回
• ニュース・解説　　　　　　　　　　　　　　　 小池 邦人

「Wonderful Server Life」　　第29回　　田畑 英和

　 〜AFP編〜

　前回新しいXserveの紹介をしましたがまずはその補足から。新型のXserveはLOM（Lights-out Management）と呼ばれる機能を搭載しています。この機能を使えばリモートからXserveの電源を入れるなどのリモート制御ができます。実際にこの機能を利用するにはLOMに対応したソフトウェアが必要になりますが、つい最近アップデートされたApple Remote Desktop v3.1はさっそくこのLOMをサポートしています。

さて、話を元に戻してネットホームの設定方法を解説しましょう。これまでAFPサービスや共有ポイントの設定方法を解説してきました。これでAFPを使ってクライアントコンピュータからサーバ上の共有ポイントにアクセスし、ホームをクライアント上ではなくサーバ上にもつことができるようになりました。
　ですが、ネットワークホームを利用するにはさらにネットワークマウントの設定も行う必要があります。ネットワークホームを使う場合、ユーザのログイン後ただちにホームが使える必要があります。ですのでいちいちログインしてからサーバ上のホームを手動でマウントするといったことはできません。そこで自動的にサーバ上の共有ポイントをマウントする必要があるわけですが、これがネットワークマウントになります。

◇ネットワークマウントの設定
　ネットワークマウントの設定は「ワークグループマネージャ」を使用します。ツールバーから「共有」をクリックし、まずは画面左側に表示される共有ポイントのリストからネットワークマウントを設定したいフォルダを選択します。ネットワークホームの設定を行うには共有ポイントのリストから「Users」を選択します。つまりサーバ上の「/Users(/ユーザ)」をネットワークマウントするように設定します。
　次に右上の「ネットワークマウント」ボタンをクリックします。ネットワークマウントの設定を行うにはディレクトリの管理者として認証を行う必要があります。これはマウントレコード（ネットワークマウントの設定情報）をディレクトリサービスで管理するためです。つまり設定したマウントレコードは共有ディレクトリ(LDAP)の中に書き込まれます。共有ディレクトリに対して書き込みを行うので、ディレクトリの管理者としてまずは認証を行う必要があるわけです。
　認証を行うには「場所」ポップアップメニューの右側のカギをクリックします。「場所」のポップアップメニューですが、ここでマウントレコードを書き込む場所を選択します。OpenDirectoryとAFPサービスを同一のサーバ上で運用する場合はデフォルトの「LDAPv3/127.0.0.1」のままでかまいません。
　負荷分散のためにOpenDirectoryとAFPサービスを別々のサーバで運用する場合は、まずAFPサービスを稼働させるサーバをOpenDirectoryサーバに「ディレクトリアクセス」を使ってバインドしておきます。こうすればAFPサーバ上で「ワークグループマネージャ」を使ってネットワークマウントの設定を行うときに「場所」ポップアップメニューにOpenDirectoryのサーバがリストアップされ、マウントレコードの保存場所として選択することができます。

適切な場所を選択したら次に「この共有ポイントのネットワークマウントを使用する」のチェックを入れます。ネットワークマウントのプロトコルを選択できますが、今回はMac同士でファイル共有を行いますので「AFP」を指定しておきます。
　「用途」は「ユーザのホームディレクトリ」を選択します。用途の選択でクライアント上のどこに共有ポイントがマウントされるかが決まります。
　以上でネットワークホームのためのネットワークマウントの設定が完了しました。最後に画面右下の「保存」ボタンをクリックするとOpenDirectory上にマウントレコードが書き込まれます。

・ネットワークマウントの設定
http://homepage.mac.com/htabata/MXS10.3/img/WGM_Sharing/WGM_Mount_03.png

　ディレクトリサービスを使ってサーバにアクセスするように設定済みのクライアントは、サーバ上（OpenDirectory上）に書き込まれたマウントレコードを読み取って自動的に共有ポイントをマウントします。
　以上がネットワークマウントの設定方法です。それでは、次回は各ユーザごとのホームの設定とホームディレクトリの作成について解説します。

つづく

藤本裕之のプログラミング夜話　#104

　前回まではもっぱら受け身、データをドラッグ＆ドロップされる側のやり方を解説してきたわけだが、普通にアプリケーションを開発していればもちろん逆の送り側、すなわちドラッグの出発点になりたい局面も生じるわけ。世の中はやはりギブ＆テイクなんであって、財布を落とす不幸なひとがいるからそれを拾う幸運なひとが生じるのである。……もちろん世の中にはちょっとエレベータのボタン押すだけで15,000円も稼いぢゃう広告代理店のヒトとかそういうのもいるわけなので、イマイチ例えが説得力を欠くような気がしないでもないが、まぁ俗世間はどうか知らぬがプログラムはそうありたいもんですな、と。

あるビューが自分自身や他のビュー、はたまた他のアプリケーションに対して提供しうるデータを持っていて、その受け渡しをドラッグ＆ドロップで可能にしたいとする。既に我々はこうしたデータを受け取る術を知っているので、送り出し側がやるべきシゴトも容易に想像がつくはずだ。すなわち、ドラッグが始まったらデータをドラッグ用のペーストボードにセットしてやればいい、のである。以下にビュー上でドラッグが始まったらやみくもに「Data to be dragged」という文字列を送り出すという全く実用性のないサンプルを示す。

@implemantation MyView

- (void) awakeFromNib {  /* わしは文字列をドラッグするよ、と宣言 */
     [self registerForDraggedTypes:
           [NSArray arrayWithObject:NSStringPboardType]];
}

- (void)mouseDown:(NSEvent*)theEvent {
     _dragging = NO;          /* これはインスタンス変数 */
}

- (void)mouseDragged:(NSEvent*)theEvent {
     if(_dragging == NO){     /* まだドラッグしてなければ...     */
          NSString*      toBeDragged = @"Data to be dragged";
          NSPasteboard*  pb =
               [NSPasteboard pasteboardWithName:NSDragPboard];
          [pb declareTypes:
               [NSArray arrayWithObject: NSStringPboardType] owner:self];
          [pb setString:toBeDragged forType:NSStringPboardType];

          NSImage*  anImage =
                [[[NSImage alloc] initWithSize:
                    [toBeDragged sizeWithAttributes:
                    [NSDictionary dictionary]]] autorelease];
          [anImage lockFocus];
          [toBeDragged drawAtPoint:NSMakePoint(0,0)
                         withAttributes:[NSDictionary dictionary]];
          [anImage unlockFocus];        /* ドラッグするイメージを作成 */

          [self dragImage:anImage
               at:[self convertPoint:
                    [theEvent locationInWindow] fromView:nil]
               offset:NSMakeSize(0,0)   /* Tiger以降は無視する */
               event:theEvent
               pasteboard:pb
               source:self
               slideBack:YES];     /* そのイメージをセットする */

          _dragging = YES;    /* ただいまドラッグ中 */
     }
}

/* この他、- (id)initWithFrame:frameRect: とか - (void)drawRect:とか
必要なメソッドはちゃんと定義されてあるものとする */
@end

　これしきのこと、と思えば大層なコードに見えるがクラシックシステムのときのドラッグ＆ドロップのインプリメントを考えれば「ホントにこんだけでいいの？」というくらい簡単になったんである。それでは最初から解説を……と思ったが、もう所定の行数ではないか。中途半端になるのも困るので解説は次回。上のリストの再録はしないので（してたら毎回ほんの少ししか進めない）、その気のあるひとは取っておくこと。
（2006_12_01）

高橋真人の「プログラミング指南」第102回

プログラマのためのオブジェクト指向再入門(10)

〜カプセル化について(1)〜

　こんにちは、高橋真人です。
　今までクラスという仕組みを使って、「機能を持ったデータの固まり」としてのオブジェクトの片鱗を見てきました。しかし、そもそもプログラムというのは詰まるところコードの固まりであって、「それがオブジェクトというまとまりを持ったからといって、何が面白いんだ？」という疑問を持たれる方もいらっしゃることと思います。
　連載の96回では、オブジェクトを利用するメリットの一つとして「処理の詳細を隠してしまえる」というお話を少ししました。今回は、この話をもう少し広げていきたいと思います。

最近、私が仕事で取り組んでいるものの一つにMLTEがあります。MLTEは、2000年にTextEditの制約を打ち砕く新しい技術として登場した仕組みです。TextEditには32kの壁などという有名なものから始まり、テキスト編集の仕組みとして登場してから随分経ったため、時代遅れになった部分が数多くあり、足りない部分はすべてプログラマが一つ一つ組み込んで行かなければならなかったのです。
　そんなTextEditの置き換えとして登場したMLTEの機能についてかいつまんで紹介しますと、日本語のインライン入力、テキストのドラッグアンドドロップ、複数の書体・サイズ・カラーの混在した表示などを最初からサポートし、テキスト編集はもちろんのこと、無限回数のアンドゥやリドゥなども標準で備えているのです。

私が仕事で作っているアプリケーションの一つに、ずっとPowerPlant(*注)で作ってきたものがあります。最初のリリースは2000年で、Mac OS 9用のアプリでした。
　ユーザーの環境が徐々にOS Xに移行してきたのに合わせ、Carbon化を行い、細々とした機能追加要求などを受けてメンテナンスを続けていますが、この度少し大きなユーザーからの要求があったため、Cocoaによる作り直しも含めいろいろな対策を検討しました。
　結果として作り直しは見送ったものの、OS Xでしか使われない今となっては意味がなかったり無駄だったりする部分も少なくないため、内部設計の一部変更も含めていろいろと手を入れていたのです。
　そのアプリにはテキスト編集エリアがあって、ここはこのアプリのUIの中では中心になる部分なので、それなりにしっかりと作り込む必要があります。もともとはPowerPlantのLTextEditViewというクラスに若干の拡張を加えて実現していました。しかし、PowerPlant自体が日本語編集で抱える問題点や、私自身の拡張のやり方のまずさなどから、ちょっとしたバグも抱えていたため、この際思い切ってこれをLMLTEPaneという、PowerPlantがMLTEを使うために用意したクラスを利用することとしたのです。
　LMLTEPaneは、PowerPlantの末期に加えられたクラスです。その後間もなくPowerPlant自体のバージョンアップが止まってしまったためPowerPlantによって加えられた機能はごくわずかですが、MLTE自体が持つ高機能な仕組みはそのまま利用することができるので、開発の手間はある程度削減できると踏んだのです。
　しかし、問題がなかったわけでもありません。LTextEditViewから作った私のクラスでは、保持するテキストの長さを表示する仕組みがありました。ユーザーが文字編集するのを受けてリアルタイムで文字数を表示します。
　リアルタイムな文字数表示という場合、日本語では変換中の文字数も拾う必要があります。ユーザーによっては、一度に大量の文字を入力したままで変換作業を行う場合もあるからです。
　また、ユーザーからの追加要求として、このテキストフィールドでは改行を含むいくつかの文字が入力できないようにする必要がありました。
　これらの機能は残念ながらMLTEを「そのまま」使っているだけでは実現ができないのです。

文字数表示に関しては、いろいろ調べて解決できました。InputMethodは、処理の途中でいくつかのCarbonイベントを発行します。よって、アプリケーションでこれらのイベントを捕まえることによって、InputMethodがまだアプリケーションに渡していない（現在変換処理中の）文字列の情報を得ることができるのです。
　しかし、もう一つの問題は難物です（「難物でした」と過去形になっていないのは、今現在でも完全解決に至っていないからです・涙）。InputMethodを介して渡ってくる文字列や、ペーストによって渡されてくる文字列に関しては、同様にCarbonイベントなどによって捕まえることができます。ところが、MLTEが提供しているドラッグアンドドロップの仕組みによって渡ってくるテキストの場合、イベントを通して捕まえることができないのです。
　さんざん調べた挙げ句に見つけた答えは、以下のようなものです。

・MLTEが用意しているドラッグアンドドロップのハンドラ（処理関数）をオフにする
・MLTEに代わって、自分でドラッグアンドドロップのハンドラを実装する

　この技術を勉強したことのある人はご存知でしょうが、ドラッグアンドドロップを実装するには、二種類の処理をしなければなりません。
　一つはモノをつかんでドラッグを始める処理。グラフィックアプリケーションであれば図形を、Finderであればアイコンを、テキスト編集ソフトであれば選択したテキスト範囲をユーザーがマウスでつかんで動かし始める時に、「ドラッグオブジェクト」を作成し、ドラッグの動作を起動する処理です。
　もう一つは、ユーザーがドラッグによって引っ張ってきたドラッグオブジェクトに反応し、マウスボタンが放されたらそれを受け入れる（または拒否する）処理。
　厳密に言えば、後者もさらに二つの処理に分けられるのですが、まあそれはよしとしましょう。
　しかし、MLTEに対して「ドラッグアンドドロップのハンドラはこっちでやるからね」と伝えるためのフラグを立てると、何故かこの二つの処理を両方ともやめてしまうのです。
　私としては、単にドラッグされてきたデータを受け入れた時にだけ（つまり拒否した場合にはいちいち知らせてくれなくていい）、それを教えてくれさえすれば充分なのに、ドラッグ関係の処理を一斉に放棄してしまうって、一体どういうことなんでしょ？
　この事実を知った時に私はショックの余り、しばらくは何も手に付きませんでした（笑）が、嘆いていても事態は何も動きませんから、ちまちまと必要な処理を組み込んで行きました。
　しかーし、Tiger上では問題なく動く処理が何故かPanther上では怪しい動作になるというバグのせいで、いまだにその回避策をめぐって右往左往を余儀なくさせられている私なのであります。（悲しいかな、未だユーザー環境も開発環境もPantherがメインであります）
　ちょっと、個人的な感情が絡んでしまったために、少し脱線してしまいました（笑）が、現実にアプリケーションを作っている人の悶々とした日常の一シーンが少しは伝わりましたでしょうか？

　「カプセル化の話をする」と言っておいて、単なる仕事の愚痴を連ねたにすぎないと思われた方も多いかもしれませんが、心配はご無用。ちゃんとこの話を元にカプセル化ということについての考察を進めてまいります。
　ただ、行数が多くなりましたので、この続きは次回に。

注：PowerPlantは、Metrowerks社のCodeWarriorの一部として提供されていたC++言語によるアプリケーションフレームワークです。Mac OS 9の時代には多くの商用アプリケーションで利用され、Carbon対応もなされたために、Mac OS Xになってからもしばらくは使われていましたが、もともとの設計がCarbonイベントモデルではない古いイベントモデルに合わせてあったため、Mac OS X用に全面的に書き換えた新しいフレームワークであるPowerPlant Xとしてさらに発展するはずでした。
　しかし、2005年のAppleのインテルプラットホームへの移行により、MetrowerksとCodeWarriorが終焉を迎えてしまったため、実質的に入手することはできなくなってしまいました。
　ただ、今年の頭にPowerPlantとPowerPlant Xはオープンソースになったため、CodeWarriorのIDE（これは、もはや入手不可能）なしでも使うことができるようになる日が来るかもしれません。もっとも、最初からMach-OであるPowerPlant Xはまだしも、PowerPlant自体をXcode対応にさせるのは、そうそう簡単なことではないような気がしますが。

ニュース・解説

　今週の解説担当:小池邦人

● Carbon ドキュメント & サンプル ＆ SDK ナビゲーション（2006/12/01）

【開発環境】

使い始めてかなり時間が経つと言うのに、Xcodeのテキストエディタでソースコードを編集していると、今でも大変ストレスがたまります（涙）。テキストファイルのオープンが遅いとか、Framework APIの文字色が変えられないなどの機能的な不備も多いのですが、バグなのか仕様なのか、とにかくソースコードを編集しているとイライラする事に数多く出くわします。

複数ファイルの検索と置換がうまくいかないケースが多々あります。検索位置がズレルのです。ソース内に日本語コメントを入れているからという噂もありますが、1ファイル内の検索と置換では問題が出ません。また、失敗したファイルを一度ファイル保存してやるとケロッと直るので、バグのような気もします？

数値をダブルクリックすると、カンマを挟んだ隣の数値まで選択してしまいます。これは、カンマを金額の3桁区切りと判断しているのが原因だと聞いたのですが、ソースコードエディタにそんな機能必要ないですよね（笑）。引数や配列の羅列でカンマの左右にスペースを入れない作法の私としては、まことに情け無い仕様です。

ソースコードの一部をカットする場合、行のセレクションの仕方により、前行のCR（キャリジリーターン）までカットしてしまう場合があります。これも、ソースコードの編集では余計なお世話です。複数行をマウスで選択してカットする場合には、前行のCRが消えてしまうと、後方の行が連続して表示されてしまい（インデントが消える）再度CRを入れなくてはいけなくなります。また、カット部分の先頭にCRが入っていると、ペースト後にも余分な編集が必要となります。

まだまだ色々とあるのですが…Metrowerks CodeWarriorのテキストエディタを利用している時は、こんなにもストレスは溜まりませんでした。Apple社の技術者は平気で使っているのかな？　それとも、さっさとエディタ部を差し替えているのかな？　Xcode 3.0ではいくらかマシになっているのを祈りましょう。もしくは、上記問題の解決方法をご存じの方は、ぜひお教えくださいませ（エディタを代えるという手段以外で…）。

【テクニカルドキュメント】

前回から12月1日の期間中、Apple社のGuidesサイトとReferenceのサイトには新規登録はありませんでした。そのかわり、デベロッパ向けの読み物がひとつ登録されています。CoreGraphicsに含まれるImageIO Frameworkの各ルーチンとそのサンプルソースコードが解説されています。今まで色々な画像ファイルフォーマット（JPEGやTIFFなど）をオープンする場合には、QuickTimeのImageCompression関連のルーチンを利用していたのですが、ImageIOルーチンを利用すると各社デジタルカメラのRAW画像フォーマットもオープンできるようです。ドキュメントには、Mac OS X 10.4.8でオープン可能な画像ファイルフォーマットの一覧も掲載されています。ただし、どの画像フォーマットが読み込めるかについては、Mac OS Xのバージョンに随分と依存するようなので注意が必要かもしれません。それにしても、テクニカルノートとして登録されても良さそうな内容ですね。

「Using the ImageIO Framework with Mac OS X 10.4 Tiger」（読み物）

http://developer.apple.com/graphicsimaging/workingwithimageio.html

前回から12月1日の期間中、新規テクニカルノートはひとつも登録されませんでしたが、新規テクニカルQ&Aの方は6つ登録されました。テクニカルQ&Aについては、前号で木下さんが解説されていますので、そちらも参照してみてください。

QA1496「Configuring the Recent Searches menu for NSSearchField」（初版）
QA1497「FSDeleteObject fails with fBsyErr, sometimes」（初版）
QA1500「Debugging a Web Kit Plug-in in Xcode」（初版）
QA1387「Integrating With The Connect to Server Dialog」（初版）
QA1499「Security Framework Error Codes」（初版）
QA1390「Standard Audio – The CodecSpecificSettings- Array and MagicCookie properties」（初版）

http://developer.apple.com/technicalqas/index-rev-date.html

【サンプルソースコード】

前回から12月1日の期間中、Apple社のSample Codeサイトには、サンプルソースコードが3つ登録されました。

「SetMouseAcclSample」（HID&Cocoa関連）（初版）
「MovieAssembler」（FinalCutPro関連）（初版）
「tcplognke」（Network関連）

http://developer.apple.com/samplecode/index-rev-date.html

【デベロップメント SDK】

前回から12月1日の期間中、Apple社のSDKサイトには新しいSDKがひとつも登録されませんでした。

http://developer.apple.com/sdk/

◇MOSAからのお知らせと編集後記は割愛します◇