人気ブログランキング | 話題のタグを見る

[CoveredCalc Be]ダイアログリソースの問題

カバー読み込みを DOM 経由にする作業は終わりました。でも、これだけではユーザにとっては何の意味もないので、まだリリースはしません。ソースは公開してもいいかもしれません。区切りとして。

それはともかく、なんとなく、BeOS 版のダイアログリソースの持ち方を変更し始めました。
これまで、Interface Elements で作った 'ARCV' リソースを BMessage で Unflatern して、そこからダイアログ (BWindow) オブジェクトを構築していました。
この方法を採った理由の 1 つは、ダイアログエディタを使いたかったこと。そしてもう 1 つはリソースを変更するだけでローカライゼーションが (まあ少しは) 可能なこと。
(LocaleKit を使わない)ローカライゼーション対応も将来行いたいと思っていますが、これは単に読み込むリソースを切り替えるだけで実現することを考えています。(今回の件に関係ないので触れてないだけで、ZETA 用に LocaleKit を使ったローカライゼーションの対応も予定としてはあります)
が、実装を進めるごとに、これはちょっと問題やなと思う点がいくつかでてきたので、ちょっと別の実現方法に変更中です。

以下、問題やなと思った点:

1. Interface Elements が古い。

Interface Elements 自身がすでに手に入りにくかったり、今後のサポートも期待できません。
まあ、GuiBerry に期待するという手はあると思いますが。(でも、GuiBerryは BWindow ではなく、BView をアーカイブするんだった気もします。まあ、それでも別に問題無いんですが。)

2. BMessage への Archive が完璧ではない。

例えば、BTextView は Archive したときにフォントと色の情報をちゃんと覚えてくれないみたいで、C++のソースの方でオブジェクトを復元してから改めてフォントと色を設定していたりします。なんか中途半端です。

3. BMessage を Flatten したときのデータの形式が R5 と ZETA で異なる。

ZETA では BMessage を Flattern したデータの形式が新しくなっているみたいで、R5 で作ったデータを ZETA で Unflatten することはできますが、逆はできなかったような記憶があります。これはつまり、ローカライゼーションのためにリソースを作るだけでも、ZETA 上で作業したのでは R5 用に使えないのでダメということになります。

4. 独自のクラスをどうするかいつも悩む。

BView(あるいはその継承クラス)を継承した独自クラスでコントロールの実装を行うときに、それをどうアーカイブしようか悩んでしまいます。
by hironytic | 2005-09-25 20:56 | 開発状況
<< [CoveredCalc] ソ... [CoveredCalc] 進... >>