Mac OS X向けのATOKは意外に早く登場するなという印象です。EGBRIDGEもMac OS X対応を明言していますが、日本語環境は意外に早く整うかなと言う印象があります。エディタもすでにCarbon化を終えているところも多く、その意味では期待もさせられるのですが、OfficeのMac OS Xネイティブ対応は今年の後半でしょうし、データベース系ソフトやプリンタドライバの問題を考えれば、完全な移行が可能なのは大分と先になるかもしれません。ただ、個人的にはOMEがきちんと動き出したら、環境を完全にMac OS Xに移行させようと思っています。Classic環境で動かす不便さはとりあえず目をつむってです。それで、実は、PostScriptプリンタを持っていないために、間違いなく印刷は不便をすると思います。Canonのインクジェットを持っていて、比較的Mac OS対応も早いですが、X対応はやはりいつになるかわかりませんからね。まあ、しばらくは、印刷が必要な場合にはPSファイルに出してWindowsでPDFにして印刷かな…という気もしています。あるいは、印刷しなくてもいいようにしてしまうかですね。実は、今のところ、経費精算なんかでやっぱり紙を媒体にしているのです。実データはメールで処理していますが、レシートや伝票を経理の人に「はいっ」って渡すわけにも行かず、帳票類の提出ペーパーを印刷しているのです。わざわざそんなもんを印刷するなと思うかも知れませんが(笑)。だけれども、あらかじめ印刷しておいて、伝票番号なんかを手で記入するのが早いですね。いずれにしても、移行期にはそれなりの我慢が必要なのは仕方ないという気もします。
(新居雅行 msyk@mdonline.jp)
ジャストシステムは、インプットメソッドのATOK14のMac OS対応版をリリースする。2001年3月9日に「ATOK14 for Mac OS 9/8.6」、2001年4月20日にはMac OS Xで稼動する「ATOK14 for Mac OS X」を発売する。価格はいずれも9,800円であるが、ATOK登録ユーザに対しては直販で5,000円で販売される。また、両方のATOK14をパックにした「ATOK14 Suite Pack for Mac OS」も、2001年4月20日から12,800円で発売する。「ATOK14 for Mac OS 9/8.6」の購入ユーザに対しては、1,000円の実費で「ATOK14 for Mac OS X 」を提供する「ATOK14 for Mac OS 9/8.6 特別アップグレードキャンペーン」も行われる。
ATOKはやはり市場でもっとも評価の高いインプットメソッドと言えるだろう。かな漢字変換ではもはや機能の一部分しか語られない。文節の連係や文法上の解説結果などを使ってより確実な漢字混じり文への変換ができる。また、最近のATOKは口語表現でも間違いなく変換する機能や、さらにはインターネットを通じてATOK14間でユーザ辞書を共用できるサービス、あるいはインターネットサイト検索の機能を込めるなど、使い勝手の面でもさまざまな機能が追加されている。Windows版のATOKの発表会での情報では、たとえばATOK14を使うことでWindowsとMac OS、Mac OS Xの間で共通のユーザ辞書を使うことが出来、1つのパソコンで登録した単語がすべてのマシンに反映されるということにもつながり、利便性は高いと言えるだろう。
Windowsの世界では、システムに標準搭載されたMS-IMEは、ATOKを目指して機能強化を図り、ATOKに対抗できるものを目指している。それでも市場の評価はATOKの方が高いものの、MS-IMEもかなり接近したと言えるだろう。一方のMac OSではことえりが標準で組み込まれているが、ATOKとの変換性能の差は歴然とある。ATOKのMac OS向けリリースが後手に回されていたことからも、日本語環境という点ではMacintoshはやはり遅れを取っているという印象は拭えなかった。しかしながら、Mac OS Xに対しては正式発売から1ヶ月後に対応するという点では、素早い対応として評価できる。また、Mac OS 9/8.6版についても、Windows版一太郎11よりは1ヶ月遅れ、Windows版の単体版とは同時に発売されることになった。
関連リンク:インターネットとの連携を徹底強化 Macintosh版日本語変換ソフトの最新版
カテゴリ:アプリケーション
今回は、ViewJPEGの画像ウィンドウに対応したEvent Handlerを実装してみます。ウィンドウのクロウズ、移動、リサイズ、ズームといったCarbon Eventに対応したHandlerルーチンを用意することになります。
今回も前回と同様に、Carbon Event Handlerのインストールルーチンを記述することから始めます。ViewJPEGで、画像ウィンドウに対応するHandlerルーチンをインストールしているのは、setUpWindowEvent()です。
EventTypeSpecの配列には、インストール用のeventClassとeventKindのペアが列記されています。その数は全部で9種類、そのうち「kEventClassWindow」クラスに属するEventは7種類となります。残り2種類のEventは、それぞれ「kEventClassMouse」と「kEventClassKeyboard」クラスに属しています。この3つのクラスに含まれる全9種類のCarbon Eventを、myWindowEventHandler()ただひとつで処理することになります。InstallApplicationEventHandler()により、EventTypeSpecの配列と一緒にmyWindowEventHandler()をインストールします。ちなみに、CarbonEvent.hを調べてみると、kEventClassWindowクラスには非常に多くのEventが属していることが分かります。
当然、これら全部に対応したHandlerをアプリケーション側で用意する必要はありません。必要な物だけをピックアップして対応すればOKです。さっそく、画像ウィンドウ用Event HandlerであるmyWindowEventHandler()の内容を見てみることにしましょう。一番最初にGetEventClass()とGetEventKind()を使い、処理分岐に必要なeventClassとeventKindの両方をEvent情報(EventRef)から得ています。
この2つのパラメータを使い、第1レベルでクラス別に処理を分岐させ、さらに第2レベルでEvent種類によって分岐させます。kEventClassWindowクラスでの最初の仕事は、GetEventParameter()によりEventが発生した画像ウィンドウのWindowRef(WindowPtr)を得ることです。すべての処理は、このWindowRefを持つウィンドウに対して実行されます。
kEventWindowActivated、kEventWindowDeactivated、kEventWindowClosedの3つのCarbon Eventは、マウス選択によりウィンドウを切り替えた時(旧Activate Event同等)と、Close Boxがクリックされた時に発生します。これらの処理内容は、旧Event Modelの場合とほとんど変わりません。次のkEventWindowDrawContentは、昔で言うところのUpdate Eventに似ており、旧Event Model同様にウィンドウ内容を再描画させる必要があります。kEventClassWindowクラスのEventには、kEventWindowUpdateという種類も存在するのですが、こちらはUpdate Eventとまったく同等となります。ただし、Mac OS XではUpdate Event対応は必要ありませんので、今回はインストールしていません。
次のkEventWindowZoomは、Zoom Boxがマウスクリックされた場合に発生します。IsWindowInStandardState()で、現在のウィンドウの状態がStandardStateかUserStateかをチェックすることにより、ズームインするかズームアウトするかを判断し、ZoomWindowIdeal()を呼んでいます。このCarbon Eventが発生すると、引き続きkEventWindowDrawContentが発生するので、先んじてInvalWindowRect()でウィンドウ全領域の再描画を指示しておきます。最後にウィンドウやスクロールバーのメンテナンスルーチンを呼び出して処理は完了です。続くkEventWindowResizeCompletedは、ウィンドウのリサイズ完了時に発生するCarbon Eventです。その処理内容は、kEventWindowZoomの場合とほとんど同じです。
最後のkEventWindowBoundsChangingは、旧Event Modelには存在しなかったタイプのEventです。このCarbon Eventは、ウィンドウの矩形枠が変化している最中に連続して発生します。Mac OS Xに付属している「Internet Explorer」でウィンドウをリサイズしてみてください。ウィンドウの中身をリアルタイムで再描画しながらリサイズが実行されることが分かります(ライブリサイズ)。kEventWindowBoundsChangingは、こうした機能を実現するために用意されていると思われます。ところが、このCarbon Event、何故だかウィンドウを移動している時にも発生してしまいます。ですから、まずGetEventParameter()にkEventParamAttributesを渡し、ウィンドウサイズが変化しているときだけ処理するように制限しています。続いて、同じくGetEventParameter()にkEventParamCurrentBoundsを渡し、現状ウィンドウ矩形枠を得て、それが画像サイズより大きくならないように調整します。最後に、SetEventParameter()により調整済みの矩形枠を再度セットすることで処理は終了します。ちなみに、この処理を行わないと、Grow Boxをマウスドラッグした時に制限が利かず、画像ウィンドウはどこまでも大きくなってしまいます。
次は、kEventClassMouseクラスです。kEventMouseDownは、どこであろうともマウスクリックが起こった時に発生します。まずはConvertEventRefToEventRecord()を利用して、EventRefを旧Event ModelのEventRecord(eve)へと変換し、そのクリック位置がウィンドウ内の場合だけ、処理ルーチンであるdoContent()へと分岐させます。
旧Event Modelをそのまま用いたちょっとズルイ処理方法のようにも見えます(笑)。ウィンドウ内のマウスクリックに関しては、kEventClassWindowクラスにも対応するCarbon Eventが用意されており、本当ならばスクロールバー(コントロール)に対してもkEventClassControlクラスのHandlerを用意する方が美しいと思われます。ところが調べてみると、どうも現状のCarbonLib 1.2では、kEventClassControlクラスに属するほとんどのCarbon Eventが未実装のようなのです。色々と試してみたのですが、この処理以外にはスムーズなスクロールバー操作を行う方法を発見することができませんでした。
最後は、kEventClassKeyboardクラスです。ここでは、まずGetEventParameter()を3回使いCharCode(ASCIIコード)、KeyCode、KeyModifierを得ています。それを旧Event Modelでもキー入力を担当していたkeyinControls()ルーチンにそのまま渡しています。
この処理もkEventClassMouseクラス同様、kEventClassControlクラスが実装されていないために取った苦肉の策です。本当ならもう少し美しい処理が実現できるでしょう。このクラスは「Raw Keyboard Event」と呼ばれています。Cabon環境には、Carbon Event Modelを考慮に入れた「Multi Lingual Text Editor」という新しいテキスト入力システムが用意されています。もしアプリケーションでCarbon Eventと親和性の高いテキスト入力を実現したければ、代わりにそちらに対応したkEventClassTextInputクラスを利用することになると予想されます。
これだけのCarbon Event Handlerを実装したViewJPEGアプリケーションを、さっそくMac OS Xパブリックβ版で起動してみました。ほとんどのEvent Handlerは正常に動いてくれたのですが、kEventClassWindowクラスのkEventWindowBoundsChangingを含め、いくつかのCarbon Eventを受け取ることができませんでした。どうも、まだ未実装のようです。例えば、ウィンドウリサイズの最中にkEventWindowBoundsChangingが発生しないため、リサイズの制限が利かないといった不都合が起こります(涙)。と言うわけで、現状のMac OS X パブリックβでは、Carbon Event Modelに準拠するために、これ以上の労力を費やしても意味が無いように思えます。Appleには、なんとか早急に次なるβ版(もう正規版発表まで時間がない...)の提供を実現して欲しいものです。(それからドキュメントも!!)
今回サンプルとして利用したCarbon Event対応の「ViewJPEG v1.2」のソースファイルとプロジェクトファイルは、オッティモのサイトのライブラリに登録されています。ぜひ旧ソースと比較しながら参考にしてみてください。
[小池邦人/オッティモ]
関連リンク:オッティモ
カテゴリ:Carbon/CF, 小池邦人のプログラミング日記
Tech Info Library-Jに、WebObjectsのセキュリティに関する問題と解決策についての文書が日本語で掲載されている。WebObjectsでは、URLにセッションIDを含めた形でアクセスを行うことが行われる。そのとき、アクセス中に別のサイトに移動したときに、移動先のサイトの側で移動前のURLが、HTTP-REFERERとして得られる。それをもとにすることで、第三者にセッションの割込みが可能となってしまうと言うもの。ただし、WebObjects固有のセキュリティホールではなく、セッションIDをURLに含める形でセッション管理をしているアプリケーションサーバやあるいはアプリケーションは他にもある。なお、WebObjectsでは10分でセッション自体がタイムアウトすることもあり、この点でセキュリティホールによって偶発的に第三者によるアクセスが可能になることはまずないと考えて良いだろう。
なお、TIL-Jの文書では対処方法として、POSTメソッドを利用した手法、クッキーを使う方法、セッション回数の制限、IPアドレスを制約する方法が示されているが、完全にセキュリティを確保できる方法ではないと注記されている。
このセキュリティに関する対処方法については、MDOnlineで【倉橋浩一、じつはWebObjectsで飯食ってます】のコーナーを担当しているテクニカル・ピットの倉橋浩一氏が、自身のページで解決策などを解説しているので、詳細はそちらも参照すると良いだろう。
◇WebObjectsのページ
http://www.techpit.co.jp/WO/
関連リンク:100452JO:WebObjects: HTTP-REFERER を利用した攻撃に対する脆弱性について
カテゴリ:サーバ, Tech Info Library-J, WebObjects
サン・マイクロシステムズは、Javaでの開発ツール「Forte for Java 2.0」をリリースした。元はNetBeansとして開発されていたツールを会社ごと取得して、サンの製品としてリリースをしたものが最初のForte for Javaである。そのバージョンアップ版Ver.2.0がリリースされた。無償のCommunity Edition、75,000円のIneternet Editionがある。Community Editionはすでにダウンロードが可能になっている。対応プラットフォームは、Solaris 7およびSolaris 8 SPARC Platform Edition、Linux、Windows NT 4.0、Windows 2000となっており、Java2 SDK Ver.1.3が必要になっている。なお、Forte for Java自体もJavaで作成されていることや、プラットフォームに依存しないインストーラも用意されていることから、Mac OS X Public Betaでのインストールを試みたが、順当な方法ではインストーラと思われる最初のウインドウだけが表示され、ウインドウの中身は何も表示されないという状態で処理はストップした。そのアプリケーションは終了できるものの、インストール作業は継続されなかった。(Mac OS X Public BetaはJava2 SDK Ver.1.2.2に相当するものと思われるが、バージョンが1.3ではないためにインストーラが動作しないかどうかは不明である。)
Forte for Javaは、ビジュアルにウインドウなどのGUIを設計できる機能を含んだ統合開発ツールである。プラグインで機能を追加できるようになっている点も大きな特徴である。新しいバージョンではデバッグ機能の改良などが行われている。Communiy Editionでは、アプレットやアプリケーションの開発ができるが、Internet EditionではWebアプリケーションの開発を支援する機能や、複数のプログラマによる開発の支援もできるようになっている。
関連リンク:Forte for Java
カテゴリ:Java, Windows, UNIX
毎日コミュニケーションズより、「もっと進め!REALbasic」が出版された。著者は真紀俊男だ。価格は2,800円、B5変型判、328ページとなっている。既刊の「進め!REALbasic」の続編であり、各種のコントロールの使い方や、QuickTimeやサウンドなどのマルチメディア処理、ネットワーク通信のやり方、プラグイン作成などの高度な話題を扱っている。REALbasicでのプログラミングテクニックを向上させるというのが大きなテーマとなっているようで、初心者のステップアップには最適な書籍と言えるだろう。
関連リンク:MYCOM BOOKS
カテゴリ:雑誌、書籍, REALbasic