[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
| 開発状況
|
検索
カテゴリ
以前の記事
2009年 12月
2009年 11月 2009年 10月 2009年 09月 2009年 04月 2009年 01月 2008年 11月 2008年 09月 2008年 08月 2008年 07月 2008年 05月 2008年 03月 2008年 02月 2008年 01月 2007年 12月 2007年 11月 2007年 09月 2007年 06月 2007年 05月 2007年 04月 2007年 03月 2007年 02月 2007年 01月 2006年 12月 2006年 11月 2006年 10月 2006年 09月 2006年 05月 2006年 04月 2006年 03月 2006年 01月 2005年 12月 2005年 11月 2005年 10月 2005年 09月 2005年 08月 2005年 07月 2005年 06月 2005年 05月 2005年 04月 2005年 03月 2005年 02月 2005年 01月 2004年 12月 2004年 11月 2004年 10月 2004年 09月 2004年 08月 2004年 05月 2004年 04月 2004年 03月 最新のトラックバック
関連リンク
その他のジャンル
ファン
記事ランキング
ブログジャンル
画像一覧
|
ファン申請 |
||