カテゴリ:構想( 8 )

[CoveredCalc] ショートカットキー

Haiku-Development ML の方でショートカットキーの議論がされてる
CoveredCalc のキーカスタマイズはショートカットキーとはちょっと違うけど、将来 Haiku のショートカットキーの実装方法が変わったら、CoveredCalc BeOS 版のキーカスタマイズの考え方も変わるかもしれない。
[PR]
by hironytic | 2008-02-04 21:33 | 構想

[CoveredCalc] キーコードからキー名称取得 2

BeOS 版のキー名称取得方法として
キーマッピングでマップされた文字をとったりすると小文字ばっかりとれてしまいそうだし、
とか書いちゃいましたが、小文字がとれたら大文字にすればいいだけでこれに関しては問題ありません。
ファンクションキーとかテンキーが取れないのが問題。

なので、ファンクションキー、テンキーなどはソフトに添付した XML ファイルに定義を書いておいて、それから漏れたものはキーマップから取得(ついでに大文字化)、それでもとれなかったら "keycode-xx" というのが良さそうです。

ということで、再びまとめなおすと、

1. ソフトに添付した XML ファイルに定義があればそのキー名称を使う。
2. (Windowsの場合) GetKeyNameText() API を使ってキー名称を取得。
2. (BeOS/ZETAの場合)キーマップからモディファイアなしの文字を取得して大文字化。
3. それでもダメなら "keycode-xx"。
[PR]
by hironytic | 2008-02-04 20:23 | 構想

[CoveredCalc] キーコードからキー名称取得

ここんとこほとんど開発がすすんでいませんが、とりあえずキーコードからのキー名称取得の調査段階にいます。
Windows 版の場合は次のようにしてやればいいかなーと考えています。
DWORD virtKey; // ここに仮想キーコードが入っている
TCHAR buf[128];
UINT scanCode = MapVirtualKey(virtKey, MAPVK_VK_TO_VSC);
if (0 != scanCode)
{
    if (0 != GetKeyNameText(scanCode << 16, buf, sizeof(buf)))
    {
        // キー名が取得できた。buf が文字列。
        return;
    }
}

// それでもとれなければキーコードをそのまま表示することにする
// virtKey を "keycode-2f" みたいに
sprintf(buf, "keycode-%02x", virtKey);


BeOS 版の方は問題で、たぶん、キーコードからキー名称を取得するような API はないですね。
キーマッピングでマップされた文字をとったりすると小文字ばっかりとれてしまいそうだし、ファンクションキーとかテンキーとかは思ったようにとれないし。
ということで BeOS 版の方はキーコードとキー名称の対応表みたいなのを XML ファイルで持っておこうかなとか思ってます。これなら楽ちん。

Windows 版の方も同じ XML ファイルを持っておいてもいいですね。特に定義は追加しないで。デフォルトの表記じゃ区別できないキーボードとかそういうのを使ってる人がカスタマイズする最後の手段を残しておくという意味しかありませんが。

ということでまとめると

1. ソフトに添付した XML ファイルに定義があればそのキー名称を使う。
2. (Windowsの場合のみ) GetKeyNameText() API を使ってキー名称を取得。
3. それでもダメなら "keycode-xx"。
[PR]
by hironytic | 2008-01-29 23:30 | 構想

[CoveredCalc for ZETA] ロケールキット対応

引っ越し終りました。
まだゴタゴタしてますが。

1.3.0 をリリースしたときの記事 に Koki さんが ZETA のロケールキットへの対応をコメント欄で要望されていました。
これに対して、ぼくは
多言語対応はロケールキットも含めて検討中です。
今のところの構想では、まず(ロケールキットと別に)言語を切り替えられる仕組みを作って、ZETAの場合だけ、「ロケールキットを使う」という設定を後から追加しようかなと思っています。
まだZETAネイティブでビルドしたことがないので、ロケールキットはそれができてからですね。(^^;

と返事をしました。

しかし、逆に、まずロケールキットに対応してから ZETA 以外のために言語を切り替えられる仕組みを作る方が、とりあえず他の言語で動くものを作るという点ではいいように思えたので前言撤回します。
多言語対応に関してはまず ZETA のロケールキット対応を行います。
英語、スペイン語への翻訳を Koki さんに行ってもらえるようなので、ぜひお願いしようと思います。
というか、そうなるとデフォルトの言語を英語にした方がいいと思うので、もう少し作業が進んだら、翻訳をお願いするつもりです。よろしくお願いします。> Koki さん
[PR]
by hironytic | 2005-10-27 11:12 | 構想

[CoveredCalc] 「=」キーの入力と PPC 版 (BeOS) について

KiMさんのところで「=」キーの入力と PPC 版について突っ込まれています。

なーんも考えずに、ただ「=」だから [=] というようにしたんですが、言われてみれば [Enter] キーで「=」というのが普通ですね。
というか、テンキーを使っていたら、[Enter] を押してしまいますよね。
テンキーの付いてないキーボードを使っていたので、そういうところが見えませんでした。一般的でないものを使うことのデメリットです。
修正は簡単だと思うので次のバージョンでは [Enter] でも反応するようにします。
キー入力についてはカスタマイズできるようにしたいと思っていて、それを実現するための仕掛けも作ってあるんですが、カスタマイズを実現させるのには時間がかかりそうなので。

PPC 版については、ビルド環境を持ってないので少なくともぼくからのバイナリリリースはできそうにないです。
作りかけの部分はまだ山ほどあるんですが、落ち着いてきたので、そろそろソース公開しようかな…。
もともとソース公開も考えて作っていたんですけど、いろいろ考えることがあって。
もうちょっと考えてみます。(単にだらだらしてるだけとも言う)


追記:自分でも気づいてなかったのですが、Windows 版では、[Enter] で「=」が入力できました。BeOS 版でその部分を実装するときに抜けてしまったみたいです。バグですね…。
[PR]
by hironytic | 2005-05-11 14:23 | 構想

[CoveredCalc] 非アクティブカバー

CoveredCalc のカバーにはウィンドウが非アクティブなとき(つまり入力フォーカスを持たないとき)の画像を用意できます。この仕様は、昔作った K-Jofol のスキンが使えるCDプレイヤー K-os Player から来ているもので、つまりは K-Jofol がそういう仕様だったことに由来します。
要するに自分で考えて作った仕様ではなくて、ただ成り行きでそうなったという仕様です。ところが、これが非常にやっかいなものだったということに、今さらながら気づいています。

ここのところ、Displator と Adams のカバーを作りました。どちらも非アクティブ画像を持っています。
Displator はキー入力部を持たない関係で、キーボードからの入力を受け付ける状態かどうかが重要なのでつけました。
Adams の方は、デフォルトカバーということで、とりあえず全機能を使おうかと思い、つけました。
現状、「こりゃ問題だな」と感じたのは、ディスプレイ部分のフォント画像に非アクティブ画像が使えないことです。Adams のように非アクティブ時に彩度を落とすと、フォントだけがはっきりして浮いてしまいます。(そこで、Adams ではディスプレイ部分だけ彩度を落としていません)

さらに、今後実装する予定のあるホバー機能(ボタンの上にマウスカーソルをもっていくとボタンが光った画像などに変わること)でもこの問題が出てきます。非アクティブ状態でもマウスカーソルは移動できますからね。
それから、2進数、8進数、16進数表示への対応も実装予定にありますが、現在の進数を切り替える UI に今のところ、それぞれのボタンを用意して現在選択されているボタンだけの色が変わるというような、ラジオボタン的なものを考えています。しかし、そこでも、ON、OFF それぞれの状態にアクティブ時と非アクティブ時の画像が必要になります。

まいったな。でも、Displator のように必要性はあるわけで、機能をなくすわけにもいかないので…。
[PR]
by hironytic | 2005-04-07 18:44 | 構想

[CoveredCalc] なんちゃってDOM

CoveredCalc では、カバー定義と設定ファイルに XML を利用しています。
XML にすると汎用のパーサが使えたり、拡張がしやすかったりというメリットがあるからです。(と過去に自分が書いてます

汎用の XML パーサには、SAX と DOM の 2 種類があります。SAX はタグなどが見つかるたびに順に通知されるイベント型。お手軽で簡単な解析に向いています。DOM は XML 文書を解析したあとツリー構造をそのままオブジェクトにマッピングして、文書内のどこでも参照できるような高機能なものです。さらに、そのツリーに変更を加えて、XML 文書として書き出すこともできます。(SAX は読み込みしかしない)
作り始めた当初は、そんなに複雑にするつもりはなかったので、SAX パーサでお手軽にやればいいかと思っていました。でも、作ってみると(特にカバー定義が)思ったより複雑になってしまいました。SAX パーサからのイベントハンドリングは妙に複雑です。
さらに設定をファイルに落とすときに XML 文書を自分で書き出さなくてはいけないので割と面倒です。
これはカバー定義と設定項目の拡張を妨げる原因になっています。やる気がなくなるんだもん。

このあたりで、SAX パーサをやめて DOM パーサに変更しようかと思いました。
現在使っている Expat を採用した背景には、BeOS で使えたことと、ライセンスが希望に合うことがあります。(と、これもまた過去に書いてます
一方、DOM パーサとして有名なのは Xerces(C++ で利用するので Xerces C++)です(なお、Xerces は SAX パーサの機能も持っています)。最新バージョンは 2.6.0 のようですが、BeOS にも 2.4.0 がポーティングされているようです。ライセンスも Apache Software License 2.0 なので問題はないでしょう。
ただし、この BeOS ポートでは共有ライブラリ(.so)のバイナリしかありません。自分でビルドすればスタティックライブラリ(.a)も得られるんでしょうか。共有ライブラリでも構わない(むしろユーザからすればそっちの方がいい?)んですが、シンプルなファイル構成にしたいのと、ユーザの環境によってライブラリが異なっていると動きが変わったりするのを避けたいんです。

でも、そこまでしてフルスペックの DOM パーサがいるか?という気もしてきました。
当然、DOM パーサは処理も重いし、サイズも大きくなります。
Expat がうまく動いてくれていることはわかっているわけですから、解析にはこのまま SAX パーサを使うことにして、DOM ツリーの管理部分とツリーを XML に出力する部分だけを自力で作ればいいんじゃないかと。
別にフルスペック必要なわけではないので、自分が使うような機能だけを実装した「なんちゃってDOM」でいいんです。DOM の仕様を満たす必要なんか全然ありませんしね。

でも、これはそれなりに時間がかかりそうなので、他の機能を実装しながら、平行して進めようかなと思っています。パーサ自体は独立してるので、Subversion でブランチ切って作業してれば、最新ソースへのマージも楽かな~。
[PR]
by hironytic | 2005-02-01 01:02 | 構想

[CoveredCalc] 演算子の直後に =

2 人目の子供ができてから、家が戦場になって開発が全く進みません(汗)

それはそうと、電卓で演算子のボタンを押した直後に = を押すとどうなるか知ってますか?
つまり、「3 + =」というように入力するわけです。
手元にあった 3 つの電卓で試してみました。

(1) 高校くらいからプログラミングのお供として使っているお気に入り電卓
「3 + =」 → 「3.」
「3 - =」 → 「3.」
「3 × =」 → 「9.」
「3 ÷ =」 → 「1.」
加減算については表示は変わりませんが、乗除算では[×]、[÷]を入力した時点で表示されているものがそのまま入力されたと見なしているようです。どうも中途半端な感じで納得いきません。

(2) 100円ショップで購入した電卓(会社で試したので正確な数字を覚えてないのですが)
「3 + =」 → 「3.」
「3 - =」 → 「-3.」
「3 × =」 → 「9.」
「3 ÷ =」 → なにやらややこしそうな小数
全く法則がわかりません…。割り算については、その後、「× 3 =」とすると、3 に近い数字が出るので、3 に近い数字で割られたようです。

(3) Windows の Microsoft 謹製(?)電卓
「3 + =」 → 「6.」
「3 - =」 → 「0.」
「3 × =」 → 「9.」
「3 ÷ =」 → 「1.」
演算子を入力した時点で表示されているものがそのまま入力されたと見なしているようです。統一されていて気持ちがいい仕様です。

というわけで、CoveredCalc は (3) に準拠してみることにしました。
つーか、してみることにしただけで、現在はそういう動きをしてないんですが。
参考までに現在の動き:
「3 + =」 → 「3.」
「3 - =」 → 「3.」
「3 × =」 → 「0.」
「3 ÷ =」 → 演算エラー
単に 0 が入力されたと見なされているだけです。
[PR]
by hironytic | 2004-05-12 23:15 | 構想