キーカスタマイズ機能の実装として、キーボードが押されたときに電卓上のどのボタンが押されたことにするのかをマッピングする仕組みと、その定義ファイルを実装しました。
設定ファイルにもどのマッピング定義を利用するか覚えるようにはなっていますが、まだ設定ダイアログからそれを切り替える UI が実装できていません。
それが実装できたら、いったんバージョン 1.9.0 としてリリースしようかと考えています。
用意されたキーマッピングではなくユーザーによる個別のキーカスタマイズを実現するのは、その次に続けて行う予定です。
ちなみに Windows 版（Windows 2000/XP/Vista環境）でキーボード押下時に電卓上のボタンの表示が更新されなくなっている不具合も修正してあります。
リポジトリにはコミット済みです。
現在の CoveredCalc では、最新をソースからビルドしてでも試してみたいという奇特な人はおそらくいないと思いますが、もし試すなら実行時に Keymaps というフォルダが CoveredCalc 実行ファイルや NLS フォルダと同階層に必要になります。この中に trunk/KeyMappings 下のそれぞれの OS 用のフォルダ内にあるマッピングファイル (*.cckx?) を格納しておきます。
設定ファイルにもどのマッピング定義を利用するか覚えるようにはなっていますが、まだ設定ダイアログからそれを切り替える UI が実装できていません。
それが実装できたら、いったんバージョン 1.9.0 としてリリースしようかと考えています。
用意されたキーマッピングではなくユーザーによる個別のキーカスタマイズを実現するのは、その次に続けて行う予定です。
ちなみに Windows 版（Windows 2000/XP/Vista環境）でキーボード押下時に電卓上のボタンの表示が更新されなくなっている不具合も修正してあります。
リポジトリにはコミット済みです。
現在の CoveredCalc では、最新をソースからビルドしてでも試してみたいという奇特な人はおそらくいないと思いますが、もし試すなら実行時に Keymaps というフォルダが CoveredCalc 実行ファイルや NLS フォルダと同階層に必要になります。この中に trunk/KeyMappings 下のそれぞれの OS 用のフォルダ内にあるマッピングファイル (*.cckx?) を格納しておきます。
ここ 1、2 ヶ月の間、CoveredCalc のダイアログ中の UI 部品を Windows と BeOS で共通化できないかと画策していました。例えばテキスト入力フィールドであれば、Windows なら Edit Control、BeOS なら BTextView が OS で用意されています。当然ながら Edit Control と BTextView ではそれをプログラムから操作する方法が全く異なります。そういうわけでダイアログを作るときは大まかにまとめられる処理だけ共通化して、部品を操作する部分は Windows と BeOS の 2 つ実装していました。これがまあ面倒なわけで、ダイアログの追加を避けて通ろうとしてしまう自分がいたわけです。
でも、必要な操作に関する共通のインタフェースがあればいいんじゃない？ 操作する部分は共通のインタフェースを通じて簡潔にまとめられるんじゃない？という単純な思いつきから始めたわけですが‥‥。
この度、共通化作業を断念しました。技術的に無理なわけではありません。というか明らかに可能です。そういうことをやっているプロダクトは世の中にたくさんあります。
今回、断念に至った理由はいくつかあります。
特に後ろ 2 つが大きな理由です。
共通インタフェースは現在使っている部品だけしか実装するつもりがありませんが、将来、機能拡張のために違う UI 部品を使いたくなったときに共通インタフェースから作らなければなりません。これは面倒だ。モチベーションが維持できない。機能拡張するのをやめてしまいそうだ（笑）その上、共通の部分まで複雑なんじゃ全く意味がない。
結局、ロクな設計をせずにちょこちょこ思いつきでやっていたのがよくなかったんですが、無意味に時間を使っちゃいましたね。
いろいろ勉強にはなった気もしますが。
でも、必要な操作に関する共通のインタフェースがあればいいんじゃない？ 操作する部分は共通のインタフェースを通じて簡潔にまとめられるんじゃない？という単純な思いつきから始めたわけですが‥‥。
この度、共通化作業を断念しました。技術的に無理なわけではありません。というか明らかに可能です。そういうことをやっているプロダクトは世の中にたくさんあります。
今回、断念に至った理由はいくつかあります。
- 共通化作業がなかなか終わりそうにない。
- Windows と BeOS の思想に合わせにくい。例えば Windows ではモーダルダイアログが一般的なのに対し BeOS ではモードレスダイアログであるとか、他にも BeOS ではダイアログ（というかウィンドウ）単位でスレッド（チーム）が違うとか。
- OS 間の違いを基本的に意識しない共通インタフェースを通じて操作を行う部分が、思ったより複雑でちっとも簡潔じゃなくなってきた。
- 共通インタフェースの実装がかなり複雑。
特に後ろ 2 つが大きな理由です。
共通インタフェースは現在使っている部品だけしか実装するつもりがありませんが、将来、機能拡張のために違う UI 部品を使いたくなったときに共通インタフェースから作らなければなりません。これは面倒だ。モチベーションが維持できない。機能拡張するのをやめてしまいそうだ（笑）その上、共通の部分まで複雑なんじゃ全く意味がない。
結局、ロクな設計をせずにちょこちょこ思いつきでやっていたのがよくなかったんですが、無意味に時間を使っちゃいましたね。
いろいろ勉強にはなった気もしますが。
Issue #31 を修正してチェックインしました。
それに加えて、次のソースをコミットしました。どちらも CoveredCalc 本体と同じく MIT ライセンスです。
Sources/BmpAlpha
ビットマップファイルからアルファプレーンをグレースケールビットマップとして取り出したり、グレースケールビットマップで表したアルファプレーンを指定した（アルファプレーンのない）ビットマップと結合してアルファプレーン付きビットマップを作成します。Windows のコマンドライン専用です。
Sources/BeFontSize
BeOS 版の言語ファイルを作るときの基本となるフォントのサイズを求めるためのユーティリティ。
これらのツールは基本的に自分が使うために作ったものなので、ドキュメントなどは整備していません。
BmpAlpha なんかは、中身のソースも寄せ集めです。
一応、こういうものも公開しとこうということでリポジトリに追加しました。
なお、今週末あたりに version 1.8.1 をリリースできるかなと思っています。
それに加えて、次のソースをコミットしました。どちらも CoveredCalc 本体と同じく MIT ライセンスです。
Sources/BmpAlpha
ビットマップファイルからアルファプレーンをグレースケールビットマップとして取り出したり、グレースケールビットマップで表したアルファプレーンを指定した（アルファプレーンのない）ビットマップと結合してアルファプレーン付きビットマップを作成します。Windows のコマンドライン専用です。
Sources/BeFontSize
BeOS 版の言語ファイルを作るときの基本となるフォントのサイズを求めるためのユーティリティ。
これらのツールは基本的に自分が使うために作ったものなので、ドキュメントなどは整備していません。
BmpAlpha なんかは、中身のソースも寄せ集めです。
一応、こういうものも公開しとこうということでリポジトリに追加しました。
なお、今週末あたりに version 1.8.1 をリリースできるかなと思っています。
いくつか不具合を修正しました。
Issue #33：透明・半透明部分が透明にも半透明にもならない場合がある。
変数の初期化忘れが原因でした。修正をリポジトリにはコミットしました。
バイナリリリース時期についてはなるべく早いうちにしようと思っています。
次のバイナリリリースまでに、Issue #31 も修正しようかと思っています。
Issue #32：デフォルトカバー (Adams) の透明領域定義にバグ＆カバーの作り方ドキュメントの記述ミス。
Adams の CoverDef.xml を修正しました。
リリースは上記 Issue #33 を修正したバージョンのリリースと同タイミングを予定しています。
カバーの作り方ドキュメントについては、修正版をリリースしました。
Issue #33：透明・半透明部分が透明にも半透明にもならない場合がある。
変数の初期化忘れが原因でした。修正をリポジトリにはコミットしました。
バイナリリリース時期についてはなるべく早いうちにしようと思っています。
次のバイナリリリースまでに、Issue #31 も修正しようかと思っています。
Issue #32：デフォルトカバー (Adams) の透明領域定義にバグ＆カバーの作り方ドキュメントの記述ミス。
Adams の CoverDef.xml を修正しました。
リリースは上記 Issue #33 を修正したバージョンのリリースと同タイミングを予定しています。
カバーの作り方ドキュメントについては、修正版をリリースしました。
CoveredCalc リポジトリのディレクトリ構造を少し変更しました。
これまで Sources の下に CoveredCalc のソースコードがそのままありましたが、ワンクッションおいて Sources/CoveredCalc の下に置くようにしました。今後、CoveredCalc に関するツールプログラムなども置こうと思っているためです。
それから、CoveredCalc が利用している他のオープンソースプロジェクトのライブラリや成果物など、CoveredCalc プロジェクトとしては利用するだけで積極的に変更する意志がないものを Sources/Libs の下へ移動しました。
これまで Sources の下に CoveredCalc のソースコードがそのままありましたが、ワンクッションおいて Sources/CoveredCalc の下に置くようにしました。今後、CoveredCalc に関するツールプログラムなども置こうと思っているためです。
それから、CoveredCalc が利用している他のオープンソースプロジェクトのライブラリや成果物など、CoveredCalc プロジェクトとしては利用するだけで積極的に変更する意志がないものを Sources/Libs の下へ移動しました。
Windows で「レイヤードウィンドウ」が動作する環境（Windows 2000/XP/Vista）向けの機能追加を行いました。
レイヤードウィンドウを使うとまず、システムとして効率のいい画像転送が行えるようになります。ウィンドウを移動したときに残像が残ったりいしにくくなるように思います。そして、これが今回のメインですが、ピクセル単位で半透明処理を施すことができます。
CoveredCalc では、カバー定義のビットマップ画像にアルファプレーンを持たせてあればそれを読み込んで半透明処理を行うようにしました。アルファプレーン付きのカバーであれば、デザインの一部を半透明にすることができます。（4月15日の記事にスクリーンショットあり）
また、アプリケーションの設定で、ウィンドウ全体の透明の度合いを設定できるようになる予定です。（これはまだ設定のダイアログが作成できていません）アルファプレーンを持たない以前のカバーであっても、ユーザーの設定で全体を半透明にできます。
次に、アルファプレーンを利用してカバー境界のスムージングも自動で行うようにしました。これはアルファプレーンを持たないカバーであっても利用できます（むしろそっちがターゲット）。
添付の画像の左側が境界のスムージングを行っていないもの。右側が行っているものです。微妙な違いなのですが、少しはきれいになっているのがわかるでしょうか。
スムージングの度合いはユーザーが設定で決めることができます。カバー作者が、その設定を上書きした値をカバー定義に記述することもできます。
環境設定のダイアログがまだできていないので次バージョンのリリースはまだ先ですが、これまでの作業をリポジトリにコミットしました。ソースからビルドすればレイヤードウィンドウの効果を実感できます。
レイヤードウィンドウを使うとまず、システムとして効率のいい画像転送が行えるようになります。ウィンドウを移動したときに残像が残ったりいしにくくなるように思います。そして、これが今回のメインですが、ピクセル単位で半透明処理を施すことができます。
CoveredCalc では、カバー定義のビットマップ画像にアルファプレーンを持たせてあればそれを読み込んで半透明処理を行うようにしました。アルファプレーン付きのカバーであれば、デザインの一部を半透明にすることができます。（4月15日の記事にスクリーンショットあり）
また、アプリケーションの設定で、ウィンドウ全体の透明の度合いを設定できるようになる予定です。（これはまだ設定のダイアログが作成できていません）アルファプレーンを持たない以前のカバーであっても、ユーザーの設定で全体を半透明にできます。
次に、アルファプレーンを利用してカバー境界のスムージングも自動で行うようにしました。これはアルファプレーンを持たないカバーであっても利用できます（むしろそっちがターゲット）。
添付の画像の左側が境界のスムージングを行っていないもの。右側が行っているものです。微妙な違いなのですが、少しはきれいになっているのがわかるでしょうか。
スムージングの度合いはユーザーが設定で決めることができます。カバー作者が、その設定を上書きした値をカバー定義に記述することもできます。
環境設定のダイアログがまだできていないので次バージョンのリリースはまだ先ですが、これまでの作業をリポジトリにコミットしました。ソースからビルドすればレイヤードウィンドウの効果を実感できます。