<   2004年 12月 ( 4 )   > この月の画像一覧

メールデータコンバータ

今まで使っていたのと別のメーラーに乗り換えてみようかなと思っても、過去のメールデータを捨てたくないのでそのままにしてたりとかってよくあります。
ぼくは Becky! 2Shuriken Pro3 /R.2を主に使うユーザーですが、この 2 つのメーラー間でメールデータをやりとりしたいときもないわけではありません。
(2つもメーラーを使うなというつっこみもあるかもしれませんが)

そこで次のような仕組みを考えました。

・メーラー別の入力プラグインで各種メーラーのメールデータを読み込む。
・メーラー別の出力プラグインで各種メーラーにメールデータを書き出す。

要するに、各種メーラー共通のメールデータフォーマットを用意して、そのフォーマットと各種メーラーのデータを変換する部分をプラグインにするわけです。
(なぜ、プラグインにするかというと、ぼくがいろんなメーラーを解析してコンバータを作りたくないから。プラグインにすれば他の人が必要に迫られて作ってくれるかもしれないし、データ構造を知っているメーラー作者が作ってくれるかもしれないから)

問題は、各種メーラー共通のフォーマットというのが設計できるかどうかです。

ちょっと考えてみました。
例えば、Becky! には各メールにカラーラベル(16,777,216色だけ用意できるはず)を付けることができます。
Shuriken では、A ~ D の 4 種類(マークなしをいれると 5 種類)のマークを付けることができます。
これで共通のフォーマットに「カラーラベル」と「マーク」を用意するというやり方では、多くのメーラー共通にするのはムリっぽいです。
ならば、共通のフォーマットにはそれらは属性という、それだけでは意味がわからないものとして用意してやればどうでしょう。
意味はユーザが決めるのです。

例えば、Becky! 用の入力プラグインはカラーラベルを勝手に「カラーラベル」という属性に変換します。
同様に Shuriken の入力プラグインはマークを勝手に「マーク」という属性に変換します。
それだけではコンバートできないので、出力プラグイン側では、どの属性をどう変換するかをユーザに指定させます。
例を挙げると、Shuriken の入力プラグインから得たデータには「マーク」という属性がついています。
これを、Becky! の出力プラグインを使って出力しようとすると、ユーザは「カラーラベル」の項目をどうするか尋ねられます。
ユーザは「マーク」という属性が A のときにカラーラベルを赤色(#ff0000)にしろというような変換ルールを指定するわけです。

そういうルール指定が柔軟にできるシステム部分を作りたいなと、ふと思いました。
#逆にいうとプラグイン部分は作りたくないな…。
[PR]
by hironytic | 2004-12-28 17:29 | 開発ネタ

[CoveredCalc for BeOS] アバウト

今日は嫁さんと子供たちが出かけてくれて、ぼくに休みをくれました。
それを利用して一気に About(バージョン情報)ダイアログを実装しました。

a0011820_2316792.gif


今日だけではなく、少し前からちょっとずつ実装していたんですが、BTextView、画像のリソース埋め込みとそれを描画する部分、バージョンのリソースからの取得と、初めて体験することが多くて方法を調べるのに手間取りました。
それから、Windows はモーダルダイアログ(ダイアログを閉じるまで動作が止まる)で実装しているんですが、BeOS ではモードレス(ダイアログを出したまま他の操作ができる)が一般的なのでそういう作りにしています。
そのあたりがソースの共通化を妨げかねないところですが、About ダイアログにあまり機能がないので今のところごまかせている感じです。
[PR]
by hironytic | 2004-12-19 23:16 | 開発状況

[CoveredCalc for BeOS] フォント

a0011820_0304413.gif
昨日の「登録されているカバーの一覧:」に Plain Font が設定されていない件について調べました。

どうやら、リソース中には、ビューのフォントとしてリソース作成時の Plain Font の名前・サイズが入っているみたいです。
つまり、リソース作成時に Plain Font と指定したら、その時の Plain Font でビューが作られて、それをアーカイブしたら、その時の Plain Font が入ったと。当然か。

ボタンなんかは、Plain Font 以外のフォントを指定してても、Plain Font が強制的に使われるってことなんでしょうか。
よくわからないですが、そうだとしても不思議はありません。
とにかく、ダイアログ初期化時に全てのビューに Plain Font を設定してやるようにしました。
[PR]
by hironytic | 2004-12-07 00:35 | 開発状況

[CoveredCalc for BeOS] ダイアログの大きさ

InterfaceElements でダイアログをデザインするときにフォントについては plain font を使うように指定しています。実行時にはユーザが(システムの設定で)指定したフォントが使われるので、フォントの大きさによってはボタンなどの文字列がコントロールの矩形をはみ出してしまう恐れがあります。
InterfaceElements に付いてくる IE Library を使っていれば、デザイン時のフォントサイズ(InterfacceElements が一緒にアーカイブしてくれる)と実行時のフォントサイズを比べて、ウィンドウとビュー(各コントロール)をスケーリングしてくれるのですが、残念ながら CoveredCalc は IE Library を使っていません。
そこで、IE Library でやっているのと同等の処理を実装してやりました。

a0011820_3182366.gif


実験してみたところ、ちゃんとスケーリングはされてるようです。(上段:Haru 12、下段:Haru 9)
でも、「登録されているカバーの一覧:」のフォントが変わってないのはなんでだ!?
これまで、フォントサイズを変えてみたことがなかったんですが、スケーリング処理とは関係ないはず。調査せねば…。
[PR]
by hironytic | 2004-12-06 03:21 | 開発状況