今年しょっぱなのビッグニュースは新iMacの発表だったのですが、昨年末のビッグニュースは「CarebonLib_1.5GM_SDK」が発表されたことです（プログラマー限定）。CarebonLib_1.5GM_SDKは、以下のApple SDKサイトからダウンロードすることが可能です。
◇CarebonLib_1.5GM_SDK
http://developer.apple.com/sdk/#Carbon1.5
実際に使用して試してみましたが、DataBrowsrやMLTEなどのバグも随分と解消されているようで、そこそこ安心して使えるようになりました。付属しているUniversal Interfacesのバージョンはv3.4.1f1となっています。
CarbonLibを単独でインストールするための「日本語版 CarbonLib 1.5」も、すでにApple Downloadサイトに登録されています。
◇日本語版 CarbonLib 1.5
http://docs.info.apple.com/article.html?artnum=120047
ただし、Mac OS X 10.1.2に搭載されているCarbon Framworkのバージョンは1.4のままです。Mac OS 8/9用のCarbonLibとMac OS X搭載のCarbon Framworkでは、バージョンの違いによる機能差がどの程度あるのかが明確にされていません。ひょっとすると、Mac OS Xの方が機能やBug Fixが先行している可能性もあります。こうした点については、Apple側からもう少しこまめに情報提供をしてもらいたいものです。
もうひとつのニュースは、Metrowerks社から「CodeWarrior Pro. 7.1 Updater」が発表されたことです。このアップデータは、以下のMetrowerks社のサイトからダウンロードすることが出来ます。
◇CodeWarrior Pro. 7.1 Updater
http://www.metrowerks.com/download/index.taf?function=detail&updates_uid=292
Updaterだけで30Mバイト程度の容量があり、かなり大規模なアップデートであることが分かります。IDEがv 4.2.6へとアップデートされるほか、コンパイラなどにも改良が加えられているようです。CodeWarrior Pro. 7ユーザならぜひともアップデートしておきたいところなのですが、残念ながら日本語版はまだ存在しません。無理やり日本語版をアップデートしたところ、環境設定をはじめ、いくつかのダイアログで日本語の文字化けが起こってしまいました。どうも、こうした使用方法は止めておいた方が良さそうです。
実は、Pro. 7の英語版には、Mac OS 9でIDEを起動すると強制的にアピアランスをグレースケールフォントに切り替えてしまうという大バグが存在していました。私は通常は英語版を使っていたのですが（即アップデートができるため）、このバグのために日本語版を使わざるおえませんでした。日本語版のPro. 7の方は、ちゃんとこのバグが回避されていたのです。今回調べたところ、Pro. 7.1の英語版ではこのバグが解消されていることが分かり、さっそく英語版に切り替えてしまうことに決定しました。日本語版を英語版に切り替えるのには、CD-ROMの「English Components」フォルダにある「English Components.smi」をマウントし、その中にある「English Tools Installer」で上書き処理を実行します。こうして一度英語版にしてしまえば、後は問題なくCodeWarrior Pro. 7.1 Updaterでアップデートすることが可能です。
そんなわけで、元旦からMacに向かいプログラミングに熱中していた私ですが、やはりと言うか予想通りというか、新年早々トラブルに見舞われてしまいました。対象となる環境は、すべてMac OS X 10.1.2です。
・CLOCK（時間＆日付）コントロールの不都合
CLOCKコントロールで「年.月.日」を表示した場合、年を4桁表示にするのか2桁表示にするのかをアプリケーション側から制御できません。どなたか方法をご存知ありませんか？ 現状では、「システム環境設定」の「地域情報」「日付」で「年を4桁表示にする」をチェックすると自動的に４桁になるようです。ただし、この場合「年」をキー入力しようとすると、下位2桁の変更しか受け付けず上位２桁を変更することができません（涙）。こちらは間違いなくバグでしょうね。
・キーボードフォーカスの不都合
エディットテキストやリストなどのコントロールを、TabキーやSetKeyboardFocus()でキーボードフォーカスした場合、どういう訳だかCarbon Eventが発生しません。キーフォーカスは、そのコントロールをマウスクリックで選択したのと同等なわけですから、kEventClassControlのkEventControlHitや、コントロールに割り付けられているkEventProcessCommandなどのCarbon Eventが発生しないと困ります。例えば、エディットテキストでは、マウスクリックした瞬間にKeyScriptを変更したい時があります。また、フォーカスによりカラム内にディフォルト文字列を表示したい場合もあります。今のままだと、こうした処理をするのに煩雑な回り道をする事になってしまいます。
・コントロールフォーカスの不都合
「システム環境設定」の「キーボード」「フルキーボードアクセス」で「すべてのコントロール可能な部分を選択」を選択しておいても、Carbonアプリケーションではこの設定が利きません。Cocoaアプリケーションではちゃんと動きます。また、この機能がONにできるのなら、SetKeyboardFocus()などのAPIでも、ポップアップメニューやラジオボタンに対してフォーカスが出来ないといけません。つまりアプリケーション側からも制御できる必要があるわけです。これも、Mac OS Xへの実装が間に合わなかった機能のひとつなのでしょうか？
「Mac OS Xに対する開発者からの提言」でも上がっていましたが、こうしたCarbon FrameworkとCocoa Frameworkの機能差は早急に解消するべき問題です。そうすれば、現状あるCarbonアプリとCocoaアプリのインターフェースの差異が、ずいぶんと目立たなくなると思います。例えばCarbonアプリから呼び出せないフォントパネルやツールバー機能などがこれに相当します。ColorPickerも両アプリでは異なるダイアログとして表示されてしまいます。また、アラート表示で対象アプリのアイコンがDockから飛び出すインターフェースも、Cocoa Frameworkだけにしか実装されていない機能です。CarbonLib 1.6（2.0?）の目標のひとつとして、こうした不都合の解消に早急に取り組んでもらいたいと思います。
次回は、Carbonアプリケーションから利用できるようになったMac OS X特有の機能を紹介したいと思います。まずは、Dockの様々な機能を活用してみることから始めます。
[小池邦人/オッティモ]