|
HMDT - Back Number / January, 2002 |
January, 2002
Cocoa 1001、NSResponder の responder chain の話。 Cocoa 1001 - Foundation/NSResponder
Cocoa 1001、今回は NSView に関して、ちょこっと追加。 Cocoa 1001 - Foundation/NSView
(前回のあらすじ。GUI を操作するときは、コマンドを与える方法がいろいろあるけど、それぞれどのくらいのステップがかかるか、数えてみよう!) てなわけで、各項目、どのくらいかかるか数えてみよう。いっとくけど、これは mkino の独断と偏見で、文献等に根拠を求めてるわけじゃない。ただ単に、おれがそう思っただけ、だからな。そこのところ留意して、あんまり参考にしないように。 ■メニュー 1 ステップ(ただしサブメニューが加わるごとに + 0.5 ステップ) Mac の UI において、コマンドを与えるいちばん基本的な方法は、メニューから選ぶことだよな。メニューを選択することを 1 ステップと数えるぜ。ただし、サブメニューを潜るごとに + 0.5 ステップと数えるよ。サブメニューを深くすればするほど、ステップ数の見地からは不利になる、っていう立場だな。 ただ、サブメニューが常に悪いか、といえばそうじゃないと思う。たとえば、「最近使った項目」というメニューを考えよう。これはたいがい、サブメニューの中にあるよな。このメニューは、項目の数が増減することが予想されるよね。これがさ、第一段階のメニューにあったら、伸び縮みしてうざったいじゃん。サブメニューに隔離しちゃった方がいいよな。 ■コントロール(ボタン、プルダウンメニュー、ポップアップメニューなど) 1 ステップ ボタンを押したり、ポップアップメニューを選択したりするのは、1 ステップと考えよう。たまに、ボタンとプルダウンメニューがいっしょになっているやつがあるけど(たとえば IE や NN の戻るボタン)、それは、両方まとめて 1 ステップって数えるよ。 ■キーボード・ショートカット 0.5 ステップ(ただし左手だけで操作できる場合) キーボード・ショートカットは、速い。なぜなら、多くの人は、右手でマウスを使うでしょ。その間、左手はどうなってる?お茶飲んでてもいいけど、キーボードの上に置いてみてくれ。そうすれば、右手のマウスで、対象を「選択」したら、即座に、左手のキーボード・ショートカットで「実行」できるでしょ。だから 0.5 ステップ。これに対して、両手を使わないと実行できないショートカットの場合(たとえば Command + delete)、「選択」したあとに、右手をマウスから離さないといけない。この場合は 1 ステップだね。 つまり、キーボード・ショートカットは、左手だけで行えるのがベストだ。しかし、Mac の場合は、左側のキーボードは、ほとんどシステム標準にとられている。Command + C とか、Command + V とか。アプリケーション独自に追加できるものは、あんまり残ってないね。 ■コンテクスト・メニュー 0.5 ステップ(ただしマウスに右ボタンがついている場合) コンテクスト・メニューは、速い。なぜなら、マウスで「選択」したあと、マウスを動かすことなく、メニューを表示して「実行」できるからな。普通のメニューや、コントロールより速い。Ctrl ボタンを押しながらでもいいけど、やっぱり右ボタンの方が速いでしょ。 あっと、もちろん、ご承知の通り、Mac には標準で右ボタンのついているマウスはないよな。別に、ここで、右ボタンはすばらしい!とか、Mac は 1 つボタンじゃないとゆるさん!とかいう話に持っていくわけじゃなくて、ただ単に、ステップ数っていう見方で考えたとき、右ボタンで選ぶコンテクスト・メニューは速い、っていうだけだ。右ボタンが使いやすいとか、コンテクスト・メニューが使いやすいとかいうのは、また別な話。 ■ツールバー 1 ステップ 画面の端っこや、ウィンドの脇にくっついている、ツールバー。これは 1 ステップと数えよう。 ちなみに、ツールバーは、画面の端(上下端と、左右端)に置くのがベストだ。そこがいちばんアクセスしやすい。なぜなら、いちばん上の端にアクセスするには、何も考えずにマウスを上にもっていけばいい。Mac のスクリーンはトーラスじゃないから、下から出てくることはないからな。それに対して、ウィンドウのタイトルバーの下、とかいう場合には、ちょうどそこで止めるようにマウスを動かさなきゃいけない。これは神経使うよな。だから、画面の端っていうのは、特別な場所なんだ。Mac では、上端は、システムがメニューとして占有している。残りの 3 つの 1 つは、Mac OS X では、Dock が使う。システムが、先にいい場所を取ってしまっているんだな。(この議論は、昔からあるやつだよね。どこだっけ?Tog が言ってたような気がするんだけど、、、) ■タブ・ダイアログ 1 ステップ(タブを移動するごとに) 1 枚のダイログの中に、複数のダイアログをおさめることができる、タブ・ダイアログ。このタブを選択するのを 1 ステップと数えよう。タブ付きのツールバーもいっしょね。 (この項つづく)
Cocoa 1001、NSBundle を使った、リソースアクセスの話の続きだよ。 Cocoa 1001 - Foundation/NSBundle あ、リソースっていっても、ウィンドウの見た目を変えるとかじゃなくて、もっと地味な話ね。Dictionary や Array といった Collection クラスのリソースの使い方の一例。
ユーザインタフェースのお話。 つまるところさ、コンピュータの操作ってのは、対象の選択と、それにコマンドを与える、の繰り返しじゃない?たとえば、Finder で、フォルダを「選択」して、情報を見る、を「実行」する。たとえば、テキストエディタで、文字列を「選択」して、フォントの変更を「実行」する。それの繰り返しだよね。 この、「選択」->「実行」っていう流れは、GUI で多いんだよね。これがコマンドラインだと、最初にコマンドが来て、その次に引数を与える。これって、突っ込んで考えてみると、GUI では対象の選択が楽だから、ってことが言えないかね?フォルダを選択するのは、クリック一回でしょ(見えてれば)。文字列を選択するのも、ずりずり、っとドラッグしてやればいい。コマンドラインを考えてみると、そっちはめんどくさい。フォルダ選択するのにも、いちいち名前入れないといけないし。テキストの選択は、もう、考えただけでいやになる(慣れれば楽、というのはとりあえず置いとく)。そのかわり、コマンドを与えるのは、簡単だ。数文字タイプすればいい(そのコマンドを覚えていればな)。GUI でのコマンドの与え方は?うーむ、これがちょっとめんどくさいんだよねぇ。 キーボード・ショートカットとかは早いよなー。セーブはコマンド + S で一発だし。それに比べりゃダイアログとかはめんどくさい。ひどいときは、メニューをずるずる引っ張りだしてきて、その中から選んで、ダイアログを表示させて、その奥の奥に隠れているボタンを探し出さないといけないときもある。コマンドの実行なんて、早けりゃ早いほどいいじゃない?たぶん、そうだと思うんだけど。じゃあさ、実行するまで、何ステップかかるか、数えてみないかい?(この項つづく)
Cocoa 1001、あんまりたいしたネタじゃないんだけど。忘れると嫌なので、備忘録代わりに。 Cocoa 1001 - Foundation/NSBundle
Cocoa 1001、NSScanner でのトークン分割を移しました。 Cocoa 1001 - Foundation/NSScanner
この前、NSString をトークンに分割するのに、独自のコードを使ったら、「NSScanner 使えばいいじゃん」っていう、突っ込みを多数いただきました。ありがとうございました。知りませんでした、NSScanner。あー、もう、恥ずかしいことしきりです。素人はだめっすねぇ。 早速使ってみました。こんな感じでいいですか?
これで、できますね。でもどうせだったら、NSEnumerator 使いたくないですか?ないですか。そうですか。iterator 的な探索だから、enumerator でアクセスした方が、、、でも、NSScanner の方が融通が効くな。
あー、つかれたー。文字列処理、めんどい。 なにか、Objective-C から簡単に叩ける、正規言語処理系はないかな?yacc を使うのが正解かな、せっかくの UNIX なんだし。
これも、読んだまま、Carbon プログラミングの本だ。この本の特徴は、一目見れば分かるんだけど、厚い!1500 ページを超えてる。内容は、主要な Carbon API をすべて網羅しているもの。リファレンス的な本だね。あと、サンプルコードがやたら多いのも特徴。一通り、Carbon プログラミングの基礎を把握した人が、さらに突っ込んだプログラミングをしたいときに、使える本です。 本の位置付けとしては、往年の Inside Macintosh みたいなものかな?それにしては、ちょっと突っ込みが甘いか。 あ、あと、英語です。念のため。
Cocoa 1001、NSString の話だ。文字列のトークン分割って、けっこう使うじゃない?ほら、コンマとか空白で区切られた文字を取り出すやつ。あれ、できないのかなー、と思って NSString の API ざっと見てたんだけど、なんかないじゃない。こんなもの、誰か作ってるだろうなー、とは思ったけど、Web 探すのもめんとくさい。作った方が、手っ取り早いぜ!というわけで、作ってみた。 Cocoa 1001 - Foundation/NSString 手っ取り早さ優先で作ったので、けっこう雑だよ。たとえば、日本語での動作確認とかしてないし。もっといい実装がある、という方は、教えて下さい。
本の内容は、サンプルプログラムを作ることを通して、Carbon の内容を一通り触る、って感じだ。基本的に、いままでの classic な Mac OS のプログラミングの知識は必要ない。あ、だけど C 言語の知識はいるからね。これを読めば、Basic な Carbon アプリは簡単に作れる。 Carbon は、いままであんまり興味がなかったから、ふーん、っていう感じで読んだんだけど、そんなに悪くないね、Carbon も。ただ、C 言語がベースだから、Objective-C に慣れちゃうと、メモリの管理とかめんどくさそうだよなー、とは思う。ま、そのへんは、プロジェクト始める前に、統一しておくんでしょう、理想的には。 日本語訳はこなれてます。トンデモ訳はないです。よく、技術系の本だと、その技術を知らない人が訳して、おいおい、これだったら原書を読んだ方が分かりやすいよ、ってのもあるけど、この本はそんなことないです。 てなわけで、過去に Mac アプリケーションを書いたことがある人や、Objective-C なんてマイナーな言語は使いたくないという人や、オブジェクト指向ってパフォーマンス悪いんでしょという人や、C++ はシンボルテーブルが長くなって読みづらいぜという人や、いままでバリバリ Solaris プログラミングしてたのに Mac の部署に左遷されたという人、なんかにお勧めです。でも、ぼくは Mac でゲームを作りたいです、プログラム言語はなにがいいですか?という人には、あんまりお勧めできないかも。そういう人には、もっといい本が別にあるからね。 次に期待されるのは、とうぜん「入門 Cocoa」なんだけど、これは春に発売予定だそうです。英語が苦手で日本語が大好きな人は、期待して待て。
いちおう説明しておくと、JBuilder は Borland が出してる Java 用開発環境。便利な GUI デザイン機能と、高い移植性が素敵だ。そのため Mac OS X にも簡単に移植できたんだよね。 ダウンロードして、インストールしてみる。問題なく、すっと通る。あ、アプリケーションがパッケージ化されてる。いいね、Mac OS X 環境に馴染んでいる。起動してみる。
おぉ、ちゃんと Aqua 化されてるじゃん。ちょっと動かしてみたけど、細かい問題はあるものの、どうにか使い物になりそう。ただし、動きは遅いです。きびきびした動作は期待できない。 Mac OS X で、本格的な Swing アプリケーションを作りたい人や、Windows 環境と共通のプロジェクトを使いたい人に、お勧めです。
間が空いてしまったんで、自分でも前の話を忘れてしまったけど、とりあえず続きだ。 で、私が Mac を買った第一の目的は、やっぱり、プログラミングでした。とはいっても、最初の敷居は高かったですね。なにしろ、開発環境が高い!そのころ、学生だった mkino には手が出ませんよ。Think C の高かったこと!何の気なしに Think C って言ったけど、もう、知らない人もいるのかな。Symantec が出してた Mac の開発環境です。そう、Symantec って、ワクチンソフトのメーカーじゃなくて、開発環境を作ってたんですよ。 そんな時に、彗星の如く現れたのが、CodeWarrior。これは、アカデミックバージョンが安かった。偉い!Metrowerks!BUG が日本語サービスやってた、ってのも大きかったよね。というわけで、念願の開発環境を手に入れましたよ。あ、ちなみに、その頃の mkino の技術力は、遠い昔に BASIC をやったことがあって、大学でぼちぼち C のプログラムを書きはじめた、っていう感じです。まあ、有り体にいって、技術力なんて無きに等しいっていうとこですね。 だから、ご想像の通り、CodeWarriror をインストールしたはいいけど、なにやっていいか分からん 状態に落ち入ったわけです。printf 出ないじゃん!scanf はどうなってんの?もちろん、SIOUX の仕組みなんて分かりませんでしたよ。それを思うと、今の Mac OS X は、何と恵まれてることか。基礎的な環境から、最も先進的でパワフルな環境までそろってる。一昔前の Mac 程度の開発環境しか持ってない Windows や、操作するだけで多大な労力を要する UNIX に比べると、天国のようだ。すべてのプログラム教育機関は Mac OS X を導入すべきだと思うよ、いやほんとに。 でね、このままじゃしょうがない、っていうんで、CodeWarrior のマニュアルについてるチュートリアルをやってみたんですよ<最初からやれって。そのチュートリアルは、C を使って、直接 Window Manager の API を叩いてウィンドウを表示する、っていうものだったんですよ。そう、PowerPlant も使わないで。わけ分からないまま、首っ引きでプログラム入れましたよ。10 数行のプログラムだったな。いくつかコンパイルエラーが出た後、実行できました。そしたら!アップルメニューが、2 個表示されてる!何それ!?(これは単にプログラムの入力間違い)さらに、ウィンドウは表示されてるけど、ドラッグしようとしても動かない!リサイズもできない!そして、さらに、ご想像の通りだと思いますが、メニューも動かないし、QUIT もできない!なんじゃ、これ!もう、パニック状態でしたよ。いま思うと、自分の書いたプログラムで、パニックになってどうするんだ、って思いますけど、あの時はショックだった。その時まで、Mac っていうのは、ウィンドウが開いて、アイコンが表示されて、メニューが出る、っていうのが自動で行われる、って思ってたんだ。だけど、その裏にはきちんとコードがあって動いているんだ、っていうことを体感しました。ウィンドウが表示されるのは、魔法じゃない。裏で動いているコードなんだ。 その日以来、Mac の見方が変わったんだよ。Mac は魔法の箱じゃないんだ。これが、何を意味しているかって?つまり、mkino でも、探究できるものなんだ。これが HMDT の出発点です。Mac OS は、一見すごい処理をしている。だけど、その裏を追い掛ければ、かならずコードが見えてくる。Mac の魔法を解き明かす。だから、いまやっているみたいに Objective-C の runtime の仕組みを知りたがったりするんです。 じゃあ、Mac の魔法が解き明かされた日にはどうなるのか?簡単です。Mac の魔法を拡張するのです。それが HMDT の目標です。あのとき感じた Mac の魔法を、自分の手で作るのです。そして、OS X で開発環境がフリーになって、kernel も読める。夢を実現するための舞台は、整っている。ワクワクしない?コードを書かずにいられないじゃない。 Have a happy Macintosh developing time!
日曜日なんで、お酒飲みながらプログラミングしてたら、へろへろになってしまいました。お酒飲んでると、あるときガクッとパフォーマンスが落ちるねー。酔っぱらうと昔の話を始めるのは、年をとった証拠、と思われるのですが、その例にもれず昔の話でもしましょう。 最近、 そんな感じで Mac の洗礼を受けて、最初に購入したマシンは Color Classic でした。これは、予算の都合と、「Mac は一体型じゃないといけないんだよな、Steve!」という、Mac 初心者にありがちな思い込みによるものでした。(でも、いまだにセパレートのマシンは買ってないよん)ちなみにこのマシンは、その後、Color Classic II へ純正アップグレード(そうだよ、あの頃は純正アップグレードなんてものがあったんだ)、VGA 化、68040 化、と Color Classic がたどるアップグレードの道を一通りとおって、現在お蔵入りとなってます。だって、ファンがうるさいんだもん。(続く)
Cocoa 1001、きのうの続きで、メソッドのリストからメソッドを取り出すんだ。 Cocoa 1001 - Objective-C/Method ここまでは分かったんだけど、メソッドの型名が、けっこう意味不明だ。うーん、どうしよう。だれか、知ってたら教えてー。試行錯誤で推測していくしかないかな、、、
Cocoa 1001、ちょと先にメソッドの話。クラスの定義からメソッドをとりだしたいんだけど、その準備。メソッドのリストを取り出さないといけない。 Cocoa 1001 - Objective-C/Method しかし、最近は細切れ更新ばっかりだな。まとまった時間がほしいよー。
Cocoa 1001、今度はインスタンス変数の話ね。 Cocoa 1001 - Objective-C/Instance Variable 読んでそのまま、Class 型からインスタンス変数の定義を探す話です。
Cocoa 1001、さっきは、Objective-C の runtime から、すべてのクラスを取ってきたけど、今度はそれを階層表示だ。 Cocoa 1001 - Objective-C/Class 今回作ってみたのが、右みたいなアプリケーションだ。Cocoa の NSOutlineView を使って、階層表示させてみた。これで見ると、ドキュメントで公開されていないクラスが、こんなにあるのかー、って面白いんだ。
Cocoa 1001、Objective-C の runtime から、すべてのクラスを取得する、っていう話。 Cocoa 1001 - Objective-C/Class これを使えば、クラスブラウザが作れるなー。
ちゃらんぽらんさんが、AppleScript に関する記事を公開していました。Mac OS X に対応しています。XML を取り扱うサンプルもあったりして、いい感じです。AppleScript Studio も、取り上げてほしいです。
ついに、われわれは new iMac のデザイン・コンセプトを発見した!
Cocoa 1001、これから何回か Objective-C の runtime についての話題を取り扱うよ。Cocoa framework ではないけど、密接に関係している話なんで、Cocoa 1001 に含めるね。 まずは、軽く Class 型の話などから。 Cocoa 1001 - Objective-C/Class
AppleScript Stuido に挑戦する Studio AS、前回作った iTunes Label Maker の続編です。今度は AppleWorks と連動させます。 Studio AS - Trial Tutorial: iTunes Label Maker 2 Apple から配付されている AppleScripts for iTunes を使っています。 Macworld のアオリ文句の訳はやめました。自分で書いてみて、つまんなかったから。
Apple のサイトでは、Macworld に向けてカウントダウンを、コピーとともに行ってるけど、これは HMDT から見れば、こういう意味だな、きっと。
デベロッパ的に、偏ってみました。きちんとしたものを見たい方は、pierre design さんの事前情報ページへどうぞ。
年も明けましたが、さっそく先日から、せこせこと働きに出てるよ。新年だしなぁ、なんか景気付けにやりたいよな。ここは、やっぱりビルドだろう。 そんなわけで、いまさらなんだけど Mozilla を落としてきて、ビルドをやったりしてるのでした。でかいよなぁ。重いよなぁ。やっぱりさぁ、新しい Mac が出て、1GHz とかだったりしたら、やるべきことはベンチマークじゃなくて、ビルドだよなぁ。絶対。「うぉぉ、こんなに速くなってるですかい」と、驚くのだ。いちばんおおもとの、ヘッダファイルを、ちょこっ、と変更してみて、「しまった、全部ビルドやりなおしになっちゃうよー」っていいながら、「うわぁ、それも全部あっという間に終わっちゃうよー」となるのだ。 液晶 iMac とか出されてもねぇ。やっぱり Mac OS X 使うなら、Project Builder でしょ。PB がさくさく動いて、なんぼ。それには Multi CPU だな。dual でも足らん。quad でいこう。そのための Mach だし。"Power Mac G5 Quad"。かっこいい!Quadra の復活みたいだ。 あ、ビルド止まった。Fatal error だって。くぅ。
|
|
Home | Link | Download | Back Number | Speciall Issue
|