Hironytic Status

ひろんの開発日誌

"raw_char"の行方

2009-10-25 14:46:32 | 情報
久々に Haiku ビルド環境を整えて、最新ソースを SVN リポジトリからとってきました。
それでもって、ビルド。pe に日本語を入力したらエラーになることを確認してから、BottomlineWindow::HandleInputMethodEvent() に "raw_char" を試しに入れてみるようにして再ビルド。pe に日本語が入力できるようになることを確認しました。

ということで、とりあえず Haiku のバグなのか pe のバグなのかわかりませんが、Haiku と BeOS R5 の非互換ではあるように思うので、Haiku にバグ報告しておきました

11月から本業がまた忙しくなりそうな感じ。今のうちに Haiku、CoveredCalc 関係のことをできるだけやっておこうと……。
そういや、Windows 7 のことを考えていませんね。Coveredcalc は動くのかなー。

raw_char の続き

2009-10-21 15:00:26 | 情報
raw_char の件ですが、
よくわからないけれど、R1A1 では、IM で確定したときのメッセージに raw_char が入ってきてないようなのです。(Canna、Anthyのどちらも)
でも、KeyboardInputDevice.cpp は最近更新されていませんよね。
この raw_char を入れてるのは、キーボードから普通にキーが押されたときの部分なんでしょうか……。たしかに IM 経由でなければ raw_char が入ってきています。

私が Haiku(というか BeOS)の IM の仕組みをあまり理解していないので、ピントがずれてるのかもしれません。
このあたり、Murai さんの方が詳しそう……。私の頭の中で
BeOS で Canna といえば→ KanBe、KanBe といえば→ T.Murai さん
BeOS で Anthy といえば→ SHINTA さん
という図式ができあがってます(笑)

それはともかく、インライン変換時は別にして、インライン変換未対応アプリに対しては
src/servers/input/BottomlineWindow.cpp
の BottomlineWindow::HandleInputMethodEvent() で作った B_KEY_DOWN メッセージが
投げられているのではないかと推測します。確かにここでは raw_char を入れてません。
ここでなんでもいいから raw_char を入れてみたら、Pe に日本語が入力できるようになるのかも。

うーん、いま手元に Haiku のビルド環境がないんですよねー。
ナイトリービルドの VMware イメージがそのまま公開されるようになってからは、そっちばっかりで試していたので。


Pe は日本語化されたものがあったんですね。全く記憶にありませんでした。
というか、そのころ、私は BeOS 系から完全に離れていたかも。
逆に Pe で raw_char は存在しないときもあるように考慮するとか(PalEdit がそうなってます)、
インライン変換に対応するというのがスマートなのかもしれませんが。

…ところで Pe のバグ報告とかパッチとかってのは、Haiku に送るのは筋違いですよね。
まあ、この問題は BeOS R5 との非互換という Haiku の不具合かもしれないので、突き止められたら Haiku の trac にチケット登録したいですね。

raw_char が気になる

2009-10-20 00:13:34 | 情報
muraiさんへのお返事を兼ねて。

Paladin は初めて使ってみたのが 1.1 なのです。
なのでなんとも言えないのですが、Make したときのコンパイルエラーや警告をハンドリングしてリストにしてくれるのと、Run Logged で実行すると標準出力を(?)ハンドリングしてくれるウィンドウが出るのはいいなと思いました。
逆に言えば、それ以外は Pe + 手動 make でもそれほど困らないかなという感じもありますが。
でも 1.1 の新機能らしい Code Library は、よく使い方がわかっていません。

あと、"raw_char" は、IM からの確定時に、BeOS の Input Server は追加してくれるけど、Haiku の Input Server は追加してくれてないのではないかなというのが私の推測です。
と、これだけではナンなので、簡単なテストプログラムで試してみました。
BeOS R5 だと、IM からの確定時、カレントメッセージに "raw_char" として 0x0a をセットしたものが飛んできています。(0x0a って LF ですよね。別に Enter で確定しなくても常に 0x0a なんですよ……。なんでまた?)
Haiku (R1A1) だと、やはりカレントメッセージに "raw_char" がセットされていないみたいです。
murai さんとこで、Input Server が追加しているみたいというのは Haiku の話でしょうか?
最近のナイトリービルドでは追加されている…とか?

あと、手元の BeOS R5 環境で確認してみましたが、Pe 2.4.1 (x86) Open Source Version ではインライン入力はできませんでした。
もう少し前の Pe (ver 2.3) も試してみようかと思ったんですが面倒だったのでやめました(^^;
前は Pe より BeIDE が使いやすいと感じていたんですよね。なのであまり Pe 使った記憶がなくてインライン入力できたかどうか覚えてないです。

Paladin とか

2009-10-08 14:33:12 | 情報
前からあるのは知っていたけど試してみたことはなかった Paladin (Haiku 上の IDE) ですが、村井さんのところで日本語入力可というのを見て試してみようと思いました。
というのも、Haiku R1A1 の Pe で日本語が入力できないのに少々不満があるので。
ちなみに CoveredCalc ではそれほど日本語を入力しないので、どうでもいいちゃあいいんですが。

使ってみた印象としては「いいっ!」ですね。
BeIDE を目指していると言うだけあって、よくも悪くも BeIDE 風です。
#ソースファイルのグループくらいは多階層にできてもいいじゃないか……。
もう Pe 使うのに慣れているので、エディタが Pe ベースというのも使いやすいです。

CoveredCalc はソースファイルが多いので、Paladin 用のプロジェクトファイルを作るのは面倒。
Pe + make から乗り換えるかどうかはわかりません。

それはそうと、Paladin のエディタ部分 PalEdit は Pe をベースにしているのに日本語入力ができます。(こちらで村井さんが文字化けすると書かれてますが、少なくとも Haiku R1A1 と BeBits にある Paladin 1.1.0 の組み合わせでは文字化けせずに入力できました)
それをヒントに Pe と PalEdit のソースコードを比べたところ、Pe でエラーが出てしまうのは PText::KeyDown() の中の次の部分が原因のよう。

FailOSErr(Looper()->CurrentMessage()->FindInt32("raw_char", &ch));

PalEdit だと FailOSErr が外されています。
Pe が出すエラーメッセージから考えても、Haiku だと IM(IME) から入力されたときに、メッセージに "raw_char" が含まれてないんでしょうね。
そもそも IM(IME) からの入力の場合、いったい何が "raw_char" になるんだという疑問はあります。

でも BeOS R5 がこのコードで動いていたなら、R5 では何かが入っているんだと思うのでそれを突き止めればいいのかな。
Haiku の問題なのか Pe の問題なのか、それとも両方の問題なのかよくわかりませんが。

Haiku R1 α1

2009-09-16 21:17:22 | 情報
(Haiku系の)あちこちで話題になっている R1 α1 ですが、私もさっそく試してみました。
今まで通り VMware で。試すというよりこれまでどおり、CoveredCalc for Haiku の開発環境にするつもりなんですけど。これまで通りっつっても3月くらいから作業してなかったわけですが。

VMware はイメージをダウンロードしてきて展開して起動するだけ。楽ですよね。

まだあまり使えてませんが、とりあえずファーストインプレッションを。

VMware イメージの Haiku ディスクのサイズがほとんど Full なのはどういうこと!?
/boot/home/config/fonts の下に日本語フォントを入れようとしたら、ディスク容量が足りなくて入りませんでした。
ディスク容量が 600MB しかありません。
それとは別に 2GB の空ディスクイメージがついてます。
これは、この 2GB の方へインストールしろということでしょうか? 勝手にそうだと決めつけて、Installer で 2GB のディスクの方へインストールしちゃいました。

svnが相変わらず非ASCII部分のUTF-8を正しく扱えません。
Subversion が 1.6.5 になっていたのですが、やっぱり非ASCII部分が ?\229?\136 のようになります。
http://www.freelists.org/post/haiku/32bitwchar-t-branch-has-been-merged-into-trunk-full-rebuild-necessary,3
あたりを見て、もしかして治っているのかなーとか期待したんですが……。

Peが相変わらず日本語を受け付けません。
Pe に対して Anthy で日本語入力を行うと、確定時に Pe が「An OS error occurred: Name not found」というアラートを出して日本語が入力できません。
まあ、以前からそうだったんですが。BeOS 上の Pe はそんなことなかったので、Haiku 用にビルドされた Pe か、Haiku のどちらかの問題なんでしょうねえ……。

** ** **

3月ごろに比べると安定度は上がっているように思うのですが、なんともいえず。
svn と Pe の問題は Haiku の問題というのかどうか。OS の問題でもなさそうな気はしますけど。
CoveredCalc の開発では大きく問題になります。
Haiku の trac にチケットとして報告していいんでしょうかね。というかすでにチケットがあるかもしれませんが。(調べられません)


BAutolock と Autolock テンプレート

2009-01-06 10:27:13 | 情報
SHINTAさんのとこHaiku Coding Guidelines の中に BAutolock を使うなという記述があることを始めて知りました。でも代わりに使えという Autolock テンプレートがどこにあるのかわからなかったのでググって見ました。せっかく調べたので書いておきます。

結局、Haiku 内で Autolock テンプレートを見つけることはできなかったんですが(どこかにあるのかな?)どうやら Haiku Coding Guidelines は、OpenTracker の Coding Guidelines を元にしているようです。全く同じ表現があります。で、OpenTracker には、AutoLock.h というものがあるのでこれが Autolock テンプレートではないかと思います。ただし、このクラス、もともとは Be Newsletters - Volume 4: 1999 にあるものではないかと思いますが。

んでもって、BAutolock と Autolock テンプレートの違いといえば、
  • BAutolock はテンプレートじゃないので引数に BLocker と BLooper をそれぞれとるバージョンが存在する。一方、Autolock テンプレートは Lock()、Unlock()、IsLocked() を実装するクラスなら何にでも適用できる。(具体的には BBitmap にも適用できる)
  • BAutolock はコンストラクタでロック、デストラクタでアンロックという使い方しかできないが、Autolock テンプレートはコンストラクタでロックせずに必要になったときにロックしたり、任意のタイミングでアンロックができる。
くらいのものみたいです。

BAutolock は「スコープに合わせて自動的にロック・アンロックする」という目的だけを持つ非常にシンプルなユーティリティとして提供されているものだと思うので、サードパーティのアプリケーションが目的に合わせて BAutolock を使うことは特に問題ないと思います。
Haiku Coding Guidelines はあくまで Haiku を作るときのガイドラインなので、Haiku にパッチを送ったりするのでなければ、他のカッコの位置とかのルールと同じ程度に参考にすればいいんじゃないかと思いました。

Haiku のビルド

2008-08-14 14:31:19 | 情報
CoveredCalc Haiku 版を作るための作業としてまずは Haiku を用意することにしました。うちでは既に実機は用意できない状態なので、Windows 上の VMware Player を使います。なお、CoveredCalc for BeOS 1.10.0 は実は VMware 上の BeOS で開発しました。(^^;

Haiku Files にある vmware イメージだと開発ツールが付属しないのですが、Senryu だと余分なものがありすぎるということで、ソースからビルドすることにしました。その方が Haiku の更新も追いやすいですしね。

だいたい、次のサイトを参考にさせてもらってビルドに成功しました。
・muraiさんのHaikuインストールメモ(Linuxホスト編)
・SHINTAさんの白 Be 全般

実際は試行錯誤してるのでこのとおりやってうまくいくかどうかはわかりませんが。メモとして残しておきます。

  1. VMware Player とか、VMX Builder とかはインストールされているとして。
  2. Haiku ビルド用の Linux として Ubuntu の日本語ローカライズドVMware用仮想マシン をダウンロードします。ubuntu-ja-8.04-vmware-i386.zip を使いました。
  3. ダウンロードした Ubuntu を VMware Player で起動して、Haiku のビルドに必要なものを揃えます。
    sudo apt-get install subversion autoconf automake texinfo flex bison gawk build-essential

  4. Haiku buildtools のチェックアウト
    svn checkout http://svn.berlios.de/svnroot/repos/haiku/buildtools/trunk buildtools

  5. Haiku ソースのチェックアウト
    svn checkout http://svn.berlios.de/svnroot/repos/haiku/haiku/trunk trunk

  6. Jam のビルド
    cd buildtools/jam
    make
    sudo ./jam0 install

  7. Haiku buildtools のビルド
    cd trunk
    ./configure --build-cross-tools ../buildtools/ --include-gpl-addons --use-gcc-pipe

  8. trunk/build/jam/UserBuildConfig を作成。中身は次のとおり。

    HAIKU_VMWARE_IMAGE_NAME = haiku.vmdk ;
    HAIKU_IMAGE_SIZE = 256 ;

    AddOptionalHaikuImagePackages Development Pe ;

    # Canna
    AddFilesToHaikuImage beos system add-ons input_server methods : canna ;

    # Timezone
    AddSymlinkToHaikuImage home config settings
    : /boot/beos/etc/timezones/Asia/Tokyo : timezone ;

    # Keymap
    AddFilesToHaikuImage home config settings : <keymap>Japanese
    : Key_map ;

    # Sound
    AddOptionalHaikuImagePackages OpenSound ;


  9. Haiku のビルド
    cd trunk
    jam -q @vmware-image

  10. trunk/generated の中に haiku.vmdk ができているので、これをドラッグ&ドロップで Windows 側に持ってくる。
  11. Haiku.vmx ファイルを用意。Senryu のものを流用してディスク関係のところだけ変えました。VMX Builder で Haiku.vmdk 以外に Work.vmdk を新規 HDD として用意。Haiku.vmdk は Haiku の更新のたびに作り直すと思うので、消えてほしくないものはこっちの HDD に入れておきます。
  12. Haiku.vmx ファイルを VMware Player で起動。あと、DriveSetup で Work.vmdk の方の HDD を BFS で初期化しておきます。


ちなみにてきとーな MP3 ファイルを再生させたらサウンドも鳴りました。いい感じです。

メニュートリガー

2007-09-21 00:49:09 | 情報
図の一番上に示したのは 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
)

BeIDE から rc を使う

2004-08-27 23:38:16 | 情報
前に書いたとおり
BeIDE GenericTranslator (Bison / Flex)
ソースを改造して rc
BeIDE から使えるようにしました。

~事前準備~
・rc はインストールしておいてください。
・rc (/boot/home/config/bin/rc) へのシンボリックリンクを /boot/develop/BeIDE/tools の下に作成しておいてください。

~改造…やったこと~
・Project Settings で出力ファイル名を RcPlugin にする。
・ResHelper.h, ResHelper.cpp をちょこちょこ変えて RcHelper.h, RcHelper.cpp を作る。
  RcHelper.h は、ファイル名と二重読み込み防止の #define 名、それにクラス名を変えたくらい。
  RcHelper.cpp は、ファイル名・クラス名の変更に加えて、
   - RcHelper::GetToolName() で return "rc"; にする
   - RcHelper::MakeOutputFileName() で、outputName.ReplaceLast(".rdef", ".rsrc"); にする。
   - RcHelper::CreateErrorMessage() で、return this->ParseFileLineError(text, "Error! ", ":", ":", " "); にする。
・Plugin.cpp で、不要な Flex, Bison, Res の Helper から Builder を作るのをやめて、RcHelper から Builder を作るだけにする。
・あとはビルド。

~使い方~
・/boot/develop/BeIDE/plugins/Prefs_add_ons に RcPlugin を置く。
・利用するプロジェクトの Project Settings で、Project → Target にて、
  File Type: text/*
  Extension: rdef
  Tool Name: rc
  Flags: Precompile Stage にチェック
・リソース定義ファイル (.rdef) をプロジェクトに追加する。
・いったんビルドして .rsrc ファイルを作る。
・できあがった .rsrc ファイルもプロジェクトに追加する。

できあがる .rsrc ファイルをプロジェクトに追加しないといけないのはちょっと面倒かもしれません。
まあ、一度やってしまえば後は気にしなくていいわけですが。

BeIDE GenericTranslator

2004-08-20 18:14:30 | 情報
BeBits で BeIDE GenericTranslator (Bison / Flex)なるものを見つけました。BeIDE で様々な外部コンパイルツールに対応させる add-on らしいです。
ソースで提供されていて、対応させるツールに応じて BuildHelper を継承したクラスを作成して、Plugin.cpp にある MakeAddOnBuilder でそれを返すようにすればいいみたい。
(今、手元に BeOS な環境がないのでソースを見て推測で書いてます)

元々は Be の Newsletter に書かれたものみたいです。

で、これを使えば、Haiku OS の rc(リソースコンパイラ)を BeIDE 上から呼び出せるような気がするわけです。
そうなれば、mwbres を使おうとしてたらリソース文字列内に「"」をどう含めたらええんや? とか改行を含めたかったら実際に改行せなあかんのは見にくいぞ、とか文句を言う必要がなくなります。
(実際に rc を使ったことがないので、推測で書いてます)

CoveredCalc の BeOS 版開発には BeIDE GenericTranslator + rc を使おうと思いました。