[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[FDclone-users:00392] Re: 日本語文字コード(UTF8)環境での動作について



> 他の open source community と比べると FDclone のそれは非常
>に小規模なものなので、まぁ和気あいあいとやっていきましょうや。

 そう言って頂けると随分と気がラクです(^^;)。


> それでも一応 compile 時の選択子は残しているんですよ。未だ
>FDclone 1.03 の仕様で compile することも可能な筈ですし。
> performance 低下が致命的になるような環境ではそういう選択も
>ないではないんですけどね。_NODOSDRIVE と _NOKANJIFCONV を指
>定するだけでも相当高速化すると思います。

 ここらへん、各項目の解説はドキュメント install や TECHKNOW でも触れてらっし
ゃいますね。
 ただ、どちらかと言うとそちらは個々の機能の解説って意味合いが強いように思うん
で、まさに具体的にどの場面に反映されるのか?ってイメージが分かり辛いように思い
ます。

 また、 FD-Clone のコンパイルオプションって、 configure で指定するのでは無く
、
直接ソースに手を加える形になりますよね。
 正直、ソース触るってのには少なからず抵抗が・・・。いや、理屈の上では、大した
問題じゃないとは分かってはいるんですが。

 こういった部分も少なからず敷居の高さに繋がってくのかもしれません。

#まぁ、ソース触るのに抵抗ある人間は、そもそもソースからコンパイルもしないって
#話もありますが(^^;)。


> kctype.h に defaultkcode という変数がありますので、この値
>を「NOCONV」から「UTF8」等に変えてやれば、既定漢字コードを指
>定可能です。

 と言うことで、早速コンパイルしなおして、GWの外出中、この環境でしばらく試用
を続けてみました。

 確かに、いくつかの制限・・・特に、シェルとしての動作が行われる際に、不便な部
分もありますが、単にランチャ動作をさせる分には、いちいちパラメータマクロで引数
を囲ってやったりする必要も無くなり、これはこれでそれなりに便利でした。

 変数で指定可能になれば、カスタマイザからの設定も出来るようになるんだと思いま
すんで、そうなるとさらに使い勝手も良くなるかな?、と期待してます。


> でも実際 UTF-8 にして使ってみると結構不便ですよ。Zaurus は
>設計的には UTF-8 に対応しているとは言い難いんじゃないかなー。

 実際、 SHARP 純正のターミナルからして EUC 固定だったりしますしね。
 正直なところ、 Zaurus ネイティブの環境としては UTF-8 どころか、日本語すら考
慮されてないんでは無いかと思います。
 あくまでも、日本語はアプリケーションレベルで処理しちゃえ、と。

 そういう意味では、ファイルシステム上で UTF-8 を意識しなきゃならないってのも
単に ”Qtopia と言うアプリケーション”の仕様に引っ張られてるだけって気もするん
ですよね〜。

#まぁ、 Qtopia で扱ってる UTF-8 なファイルシステムがデファクトに成り得れば、
#話も変わってくるんでしょうけど・・・なるんかな(^^;)。


                                                        TAKETYON こと 武貞一三