MOSA Multi-OS Software Artists

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

2006-12-12

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

■　 〜AFP編〜

　AFPサービスおよびネットワークマウントの設定が完了しましたので、あとはユーザごとにホームを設定すればいよいよネットワークホームが利用できるようになります。

□ホームの設定
　ユーザごとのホームの設定ですが「ワークグループマネージャ」を使用します。まずツールバーから「アカウント」をクリックして画面左側にユーザのリストを表示します。次にホームの設定を行いたいユーザをユーザリストから選択してツールバーの下に並んだボタンから「ホーム」をクリックします。この「ホーム」設定画面で選択中のユーザのホームの設定を行います。
　デフォルトでは（なし）が選択されています。ネットワークマウントの設定が完了していればネットワークマウントで設定した領域がホームとして選択可能なパスのリストに追加されています。
　今回の例ですと「afp://server.example.com/Users」がネットワークマウントで設定したホームのパスになります。あとはリストからホームとして設定したいパスを選択して、画面右下の「保存」ボタンをクリックすれば、ユーザのホームの設定が完了します。

・ホームの設定
http://homepage.mac.com/htabata/MXS10.3/img/WGM_Home/WGM_Home_02.png

　パスのリストの上には設定したパスが表示されますが、ネットワークホームを利用する場合には2種類のパスが設定されていることが確認できます。2種類のパスの意味はそれぞれ次のとおりです。

・exampleユーザの場合
afp://server.example.com/Users/example
　クライアントからみたサーバ上のホームのパスのURL
/Network/Servers/server.example.com/Users/example
　ホームをマウントするクライアント上でのパス

　あとは同様の手順をユーザの数だけ繰り返せばよいのですが、ユーザが複数存在した場合、いちいち1ユーザずつ設定するのは手間がかかります。そこでこんなときには画面左側のユーザリストから、ホームを設定したいユーザをすべて選択してから、ホームの設定を行います。すると複数ユーザのホームを一括して設定することができます。

・複数ユーザのホームの設定
http://homepage.mac.com/htabata/MXS10.3/img/WGM_Home/WGM_Home_02.png

　このように「ワークグループマネージャ」では複数のユーザに対して設定をまとめて行えますが、ホーム以外の設定でも複数ユーザの設定をまとめて行うことができます。

□ホームの作成
　「システム環境設定」の「アカウント」でローカルユーザを作成した場合には自動的に「/ユーザ」にホームが作成されますが、「ワークグループマネージャ」でホームの設定をしただけですと、ホームは自動的には作成されません。
　もしホームが存在しない状態で実際にネットワークユーザがクライアントコンピュータにログインしますと、その時点でホームが自動的に作成されます。ですが、あらかじめホームを作成しておくこともでき、ホームを作成するにはホームの設定画面の下にある「今すぐホームを作成」ボタンをクリックします。
　このボタンはその名前からして、クリックするとすぐホームを作成してくれそうな気がしますが、実際には画面右下の「保存」ボタンをクリックしないとホームは作成されません。作成されたホームはサーバ上の「/ユーザ」に作成されます。
　ホームの作成も、ホームを設定したときと同様に画面左側のユーザリストから複数ユーザをまとめて選択した状態で実行することができます。この場合選択していた各ユーザのホームが作成されます。
　ホームの作成は「ワークグループマネージャ」を使用するほかにもコマンドラインから実行することができます。「/usr/sbin/createhomedir」というコマンドが用意されており、例えばexampleユーザのホームを作成するには次のようにこのコマンドを使用します。

・コマンドラインからのホームの作成

% createhomedir -u example

　なおこのコマンドはroot権限で実行する必要がありますので、通常はsudoコマンドを先頭につけて実行します。登録済みのすべてのユーザのホームを作成することもでき、その場合には次のように”-a”オプションを使用します。

・すべてのユーザのホームの作成

% createhomedir -a

　ちなみにホームの作成ですが、「/システム/ライブラリ/User Template」に各言語ごとのホームのテンプレートが準備されており、こちらを参照することでホームの作成が実行されます。
　ホームの構成をカスタマイズすることも可能ですが、その場合はcreatehomedirコマンドを利用したシェルスクリプトなどを作成して対応するのがよいでしょう。

　さて、これでネットワークホームに関する設定がすべて完了しました。サーバ上での設定がすべて完了した後に、クライアントコンピュータを再起動してネットワークユーザとしてログインすれば、ネットワークホームが利用できるようになります。

つづく

SqueakではじめるSmalltalk入門　　　第75回　　鷲見 正人

本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkについて、最近話題のSqueakシステムを使って紹介しています。

前回は、#addFieldTo:、#addButtonTo:といった、各ウィジェットをGUIビルダのウインドウへ追加するための専用メソッドの共通部分を新しい#add:To:メソッドとしてまとめ、ウィジェット生成のほうは、ウィジェットタイプ（#fieldや#buttonといった…）を名前に持つメソッドに分担させる改変を行ないました。

これにより、当初のテキストフィールドやプッシュボタン以外のウィジェットを扱えるようにする拡張手続きはとても簡単になりました。が、まだ相変わらず、追加したウィジェット用にメニュー項目を新設する作業は必要です。具体的には、 #addModelItemsToWindowMenu:というメソッドに、メニュー項目の追加、および、そのメニュー項目に適切なウィジェットタイプのシンボルをパラメータとして#add:to:メソッドを呼び出すよう機能の割り振りをする行を挿入しないといけません。

そこで今回は、このメニュー構築の手続き自体も動的にしてしまい、新しく扱うウィジェットを生成するためのメソッドを定義するだけで済ませることが可能な仕組みを考えることにします。

▼与えられたウィジェットタイプ群からメニューを自動的に生成する
たとえば、#fieldと#buttonという二種類のウィジェットタイプを扱えるとして、それを表わす情報が配列#(#field #button)として与えられたと想定しましょう。ここから、「add field」「add button」といったメニュー項目用の文字を生成することは#collect:を使えば簡単です。

#(#field #button) collect: [:each | 'add ', each]   " => #('add field' 'add button') "

なお、配列リテラル式において、要素となるシンボルの#は（対象となるシンボルがスペースなどの記号を含まないなら…）省略可能なので、こう書いても同じです。

#(field button) collect: [:each | 'add ', each]

#collect:は結果を集めていますが、ただブロック内の処理を繰り返すだけなら#do:を用います。このことをふまえて、#addModelItemsToWindowMenu:を次のように書き換えてみましょう。書き換えたらaccept (cmd + S)によるコンパイルもお忘れなく。

addModelItemsToWindowMenu: aMenu
   | window |
   window := aMenu defaultTarget.
   aMenu addLine.
   #(field button) do: [:widgetSym |
      aMenu
         add: 'add ', widgetSym
         target: self
         selector: #add:to:
         argumentList: {widgetSym. window}].
   aMenu addLine.
   aMenu add: 'delete' target: self selector: #removeWidgetFrom: argument: window

ウインドウメニューをプルダウンしても、これまでとの違いはまったくありませんし、項目を選択したときの動作も同じです。しかし、#(field button)のところにウィジェットタイプを書き足すだけでメニュー項目を増やすことができるようになっています。ためしに、#(field button list)と書き換えてacceptしてみてください。メニュー項目には「add list」が追加されているはずです。

[fig.A]メニュー項目に自動的に追加された「add list」

このメニュー項目はまだ機能しませんが（選択するとエラー）、項目リストを扱うためのウィジェットであるa PluggableListMorphを生成する次のメソッド「#list」を追加することで動作するようになります。

list
   ^ PluggableListMorph
      on: self
      list: nil
      selected: nil
      changeSelected: nil
      menu: nil

▼扱うことができるウィジェットの種類を動的に得る
残る問題は、#(field button list)といった配列をどうやって得るか？です。これにはSmalltalkの強力なリフレクション機能を活用することにいたします。具体的には、まず、新しい「widget types」というカテゴリを設けて、そこに#field、#button、#listというウィジェット生成用のメソッドを分類しておき、改めて「widget types」カテゴリにあるメソッド名をクラスに尋ねることで、目的の情報を得ようというもくろみです。

システムブラウザにて、メソッドカテゴリリスト（上段右から二番目の枠）で「– all –」が選択されていることを確認してから、メソッド名リスト（右隣、上段右端の枠）から「field」を選択。そのペインのシフト黄ボタンメニュー（shiftキーを押しながら黄ボタン、あるいは、黄ボタンメニューをポップアップさせてmore…を選択）から「change category…」→「new…」を選択し、新しいカテゴリを追加するための入力欄で「widget types」とタイプして入力し「了解(s)」（英語モードならAccept）します。

[fig.B]widget typesカテゴリの追加

すると、メソッドカテゴリリスト（左隣の枠）に「widget types」というカテゴリが現れます。見た目では分かりませんが、一連の作業により#fieldメソッドは、このカテゴリに再分類されています。次に、メソッド名リストから「button」を選択し、同じようにシフト黄ボタンメニューから「change category…」を選択してください。今度はメニューに「widget types」が含まれているので、これを選んでおしまいです。#listについても同様に行ないます。

メソッドカテゴリリストで「widget types」をクリックして選択し、三つのメソッドがきちんと収まっているか確認しておきましょう。もし再分類から漏れたメソッドがあるときは「– all –」を選び直して、操作を繰り返します。

[fig.C]widget typesカテゴリに分類されたウィジェット生成用メソッド群

以上で準備は整ったので最後の仕上げです。クラスに対して、指定したカテゴリに属するメソッド名（セレクタ）を列挙してくれるよう頼むのには、次の式を用います。

GuiBuilder allMethodsInCategory: 'widget types'   " => #(#button #field #list) "

この式を先の#addModelItemsToWindowMenu:でハードコードした配列に置き換えれば、当初の「メニュー生成までの自動化」という目的は達成できます。

addModelItemsToWindowMenu: aMenu
   | window |
   window := aMenu defaultTarget.
   aMenu addLine.
   (self class allMethodsInCategory: 'widget types') do: [:widgetSym |
      aMenu
         add: 'add ', widgetSym
         target: self
         selector: #add:to:
         argumentList: {widgetSym. window}].
   aMenu addLine.
   aMenu add: 'delete' target: self selector: #removeWidgetFrom: argument: window

ためしに、’widget types’のメソッドを別のカテゴリに再分類したり元に戻したりして、メニュー項目がきちんとその変更に追従できているか確認してみてください。

バックナンバー：

ニュース・解説

　今週の解説担当:木下 誠

———————————————————————-
Leopard続報：アプリケーションテクノロジー
———————————————————————-

Leopardの開発者向け情報を小出しに紹介している「Leopard Technology Series for Developers」。新たな項目として、「Leopard Developer Application Technologies Overview」が追加されました。今回は、サードパーティのアプリケーションで使える、Leopardの技術を紹介しています。

取り上げられているのは、Time Machine、iChatとの統合、Calendar Store、Scripting Bridge、Core Animation、64-bitなど。Scripting Bridgeへの言及は、今回が初めてだったではないでしょうか。

Cocoaアプリケーションの開発としてみると、PantherのCocoaバインディングや、TigerのCore Dataのような、いままでのアプリケーションの作り方をひっくり返してしまうようなものはなく、落ち着いた気分で迎えられるアップデートではないでしょうか。

Leopard Developer Application Technologies Overview
http://developer.apple.com/leopard/overview/apptech.html

———————————————————————-
Audio ConverterのQA
———————————————————————-

Audio Converterに関するQAが出ています。「QA1437: Standard Audio -Parsing the kQTSCAudioPropertyID_CodecSpecificSettingsArray 」です。

Auido Converterでは、オーディオの変換に関する設定を行う標準ダイアログが提供されていますが、その設定をCFDictionaryの形で取り出す方法が解説されています。

少し前に公開された「QA1390: Standard Audio – The CodecSpecificSettingsArray and MagicCookie properties」も併せて読んでください。

QA1437: Standard Audio – Parsing the
kQTSCAudioPropertyID_CodecSpecificSettingsArray property
http://developer.apple.com/qa/qa2006/qa1437.html

QA1390: Standard Audio – The CodecSpecificSettingsArray and
MagicCookie properties
http://developer.apple.com/qa/qa2006/qa1390.html

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