[CoveredCalc] version 1.9.0 をリリース

CoveredCalc version 1.9.0 をリリースしました。(先週土曜に^^;)
[PR]
# by hironytic | 2007-11-26 13:02 | 開発状況

[CoveredCalc] version 1.9.0

CoveredCalc version 1.9.0 リリース目前です。
ソースコードはリポジトリにコミット済みです。
大きな機能追加として、日本語キーボードだけでなく英語キーボードを選べるようになりました。

とはいえ、添付テキスト(マニュアル)の更新とか、配布イメージを作って zip に固めるとか、様々な作業が残っているのでリリースは今週末くらいでしょうか。

1.9.0 リリースのために残っている作業をまとめてみました
随時更新していきます。
[PR]
# by hironytic | 2007-11-22 10:27 | 開発状況

[CoveredCalc] キーカスタマイズ

キーカスタマイズ機能の実装として、キーボードが押されたときに電卓上のどのボタンが押されたことにするのかをマッピングする仕組みと、その定義ファイルを実装しました。
設定ファイルにもどのマッピング定義を利用するか覚えるようにはなっていますが、まだ設定ダイアログからそれを切り替える UI が実装できていません。
それが実装できたら、いったんバージョン 1.9.0 としてリリースしようかと考えています。
用意されたキーマッピングではなくユーザーによる個別のキーカスタマイズを実現するのは、その次に続けて行う予定です。

ちなみに Windows 版(Windows 2000/XP/Vista環境)でキーボード押下時に電卓上のボタンの表示が更新されなくなっている不具合も修正してあります。

リポジトリにはコミット済みです。
現在の CoveredCalc では、最新をソースからビルドしてでも試してみたいという奇特な人はおそらくいないと思いますが、もし試すなら実行時に Keymaps というフォルダが CoveredCalc 実行ファイルや NLS フォルダと同階層に必要になります。この中に trunk/KeyMappings 下のそれぞれの OS 用のフォルダ内にあるマッピングファイル (*.cckx?) を格納しておきます。
[PR]
# by hironytic | 2007-11-01 15:23 | 開発状況

メニュートリガー

a0011820_040189.jpg

図の一番上に示したのは BeOS を日本語で使っているとときどき見かける
「ファイル(F) 」というメニューです。ここで注目してほしいのは最後になんかゴミのような点があるところ。実はこの点、メニュー項目をキーで選択する際のトリガーである F の下に引かれるべき下線が別のところに出ているんです。

その下に示した 2 つのメニューは、BeOS R5 と Haiku で次のように作成した 4 つのメニュー項目を表示させてみたものです。

menuItem = new BMenuItem("Haiku BEOS beos rebirth", new BMessage('MNU1'));
menuItem->SetTrigger('B');
popupMenu->AddItem(menuItem);

menuItem = new BMenuItem("Haiku BEOS beos rebirth", new BMessage('MNU2'));
menuItem->SetTrigger('e');
popupMenu->AddItem(menuItem);

menuItem = new BMenuItem("はいく BEOS beos rebirth", new BMessage('MNU3'));
menuItem->SetTrigger('O');
popupMenu->AddItem(menuItem);

menuItem = new BMenuItem("はいく BEOS beos rebirth", new BMessage('MNU4'));
menuItem->SetTrigger('s');
popupMenu->AddItem(menuItem);

まずは BeOS R5 の方で上の 2 つのメニュー項目に注目。トリガーに大文字を指定しても小文字を指定しても、その区別なく、その文字が前から見つかったところに下線が引かれます。ところが、大文字で指定した方は実はキーでは操作できません。いや、もしかしたらキーに大文字が割り当てられている Keymap で試せば操作できるのかもしれませんが、そこまでは試していません。通常は小文字が割り当てられていると思うので、基本的にトリガーは小文字で指定すると考えていいでしょう。

次に BeOS R5 の残り 2 つのメニュー項目に注目。こっちは O と s を設定してあるのにとんでもないところに下線が引かれてます。どうもこれ、UTF-8 のバイト数で割り出したインデックスを文字数として計算しているようなのです。
UTF-8では「はいく BEOS beos rebirth」は「E3 81 AF E3 81 84 E3 81 8F 20 42 45 4F 53 20 62 65 6F 73 20 72 65 62 69 72 74 68」というコード列になります。「は」が「E3 81 AF」という 3 バイトで表されるわけです。
このコード列から「O」(4F あるいは 6F)を探すと前から 13 バイト目に見つかります。これは文字数で言えば前から 7 文字目になるのですが、実際に下線が引かれているのは 13 文字目ですね。マルチバイト圏のことが考慮されていないバグでしょう。

さて、このバグ、Haiku では治っているのかな~?と思って実験してみたのが図の一番下のもの。
Haiku の方でも注目して欲しいのが上の 2 つ。BeOS R5 と異なり、トリガーに指定した文字の大文字・小文字を区別して下線が引かれています。これは微妙に困ります。例えば「File」とメニューに「f」のトリガーを与える場合を考えてください。BeOS R5 では小文字を指定しないと実質動かないのですが、Haiku で小文字を指定すると(「f」はラベルに見つからないので)トリガーの下線が引かれません。BeOS R5 と Haiku の両方でうまく行くようなプログラムは作れないのです。ちなみに、Haiku、このバージョンではキーによるトリガー操作は大文字も小文字も効きませんでした。

それはそうと、残り 2 つのメニュー項目が今回の実験のメインです。結論から言うと、BeOS R5 と全く同じ不具合を持ってます。そんなところは再現しなくていいんだってば。

Haiku の BMenuItem のソースを見てみた感じでは、strchr で得たインデックスを BFont::GetEscapements() に渡しているのが悪いみたい。GetEscapements() の第 2 引数はバイト数じゃなくて文字数ですからね。
あと、ソースレベルでしか確認してませんが、BMenuItem::SetTrigger() を呼んだあとで BMenuItem::SetLabel() でラベルを変えてもトリガーの下線位置が更新されないように見えます。これもおかしいんじゃないのかな?

ある程度予想はしていたことですが Haiku も細かいところで完成度がまだまだのようです。

(2007-09-29 13:47追記
みなさんの励ましと Google 言語ツールのおかげで、なんとか Haiku プロジェクトへバグ報告しました。
http://dev.haiku-os.org/ticket/1506
)
[PR]
# by hironytic | 2007-09-21 00:46 | 情報

[CoveredCalc] ダイアログコンポーネントの共通化 - 断念

ここ 1、2 ヶ月の間、CoveredCalc のダイアログ中の UI 部品を Windows と BeOS で共通化できないかと画策していました。例えばテキスト入力フィールドであれば、Windows なら Edit Control、BeOS なら BTextView が OS で用意されています。当然ながら Edit Control と BTextView ではそれをプログラムから操作する方法が全く異なります。そういうわけでダイアログを作るときは大まかにまとめられる処理だけ共通化して、部品を操作する部分は Windows と BeOS の 2 つ実装していました。これがまあ面倒なわけで、ダイアログの追加を避けて通ろうとしてしまう自分がいたわけです。
でも、必要な操作に関する共通のインタフェースがあればいいんじゃない? 操作する部分は共通のインタフェースを通じて簡潔にまとめられるんじゃない?という単純な思いつきから始めたわけですが‥‥。

この度、共通化作業を断念しました。技術的に無理なわけではありません。というか明らかに可能です。そういうことをやっているプロダクトは世の中にたくさんあります。
今回、断念に至った理由はいくつかあります。

  • 共通化作業がなかなか終わりそうにない。
  • Windows と BeOS の思想に合わせにくい。例えば Windows ではモーダルダイアログが一般的なのに対し BeOS ではモードレスダイアログであるとか、他にも BeOS ではダイアログ(というかウィンドウ)単位でスレッド(チーム)が違うとか。
  • OS 間の違いを基本的に意識しない共通インタフェースを通じて操作を行う部分が、思ったより複雑でちっとも簡潔じゃなくなってきた。
  • 共通インタフェースの実装がかなり複雑。

特に後ろ 2 つが大きな理由です。
共通インタフェースは現在使っている部品だけしか実装するつもりがありませんが、将来、機能拡張のために違う UI 部品を使いたくなったときに共通インタフェースから作らなければなりません。これは面倒だ。モチベーションが維持できない。機能拡張するのをやめてしまいそうだ(笑)その上、共通の部分まで複雑なんじゃ全く意味がない。

結局、ロクな設計をせずにちょこちょこ思いつきでやっていたのがよくなかったんですが、無意味に時間を使っちゃいましたね。
いろいろ勉強にはなった気もしますが。
[PR]
# by hironytic | 2007-09-19 22:35 | 開発状況

[CoveredCalc] 不具合修正 + ツール類のソースをコミット

Issue #31 を修正してチェックインしました。

それに加えて、次のソースをコミットしました。どちらも CoveredCalc 本体と同じく MIT ライセンスです。

Sources/BmpAlpha
ビットマップファイルからアルファプレーンをグレースケールビットマップとして取り出したり、グレースケールビットマップで表したアルファプレーンを指定した(アルファプレーンのない)ビットマップと結合してアルファプレーン付きビットマップを作成します。Windows のコマンドライン専用です。

Sources/BeFontSize
BeOS 版の言語ファイルを作るときの基本となるフォントのサイズを求めるためのユーティリティ。

これらのツールは基本的に自分が使うために作ったものなので、ドキュメントなどは整備していません。
BmpAlpha なんかは、中身のソースも寄せ集めです。
一応、こういうものも公開しとこうということでリポジトリに追加しました。

なお、今週末あたりに version 1.8.1 をリリースできるかなと思っています。
[PR]
# by hironytic | 2007-06-25 20:54 | 開発状況

[CoveredCalc] 不具合の修正

いくつか不具合を修正しました。

Issue #33:透明・半透明部分が透明にも半透明にもならない場合がある。
変数の初期化忘れが原因でした。修正をリポジトリにはコミットしました。
バイナリリリース時期についてはなるべく早いうちにしようと思っています。
次のバイナリリリースまでに、Issue #31 も修正しようかと思っています。

Issue #32:デフォルトカバー (Adams) の透明領域定義にバグ&カバーの作り方ドキュメントの記述ミス。
Adams の CoverDef.xml を修正しました。
リリースは上記 Issue #33 を修正したバージョンのリリースと同タイミングを予定しています。
カバーの作り方ドキュメントについては、修正版をリリースしました。
[PR]
# by hironytic | 2007-06-22 22:54 | 開発状況

[CoveredCalc] リポジトリのディレクトリ構造を少し変更

CoveredCalc リポジトリのディレクトリ構造を少し変更しました。
これまで Sources の下に CoveredCalc のソースコードがそのままありましたが、ワンクッションおいて Sources/CoveredCalc の下に置くようにしました。今後、CoveredCalc に関するツールプログラムなども置こうと思っているためです。
それから、CoveredCalc が利用している他のオープンソースプロジェクトのライブラリや成果物など、CoveredCalc プロジェクトとしては利用するだけで積極的に変更する意志がないものを Sources/Libs の下へ移動しました。
[PR]
# by hironytic | 2007-06-17 01:17 | 開発状況

[CoveredCalc] version 1.8.0 をリリース

CoveredCalc version 1.8.0 をリリースしました。
プロジェクトページ からダウンロードできます。
いま、ひろんの倉庫の方を更新しているヒマがないので、そちらはまた後で。
[PR]
# by hironytic | 2007-06-02 11:10 | 開発状況

[CoveredCalc for Windows] レイヤードウィンドウ関連の修正をコミット

Windows で「レイヤードウィンドウ」が動作する環境(Windows 2000/XP/Vista)向けの機能追加を行いました。
レイヤードウィンドウを使うとまず、システムとして効率のいい画像転送が行えるようになります。ウィンドウを移動したときに残像が残ったりいしにくくなるように思います。そして、これが今回のメインですが、ピクセル単位で半透明処理を施すことができます。

CoveredCalc では、カバー定義のビットマップ画像にアルファプレーンを持たせてあればそれを読み込んで半透明処理を行うようにしました。アルファプレーン付きのカバーであれば、デザインの一部を半透明にすることができます。(4月15日の記事にスクリーンショットあり
また、アプリケーションの設定で、ウィンドウ全体の透明の度合いを設定できるようになる予定です。(これはまだ設定のダイアログが作成できていません)アルファプレーンを持たない以前のカバーであっても、ユーザーの設定で全体を半透明にできます。

a0011820_16212045.jpg次に、アルファプレーンを利用してカバー境界のスムージングも自動で行うようにしました。これはアルファプレーンを持たないカバーであっても利用できます(むしろそっちがターゲット)。
添付の画像の左側が境界のスムージングを行っていないもの。右側が行っているものです。微妙な違いなのですが、少しはきれいになっているのがわかるでしょうか。
スムージングの度合いはユーザーが設定で決めることができます。カバー作者が、その設定を上書きした値をカバー定義に記述することもできます。

環境設定のダイアログがまだできていないので次バージョンのリリースはまだ先ですが、これまでの作業をリポジトリにコミットしました。ソースからビルドすればレイヤードウィンドウの効果を実感できます。
[PR]
# by hironytic | 2007-05-20 16:24 | 開発状況