MOSA Multi-OS Software Artists

MOSAはソフトウェア開発者を支援します

  • iPhone/iPod touch アプリ紹介
  • MOSA掲示板
  • 活動履歴
  • About MOSA(English)

MOSA Developer News［MOSADeN＝モサ伝］第226号

2006-10-31
　

目次

  • 湘南ミーティングにはじめて参加して　　　　 冨田 真理子
  • 「「Wonderful Server Life」　　　第24回　　田畑 英和
  • 小池邦人の「Carbon API 徒然草」
  • SqueakではじめるSmalltalk入門　　第72回　　鷲見 正人
  • ニュース・解説　　　　　　　　　　　　　　 木下 誠

湘南ミーティングにはじめて参加して　 ヤノ電器(株)開発部　冨田 真理子

　今回、MOSA湘南ミーティング初参加者代表として感想記事を書かせて頂くことになりました、Mac歴約半年の冨田です。

私のMacとの付き合いは、今年の5月にヤノ電器(株)に入社したと同時に始まりました。
　また、社長がMOSAの会長をされておられるとのことで、今回のMOSA湘南ミーティングに参加させて頂くことになりました。
　裏を返せば「ヤノに入らなければMacとは縁はなく、社長が会長でなければ湘南ミーティングには参加しなかった」私なのですが、このような感想記事をメールマガジンに掲載して頂く機会を頂き、大変光栄に思っております。

最近は、「FreeBSD系」「Boot Camp」というキーワードに惹かれ、UNIXやLinuxユーザーの方が多くMacの世界に入って来られていると聞いています。（私も以前はSIer会社で主にUNIX系／Linux系の仕事を担当していたので、OS Xは親しみやすかったです）私のように最近のMac（OS X）を触りだした人で「Macで仕事をしている人ってどんな人？」「昔のMacってどんなものだったの？」という興味をお持ちの方は、今回のようなミーティングは肌で感じる良い機会になると思います。「Mac大好き！」で「WWDCに参加するのは当たり前」という、熱意溢れる方々が多く参加されていらっしゃるので、「Mac」の今昔の片鱗を知ることができました。

今回は5個のセッションに参加しましたが、どのセッションも講師の方のレベルが高く、Macの知識を少し深めることができたと思います。個人的には、特に「インテル・ソフトウェア開発製品の紹介」のセッションが印象に残っています。

また、ミッドナイトセッションは睡魔に負けて参加できませんでしたが、明け方近くまで語り明かしたという方もおられたとのことで、「貴重な機会を逃したかな、、、」と少し残念に感じています。

ミーティングには何年も前から参加されている方や、既に顔見知り同士の方々も多く、「1人で初参加」だと疎外感みたいなものを感じる場面があるかもしれません。
　しかし、自分から積極的に働きかける心意気があれば、「Mac大好き！」なメンバの仲間に入ることが出来ると思います。また、フリーの方やご自分で会社の代表をなさっておられる方が多く参加されているので、自分の気持ち次第で「情報交換」「人脈を広げる」という場としても活用出来ると思います。

少しでもMOSA湘南ミーティングに興味をお持ちの方は、来年は勇気を出して是非参加なさって下さい。

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

　 〜Open Directory編〜

　前回はOpen Directory上にネットワークユーザを登録する方法について解説しました。今回はクライアントコンピュータからネットワークユーザを利用する方法について解説します。

◇「ディレクトリアクセス」
　各クライアントコンピュータからネットワークユーザを利用するには、まずどのディレクトリサーバを使用するのかを各クライアントコンピュータごとに設定します。
　設定を行うには「/アプリケーション/ユーティリティ」にインストールされています「ディレクトリアクセス」を使用します。このツールで設定を行うには管理者権限が必要になりますので、ツールを起動したときにロックがかかっている場合には画面左下のアイコンをクリックして管理者として認証を行います。
　「ディレクトリアクセス」はOpen Directoryのクライアントとしての設定を行うためのツールですが、そもそもOpen Directoryは様々なディレクトリサービスに対応できる仕組みになっています。そのため各ディレクトリサービスを利用するためのプラグインが用意されており、「ディレクトリアクセス」ではプラグインごとに設定を行います。主なプラグインには以下のものがあります。

・LDAPv3
　ディレクトリサービスの標準的なプロトコルであるLDAPを使用するためのプラグイン。

・NetInfo
　NetInfoとはNeXT時代から存在するディレクトリサービスですが、現在ではローカルディレクトリの管理に使用されています。

・Active Directory
　Windowsのディレクトリサービスである「Active Directory」を使用するためのプラグイン。Active DirectoryもLDAP対応ではあるが、より簡単に設定ができるよう「Active Directory」専用のプラグインが用意されています。

・BSDフラットファイルおよびNIS
　テキストファイルでアカウント情報などを管理したり、Sunのディレクトリサービス「NIS」を使用するためのプラグイン。

Open DirectoryのマスターはLDAPを使ってディレクトリ情報を共有しますので、「LDAPv3」プラグインの設定を行うことになります。

・「ディレクトリアクセス」
http://homepage.mac.com/htabata/MXS10.3/img/DA/DA_01.png

◇「LDAPv3」の設定
　各プラグインは個別にOn/Offできますので、まずは「LDAPv3」の「使用可能」がチェックされているかを確認し、チェックされていなければチェックを入れて画面右下の「適用」ボタンをクリックします。
　次に「LDAPv3」を選択してダブルクリックするか、「設定」ボタンをクリックして接続先のサーバを設定します。

・「LDAPv3」の設定
http://homepage.mac.com/htabata/MXS10.3/img/DA/DA_02.png

　接続先のサーバを設定するには「新規」ボタンをクリックし、以下の手順で設定を行います。

(1)アドレスの指定
　「サーバ名またはIPアドレス」に接続先のサーバのアドレスを入力します。「SSLを使って暗号化」は、サーバ側でSSLの設定をしていなければ（サーバ側もクライアント側もデフォルトでSSLはOff）Offのままでかまいません。「認証に使用」「コンタクトに使用」はとりあえずデフォルトのOnのままでよいでしょう。「認証に使用」をOffにした場合にはネットワークユーザを使ってクライアントコンピュータにログインできません。
　サーバのアドレスを入力したら右下の「続ける」ボタンをクリックします。

http://homepage.mac.com/htabata/MXS10.3/img/DA/DA_03.png

(2)ディレクトリバインド
　次にディレクトリサーバへの接続のために認証を行う画面が表示されますが、サーバ側で明示的に認証の設定をしていなければ、Open Directoryのマスターに接続（バインドといいます）するさいに認証の必要はありません。ですので、デフォルトのままで「続ける」ボタンをクリックします。

http://homepage.mac.com/htabata/MXS10.3/img/DA/DA_04.png

(3)バインドの完了
　画面の下のほうに「新規サーバの設定が完了しました」と表示されれば、バインドに成功したということです。「OK」ボタンをクリックするとバインドしたサーバがリストに追加されていることが確認できます。
　うまくバインドができなければ手順(1)で入力したアドレスに間違いがないかを確認してみましょう。

http://homepage.mac.com/htabata/MXS10.3/img/DA/DA_05.png
http://homepage.mac.com/htabata/MXS10.3/img/DA/DA_06.png

　以上の設定でクライアントコンピュータをディレクトリサーバにバインドすることができます。1台のクライアントコンピュータを複数台のディレクトリサーバに接続することもできますが、その場合は手順(1)〜(3)の設定を繰り返します。

◇認証とコンタクト
　手順(2)の設定項目「認証に使用」と「コンタクトに使用」ですが、それぞれ「ディレクトリアクセス」の「認証」と「コンタクト」設定画面に反映されます。

・「認証」設定画面
http://homepage.mac.com/htabata/MXS10.3/img/DA/DA_07.png
・「コンタクト」設定画面
http://homepage.mac.com/htabata/MXS10.3/img/DA/DA_08.png

　まず「認証」ですが、この画面の「ディレクトリドメイン」のリストに表示されているサーバが認証に使用できるディレクトリサーバです。つまりここのリストに表示されていないサーバ上のネットワークユーザではクライアントコンピュータにログインできないということです。もしここに目的のディレクトリサーバが追加されていなければ「追加」ボタンからバインド済みのサーバを追加することができます。
　さきほどの手順(2)で「認証に使用」をチェックしておけば、サーバが自動的にリストに追加されます。リストの先頭にあるのはクライアントコンピュータ上のNetInfoです。
　クライアント上での認証はこのリスト順に行われますので、まずはローカルのNetInfoでの認証を試み、失敗した場合には2番目以降のディレクトリに認証をかけます。「認証」のリストにはバインド済みのサーバを複数追加でき、この場合2番目のディレクトリで認証に失敗した場合、3番目、4番目と1つずつ認証を繰り返すことになります。リストの先頭にあるNetInfoは変更することはできません。

最後に「コンタクト」ですが、Mac OS Xには「アドレスブック」などディレクトリサービスに対応したアプリケーションがあります。「コンタクト」の「ディレクトリドメイン」リストにサーバを追加しておけば「アドレスブック」からディレクトリサーバ上のユーザ情報にアクセスできるようになります。

以上でクライアント上での設定ができたことになりますが、次回は設定の確認方法について解説する予定です。また、実際にネットワークユーザをクライアント上で使用するにはホームの設定が必要になってきますが、こちらについてもこれから解説していきます。

つづく

小池邦人のCarbon API 徒然草（2006/10/27）

〜　Carbonモダンアプリケーションへの道（その5）　〜

前回はPICT画像を取り扱うための代用APIを調査してみました。今回は、文字列（ストリングス）の作成や操作に関係するモダンなCarbon APIを紹介したいと思います。

従来、Macintosh用アプリケーションの開発で文字列を扱う場合には、Cストリングスの代わりにPascalストリングス（Str255）が多用されてきました。これは、初代Macintoshシステム（ひょっとしてLisaからの遺産だったかも…）の開発用言語としてPascalが使われていたのが原因です。そのため、QuickDrawやToolBoxの各Managerの文字列を取り扱うAPIの引数には、必ずPascalストリングスが渡されるように設計されていました。

例えば、Text Utility（TextUtils.h）には、GetIndString()というSTR#リソースからインデックス（番号）参照で特定のPascalストリングスを抽出してくる大変便利なAPIがありました。まあ、これも予想通りDEPRECATED指定なので、そのうち利用できなくなるのですが（寂しい）。色々と調査をしてみると、Pascalストリングスの操作に関連したAPIはDEPRECATED指定になったものが多いようです。

void GetIndString( Str255 theString,short strListID,short index );

筆者は、アプリケーションでエラーアラートなどを表示する場合、このAPIを用いて、その文字列内容をSTR#リソースから抽出して利用していました。ちなみに、2つめの引数はSTR#リソースのID番号でして、これを切り替えることにより、自作アプリケーションを多国語に対応させるような処理も行えました（随分と昔の話です）。ただし、Pascalストリングスは先頭の1バイトにその文字列長の値が代入されています。そのため、1文字が1バイトだとすると、最長で255文字の文字列しか取り扱うことができません。つまり、何らかの処理において長い文字列を扱いたい場合には、必ず制限が付きまといます。

ちなみにCストリングスは、その最終バイトにゼロを代入することで文字列の終わりとしますので、文字列の長さには制限がありません。また現在では、Unicode（Mac OS Xのファイルシステムで利用）をはじめとする多種多様の文字エンコーディングが存在しますので、そうしたものを統一して操作するにはPascalストリングスでは力不足です。まあ、ず〜と今までの間（20年以上も）Macintoshのシステムの中心でPascalストリングスが生き残っていたこと自体が奇跡なのですが（笑）、Mac OS Xでは、その主役の座を別の文字列フォーマットに譲ることになりました。Mac OS Xでの文字列は、Core Foundation APIで多用されているCFString（CFStringRef）として参照されます。

CFStringを直接操作するAPIの解説は後述するとして、古くからあるAPIのCFString対応がどうなっているのかを調べてみましょう。例えば、ウィンドウ、メニュー、コントロールなどのユーザインターフェース・オブジェクトの名称を設定する場合、昔のAPIであれば必ずPascalストリングスが用いられていました。対象がウィンドウであれば、その名称（タイトル）を設定する時にはSetWTitle()を、逆に表示されているタイトルを得る時には、GetWTitle()を用いていました。不思議なことに、実はこの2つのAPIはDEPRECATED指定ではありません。

SetWTitle( WindowRef window,ConstStr255Param title );

GetWTitle( WindowRef window,Str255 title );

現在では、こうしたAPIに対してStr255の代わりにCFStringRefを渡す代用品が用意されています。SetWTitle()の代用品としてはSetWindowTitleWithCFString()が、GetWTitle()の代用品としてはCopyWindowTitleAsCFString()が用意されています。Control ManagerやMenu Managerの同種のAPIについてもまったく同じことが言えます。

SetWindowTitleWithCFString( WindowRef inWindow,CFStringRef inString );

CopyWindowTitleAsCFString( WindowRef inWindow,CFStringRef *outString );


続いて、最初からCFStringを使うように設計されたモダンAPIをいくつか見てみます。以下のopenMyDialog()は、ファイル名が「Dialog.nib」というNibファイルをオープンし、そこに定義されている「Test_Dialog」というオブジェクトを使いウィンドウを作成するルーチンです。

short openMyDialog( WindowRef *wptr )
{
    IBNibRef     nibRef;
    short        err=1;

    if( ! CreateNibReference( CFSTR( "Dialog" ),&nibRef ) ) // Nibファイルを開く
    {
        if( ! CreateWindowFromNib( nibRef,CFSTR( "Test_Dialog" ),wptr ) )
        {                                    // オブジェクトからウィンドウを作成
            DisposeNibReference( nibRef );   // 不必要になったIBNibRefを削除
            ShowWindow( *wptr );             // ウィンドウをオープン
            err=noErr;
        }
    }
    return( err );
}


上記の、CreateNibReference()の1つ目の引数とCreateWindowFromNib()の2つ目の引数には、CFStringRefで参照されるNibファイル名とウィンドウオブジェクト名を渡します。定数（固定値）のCFStringRefを引数に渡す時には、例題のようにCFSTR()の内部にCストリングスを記述すればOKです。これは、Pascalストリングスを”\pDialog”と記述したのと同じことです。

引数として渡すCストリングスが不定の場合には、CストリングスからCFStringを作成することで得られるCFStringRefが必要です。CFStringRefを作成したり操作したりするAPIはCFString.hに定義されています。こうしたAPIを用いれば、Pascalストリングス、Cストリングス、Unicode文字列などをCFStringへと変換し、それを参照するためのCFStringRefを得ることができます。例えばCストリングスをCFStringへ変換するためには、以下のようにCFStringCreateWithCString() APIを用いた簡単なルーチンが利用できます。

OSErr cToCFString( char *cstr,CFStringRef *cfstr )
{
    short    err=1;

    if( *cfstr=CFStringCreateWithCString( NULL,cstr,
                                        CFStringGetSystemEncoding() ) )
        err=noErr;
    return( err );
}


得られたCFStringRefが不必要になった場合には、他のCore Foundation APIで作成するオブジェクトと同様、CFRelease()に渡して解放する必要があります。この時の注意点は、CFRelease()に渡すCFStringRefがゼロ（NULL）などであると、CFRelease()を実行した時点でアプリケーションが落ちてしまうことです。筆者は、以下のようなルーチンを作り、こうした事故を未然に防ぐようにしています。

OSErr disposeCFString( CFStringRef cfstr )
{
    short    err=1;

    if( cfstr )
    {
        CFRelease( cfstr ); // CFStringRefの解放
        err=noErr;
    }
    return( err );
}


逆にCFStringからCストリングスを得るには、CFStringGetCString() APIを用いた以下の様なルーチンを準備しておくと便利です。

OSErr cfToCString( CFStringRef cfstr,char *cstr )
{
    short    err=1;

    if( CFStringGetCString( cfstr,cstr,256,CFStringGetSystemEncoding() ) )
        err=noErr;
    return( err );
}


今回は、Pascalストリングスの代わりとして登場したCFStringを簡単に紹介しました。次回は、CFString自体を操作するAPIを含め、さらに詳しくその特徴や活用方法などについて解説したいと思います。

つづく

S

queakではじめるSmalltalk入門　　　第72回　　鷲見 正人

本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkについて、最近話題のSqueakシステムを使って紹介しています。前回は、製作中の簡易GUIビルダにおいて、メソッド「#addFieldTo:」で、設置するテキストフィールドの大きさを任意に指定できる機能を拡張しました。今回は、逆に既存のテキストフィールドを削除するメソッド「#removeWidgetFrom:」と、それをマウス操作により起動するためのメニュー項目「delete」を追加しましょう。

簡単のため、削除のためのメニュー項目を選択後、GUIビルダウインドウをクリックすると、そこにあるテキストフィールドを削除する…という仕様にします。

クリックした場所の画面上での座標は、すでに第64回で予習したとおり、クラスPointにメッセージfromUserを送信することで容易に得られます。一方、ウインドウは自分にサブモーフとして登録されているウィジェット（この場合、テキストフィールド）を知っていて、paneMorphというメッセージを送るとそれらを要素として収めたコレクションとして返してきます。これらのことを利用して、クリックした場所にあるウィジェット（サブモーフ）を判断して削除するメソッドは次のように書くことができそうです。

removeWidgetFrom: window
   | clickPoint selected |
   clickPoint := Point fromUser.
   selected := window paneMorphs
      detect: [:morph | morph bounds containsPoint: clickPoint]
      ifNone: [].
   selected ifNotNil: [selected delete]


クラス「GuiBuilder」のブラウズしている状態で、このコードを選択してコピー＆ペーストでGuiBuilderをブラウズ中のシステムブラウザのコードペインに貼り付け、accept（cmd + S）してください。システムブラウザ右上のペインに「removeWidgetFrom:」が追加されれば、コンパイルは成功です。

クリックした場所に存在するウィジェットを検出する手段はいくつか考えられますが、ここでは#containsPoint:による判定と#detect:ifNone:の組み合わせにより記述しました。

「#containsPoint:」はRectangleのメソッドで、起動すると、名前の通りレシーバである矩形（a Rectangle）がパラメータとして添えられた座標（a Point）を含んでいるかどうかについて、その結果を真偽値で返してきます。

(0 @ 0 corner: 10 @ 10) containsPoint: 5 @ 5     " => true  "
(0 @ 0 corner: 10 @ 10) containsPoint: -1 @ -1   " => false "


もうひとつのキーになるメソッド「#detect:ifNone:」は、レシーバとなるコレクションの中に、第一パラメータとして添えたブロックの評価値が真になる最初の要素を見つけて返します。

#(1 2 3 4) detect: [:each | each even] ifNone: []   " => 2  "
'string' detect: [:char | char isVowel] ifNone: []  " => $i "


該当する要素がひとつも見つからない場合は、代わりに第二パラメータに添えたブロックの評価値を返します。ブロック内に何も記述しない場合はnilが返ってきます。

'rhythm' detect: [:char | char isVowel] ifNone: [#none]  " => #none "
'rhythm' detect: [:char | char isVowel] ifNone: []       " => nil "


先述の#removeWidgetFrom:では、クリックした場所にウィジェットが存在しない場合がこれにあたり、返値はselectedに関連づけされます。最後の仕上げの式では、selectedがnilでなければ、つまり該当するウィジェットが見つかっていれば、それに対してメッセージ「delete」を送って削除しています。

さて。このメソッドをGUI上での操作に結びつけるには、ウインドウメニューにこのメソッドを起動するためのメニュー項目を追加しておく必要があります。仮に「delete」とでもいたしましょう。「add field」メニュー項目と同様、 

#addModelItemsToWindowMenu:のコードの改変で簡単に指示できます。

addModelItemsToWindowMenu: aMenu
   | window |
   window := aMenu defaultTarget.
   aMenu addLine.
   aMenu add: 'add field' target: self selector: #addFieldTo: argument: window.
   aMenu addLine.
   aMenu add: 'delete' target: self selector: #removeWidgetFrom: argument: window


システムブラウザ右上のペイン（メソッド名リスト）より「addModelItemsToWindowMenu:」をクリックして選択し、コードを上のように書き換えるか、もしくは、メソッド「#removeWidgetFrom:」のときと同様にコピーしてから、select all（cmd + A）、paste（cmd + V）（既存のコードと置き換え…）して、最後にaccept（cmd + S）してください。

コンパイルがうまく通れば、その直後からGUIビルダウインドウのウインドウメニューには区切り線と「delete」コマンドが追加されるはずです。

[fig.A]追加された区切り線と「delete」コマンド

この「delete」を選択すると、直後にマウスカーソルがクロスヘア（十字）に変わるので、削除したいテキストフィールドをクリックして指定します。クリックした場所にあるテキストフィールドを消すことができれば、動作は正常です。

バックナンバー：

［訂正］前回、最後に示した#addFieldTo:中で、「window bounds」とあるのは「window layoutBounds」の誤りです。悩んでしまった方、ごめんなさい。

ニュース・解説

　今週の解説担当:木下 誠

———————————————————————-
Leopard Dev Centerが開設
———————————————————————-

「Leopard Dev Center」が開設されました。Leopardに関連する開発情報を一手に集めたページです。いよいよLeopardへの移行が現実のものとなってきました。このページでは、ガイド、リリースノート、リファレンス、サンプルコードが提供されています。Leopard Dev Centerへのログインには、ADCのPremierかSelectの権限が必要です。

同時に、Leopard情報のアップデートとして、「Leopard Technology Series for Developers」が公開されています。こちらは、一般の方も見る事ができます。Image KitやPicture Taker Panelなど、新しい情報も追加されています。

Leopard Dev Center
https://developer.apple.com/leopard/devcenter/

Leopard Technology Series for Developers
http://developer.apple.com/leopard/overview/index.html

———————————————————————-
Accessibility APIチュートリアル
———————————————————————-

CocoaでAccessibility APIを使う方法を解説したチュートリアルが公開されています。二部構成になっており、Part Iは「Enabling Accessibility in Your Cocoa Application」、Part IIが「Adding Accessibility Support in Custom Views in Your Cocoa Application」となります。

Part Iでは、Accessibility APIのオーバービューが紹介されています。Part IIは、カスタムビューでそれを実装する、実践編です。

Enabling Accessibility in Your Cocoa Application
http://developer.apple.com/ue/accessibility/accessibilityincocoa.html

Adding Accessibility Support in Custom Views in Your Cocoa Application
http://developer.apple.com/ue/accessibility/accessibilitycustomviews.html

———————————————————————-
ApertureのSDK
———————————————————————-

Apertureでプラグインを作るためのSDKが公開されています。SDKのオーバービューと、リファレンスの、二種類のドキュメントがあります。

Aperture SDK Overview
http://developer.apple.com/documentation/AppleApplications/Conceptual/AppleApp_Aperture_001/index.html

API Reference: Aperture SDK
http://developer.apple.com/documentation/AppleApplications/Reference/AppleApp_Aperture_002/index.html

———————————————————————-
ライブラリのリンクに関するQA
———————————————————————-

ライブラリのリンクに関するQAが出ています。「QA1393: Using static versions of exisiting dynamic libraries」です。

ここでは、システムにスタティックライブラリとダイナミックライブラリがあった場合、明示的にスタティックライブラリをリンクする方法を解説しています。Xcodeで、Library Search Pathsを設定し、かつ-search_paths_firstフラグを指定する事になります。

QA1393: Using static versions of exisiting dynamic libraries
http://developer.apple.com/qa/qa2006/qa1393.html

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

　

MOSA Developer News　　　略称［MOSADeN＝モサ伝］
　　　　　　記事投稿受付　http://www.mosa.gr.jp/topics/mdn-toukou.html
Apple、Mac OSは米国アップルコンピュータ社の登録商標です。またそのほかの各製品名等はそれぞれ各社の商標ならびに登録商標です。
このメールの再配信、および掲載された記事の無断転載を禁じます。
特定非営利活動法人MOSA　　http://www.mosa.gr.jp/
Copyright (C)2006 MOSA. All rights reserved.