diary

相変わらず、BBSのスパム書き込みがひどい。
とりあえず、BBS CGIを一部書き直して、スパムメッセージをまとめて消せるように変更しました。
ついでに、HTML4.01 からXHTML1.0 へ仕様も変更。

ほとんどが海外からのスパムなので、書き込み文字が英数字だけなら、はじくっていう仕組みにしてもいいかもしれない。

　最近は、遊びでCADソフトを作っているんだが、そのデータ構造は非常に興味深い。当初は四分木がいいと思っていたんだが、これは領域のある図を管理するのにはあまり適さない。

　現在のCADソフトでのデータ構造は、以下のようなものが使われるようだ。
・R木
・GBD木
　どちらも、あまりデータ構造の教科書には出てこない方式だが、空間インデックスという1つのカテゴリーとして研究が進んでいるようである。空間を階層的な部分領域に分割して、効率的に探索を行うという基本方針は、一般的な木構造と同様である。

　R木は rectangle(矩形)の頭文字 Rからつけられた名前で、図をかこむ最小外接矩形(Minimum Bouding Rectangle(MBR))をもとに空間を分割し木を構成する。木を構成する各ノードは、ノード下に含まれるすべての図形のMBRを包含したMBRを持つ。木はB木と同様に、平衡木であり効率的に探索を行うことができる。
　領域の分割方法には色々な方法があり、その方法により、
・R+木,
・R*木,
・ヒルベルトR木
などがある。

　GBD木は、さらに資料は少なかったが、四分木とR木を組み合わせたような構造であり、より複雑である。
　対象平面を、垂直に分割、水平に分割を繰り返し、正方形と、2：1の長方形の領域に分割していく。分割された各領域は「領域式」という式で表し、右上方向を大きいとするルールにより、大小比較をすることができる。
　GBD木は、B+木のような構造で、すべてのデータ(図形)は最下層の葉ノードに格納される。各葉ノードは1つの領域を持ち領域式をもとにソートされている。
　図形追加時には、図形の中心点から領域を求めて、対応する領域式を持つ葉ノードへ追加される。
　また、各ノードは、ノード以下すべての図を内包した最小外接矩形(MBR)を持つ。図は中心点のみで葉ノードに追加されるためMBRは必ずしも対応する領域式の領域内に収まるわけではない。
　探索はR木同様にMBRをもとに行うが、挿入・削除をより高速に行えるとのこと。

　しかし、一般的に使われるソフトでも、つきつめるとデータ構造はどれも複雑である。テキストエディタも、お遊びでは1行を1つの文字列、1つのノードとして、双方向循環リストなどで作るが、本格的なエディタではB木などが使われている。お遊びのCADソフト作りでは、どのデータ構造にしようか悩ましいところである。

いやー。全然更新してません。
たまには何かさわろうかと、とりあえず旧バージョンのまま放置していた Movable Type を消して、Word Pressに移行してみました。とりあえず使ってみた感じは、なかなか快適です。とくに編集画面は、JavaScriptをうまく使っていて、非常に使いやすいです。

最近は、GTK を勉強中。日本語の資料は少ないけど、設計はすごく良くできてる。
WindowsとLinuxどちらでも動くみたいだし、使いこなせればなかなか面白そうだ。

P.S.
そろそろ Lacoocan も飽きてきたなぁ。結局レンタルサーバーはできることが少ない。そろそろ自宅サーバも考えたい。

　これまで、ずっとサイトをHTML4.01で作成していたが、この度思い切ってXHTML1.0に修正してみた(BBS以外)。とはいってもヘッダ部と一部のタグを修正するくらいで、大きな変更はしなくても簡単に変更することができた。
　しかし、何のメリットがあったのかは、いまいち良くわからない(^-^;
　HTMLよりも書き方が厳格なぶんだけ、誰が書いてもあるていど書き方が統一になる。というのはメリットかな。あと一般的なXMLを扱うプログラムで処理できるようになるので、プログラムから入出力するには便利になるのだろうか。ここらへんはまだ勉強してみないと分らない。
まぁ、HTMLに比べて特別書くのが面倒ということもなく、覚えてしまえば普通に書けるので、XMLの勉強の意味もこめてこれからはXHTMLで作ろうかなと思っています。

　6月30日。Wheel Ball ver2.00(正式版)のリリース、iアプリ Mobile関数電卓の初公開。そして、著作者名・サイト名変更と、サイト移行を行いました。
　Wheel Ball ver1.5xβは安定しているようなので、そのまま ver2.00 正式版としてリリースしました。ver1.0x で安定して使えているかたも、今後は ver2.00を使っていただくことをお勧めします。
　初公開の iアプリ Mobile関数電卓は、もともと自分ように作ったアプリですが、もしかしたら使っていただける方がいるかもしれないので公開してみました。開発継続するかはまだ未定です。他にも自分用に作った iアプリがたくさんあるので、また時間があるときにでも追加公開したいと思っています。
　ハンドル Jesus は、若いころに適当につけた名前ですが、最近は歳をとったせいか恥ずかしくなってきたので、普通に本名を名乗ることにしました。それに伴いサイト名とソフトの著作者名を変更しました。
　サイトの移行は、Perl の勉強を続けているうちに、もっと自作のCGIにこだわってみたいと思うようになったので、CGIに対する機能が豊富な @nifty LaCoocan へ移行してみました。今後、BBSのCGIなど少しこだわったものに改良していこうかと思っています。

　本日、Wheel Ball 1.54βを公開しました。正式版にしようか迷ったのですが、もう一回だけβで出すことにしました。僕自身ずっとVistaで使っているのですが、今のところ不具合はでていません。あれだけ大きな変更をしたのにバグが無いのが逆に気持ち悪いので、もう少し様子見です。（なんじゃそりゃ。）
　今回のバージョンアップは、垂直・水平ホイール同時使用制限のちょっとした改良のみです。
　前バージョンまでは、ホイール方向を片方向に制限している時に、違う方向に一定の移動量があればホイール方向の切替や、制限の解除をしていました。
　今バージョンでは移動量だけでなく、縦方向と横方向の移動量の比率もチェックするようにしました。それによって、高速にスクロールさせているときにでも、意図せずホイール方向が切り替わることがなくなりました。また、低速にホイールしているときには、今までよりも少ない移動量でホイール方向を切り替えることができるようになりました。
　細かな調整をユーザー側でできるようにするかは悩んでいますが、設定ダイアログのスペースが無いので、特に要望がなければこのままにしたいと思っています。
　あとは、マイクロソフトから、Visual C++ 2005 SP1 のランタイムライブラリが再頒布されはじめたので、要ランタイム版を準備しました。需要あるのかな…

　とりあえず、前回の日記に書いた垂直・水平ホイール同時使用の制限を Wheel Ball ver1.53βで実装してみました。本当ならば、大きな移動というのを、どのくらいにするか選択できるようにするべきだと思ったのですが、とりあえずは固定値での実装です。（現在は256ミリ秒で、200ピクセルの移動で大きな移動としています。根拠は特に無し。）
　いかんせん対応アプリが少ないので使い心地を調べるのも難しいのですが、何となくうまく動いているようです。これでつけたい機能は一通り実装したので、あとは安定化・バグ取り・微調整を数回重ねて正式版として公開したいと思っています。

前回のブログで書いたとおり、Windows Vistaの水平ホイールに対応したWheel Ball ver1.51βをリリースしました。
さて水平ホイールですが、ほとんど対応アプリケーションが無い現状で、あまり意味ないとも思ったのですが、身近なところでFirefoxが対応しているみたいだし、今はβ版なので、とりあえず試験的に実装してみました。最終的にどうするかは、まだ未定です。
1つ今悩んでいる問題点として、垂直・水平ホイールを両方使用する場合、例えば垂直ホイールだけをしたい。と思ったときに、縦方向にマウスを移動しても、少しだけ横方向へも移動してしまいます。その小さな移動が蓄積して、意図せず水平ホイールしてしまうということがあります。スクロールの時、縦方向にだけスクロールしたいことなどよくあります。
マイクロソフトがチルトホイールを搭載したときに、ボールにしなかったのは、そういった理由かと思われます。ボールだと縦のみ、横のみという回転がしにくいからです。
さてWheel Ballは、主にトラックボールからの使用を前提に作られているために、何らかの対策を考えなくてはいけません。
すぐに思い浮かんだアイデアは、垂直・水平ホイールを排他利用することです。最初に垂直ホイールを行ったら、水平ホイールはしない。最初に水平ホイールをしたら垂直ホイールはしない。とすることで同時使用をできなくします。でも同時に使いたいとき困るんですよね。
次に考えたのが、マウスボタンや、キーボードキーのスイッチを複数用意して、垂直ホイール専用のスイッチ、水平ホイール専用のスイッチ、両方のスイッチと定義していく方法です。これはなかなか良さそうですが、スイッチの実装が複雑になりそうな気もする。そもそもマウスの限られたボタンをいくつも占有したくない。
最後に、これはまだ、しっかりとしたイメージが浮かばないのですが、最初に移動した方向へホイールを開始して、その後に最初と違う方向へ大きな移動があったときのみ同時ホイールとする。一度同時ホイールになったあとは、双方向に自由にホイールできるようにする。これが一番良いかなと思っているのですが、大きな移動というのを、どのくらいにするのか、どういった判定のしかたにするべきかなどは、まだ悩んでいるところです。
みなさんの良いアイデアがあれば、ぜひ教えてください。
また、水平ホイールは正式にはVistaのみの対応ですが、XPのFirefoxでも問題なく動いているようです。今後対応アプリケーションが増えることを願うばかりです。
さて、この度は気分転換にアイコンも変更しました。
新アイコンは、以下のサイトを参考にさせていただき gimpで描画しました。
GIMP2を使おう（http://www.geocities.jp/gimproject/gimp2.0.html）
またアイコン形式の作成には、以下のツールを利用させていただきました。
icoFX（http://icofx.xhost.ro/）
サイトとツールの作者様に感謝です。
遊び心で、Vistaからの特大アイコン 256*256 にも対応したのですが、ちょっとファイルサイズが大きくなってしまったので、次バージョンでは 48*48 くらいまでにするかもしれません。

　先日、Windows VistaをセカンドPCにインストールしました。（Vista Ultimate 32bit DSP版）すぐにXPから乗り換える気はないのですが、気になる点がいくつかあったため試験的に入れてみました。
　Vistaを使ってみてすぐに感じたのは、「思ったより変わっていないな」ということです。設定ダイアログなども、まったくXPとデザインが変わっていないものも多くて、身構えていたほど操作に戸惑うことはありませんでした。
　ただ、スタートメニューのすべてのプログラムの表示方法は、個人的にかなり納得がいきません。これまでの右側にポップアップする方式のほうが、使いやすかったと思うのですが、みなさんはどうでしょうか？
　つづいて、Wheel Ballが正常に動作するか。これは事前にBBSで動作報告を書き込んでもらっていたので、わかってはいたものの、とりあえず正常に動いて一安心です。
　そして最後に、一番気になっていたのが Vistaから新たに搭載された
「水平ホイール」です。
　これまでもチルトホイール等で水平方向のホイールを搭載しているマウスなどありましたが、Windowsそのものには水平ホイールを通知する機能が無かったために、マウスドライバ側から直接水平スクロールさせていました。そのため、正常に動かないソフトがありましたし、アプリ側で独自に水平ホイールにたいする処理を書くことは不可能でした。
　Vistaからは、OSに水平ホイールという機能が追加され、WM_MOUSEHWHEELというメッセージでアプリケーションに通知されるようになりました。これはぜひ、Wheel Ballに搭載してみたい。
　さっそくWM_MOUSEHWHEELメッセージを送る試験プログラムを作成して、Vistaのアプリに送ってみました。とりあえずInternet Explorer 7を立ち上げて水平スクロールバーを表示してメッセージを送ってみたところ・・・あれスクロールしない。作るの間違えたか？と今度は、メモ帳に対して送ってみたら、メモ帳では水平スクロールできました。
いくつかVista上で水平ホイールを試してみた結果は以下のとおり
（○：動いた。×：動かない）
○ メモ帳
○ エクスプローラ
○ Windows メール
× Internet Explorer
× ワードパッド
× ペイント
　せめて、Internet Explorer くらい当たり前のように対応しているのかと思っていたので期待はずれでした。
　今回の、水平ホイール、新機能とはいっても、WM_MOUSEHWHEEL という新たな値が定義されただけなので、メッセージを送るというかたちでならXPでも動きます。ただ、SendInputというマウス入力APIからの通知では、メッセージを受け取ることはできませんでした。
　Wheel Ballでも近いうちに水平ホイールへ対応したいと思っていますが、使えるアプリが少ないので、当分はあまり意味が無さそうですね。

　久しぶりにWheel Ballのバージョンアップをしました。
　追加の機能はキーボードへの対応だけですが、開発環境をVisual Studio 2005に変更して、内部ロジックもかなり修正しました。
　このバージョンが安定したら Windows Vista版を作る予定なので、その前にどうしてもVisual Studio 2005への変更が必要でした。（さすがにVisual C++ 6.0でVista用アプリを作るわけにもいくまい。）
　ただ、あまりに修正しすぎたのと、久しぶりのバージョンアップなので、大きなバグが残っているかもしれません。しばらくβ版で様子を見たいと思います。不具合あったらご連絡ください。
　今回メインのキーボードへの対応は、ずっと前からやりたいと思っていたのですが、どういう形で実装するか悩んで保留になっていました。マウスボタンとの排他利用だと簡単なんですが、それだとおもしろくないので、同時に使えてかつ両方とも自然に使えるようにあれこれ考えて遅くなりました。
　なんとか実装したキーボードですが、実際に使用するときに、どのキーを使うのをディフォルトにするべきかも悩みました。Shift, Ctrl, Alt キーは、どれもよく使うキーで無効にするのは難しい。無効にせずにホイールイベントを発生させると、「Shift＋ホイール」はほとんどのブラウザで「戻る・進む」だし、「Ctrl＋ホイール」は「拡大・縮小」に割り当てられてるので難しい。「Alt＋ホイール」は大丈夫っぽいですが、押すとメニューにフォーカスが移ってしまうので、そのまま使うのは無理。
　となると、あまり使わない日本語入力関連のキーを思いつくのですが、英数キーや、ひらがなキー、半角/全角キーは、キーイベント発生のしかたが特殊でうまく利用できません。唯一普通に使えたのが、変換キーと、無変換キーでした。ただ101キーボードとか使っている人は使えないんですよね。ちなみに僕のキーボードWinキーがついていないのでWinキーのテストもできないということで却下しました。
　色々考えた末に、「キーボードをスイッチに使用する」はオフに、使用するときはAltキーを無効にして使うのをディフォルトにしました。Shift, Ctrl, Alt の中ではAltが一番使用頻度が低いので、とりあえず使ってみるのには無効でもいいかなと。（Alt＋Tabとかおかしくなるので、やはり無理はある。。）
　あとは使う人の環境にあわせて、使えそうなキーを探して欲しいと思います。苦労して作ったわりにはあまり使われないかも知れませんね^-^; マウスしか使わないときには、一切キーボードのフックは働かないので、これまで通り使う場合でも重たくなることはないです。
　キーボードキーについては、まだ試作段階なので、将来的に大きく変更するかもしれません。
　次はVistaです。先日とりあえずVistaをセカンドマシンにインストールしてみたのですが、僕のマシンだと性能的にギリギリなのかもしれない。やや重たいです。XPでも重たいVisual Studio 2005がまともに動くだろうか。