3月 262004
以前にちょっと構想を書いていたKDE用エンコード自動認識クラスを制作中。
まだまだ練りは足りないけれど、とりあえずそこそこ形になってきた感じがするので暫定公開。
ライブラリの形になってますが、最終的にはkdelibs/kutils辺りへのパッチとする予定。
もうすこしAPIを検討しながら、kdelibs/khtml/misc/decoder.cppあたりにある関数を取り込んで行きます。
KDetectEncoding, KEncodingDetecterという名前の付け方はなんだかなと自分でも思うのでいい名前の提案を募集中。同時に、APIとその役割についてはもう少し考えておきたい。
後、doxygenあたりの使い方がよくわかってないのでMakefile.am等も含め、その辺はいろいろと作業がいるかな。
今後の予定としては、kdelibs/kutilsへのパッチ化の後、
khtmlをKDetectEncoding classを使うように変更、kdelibs/kateを同様に改造、KTextEditerInterfaceへの自動認識関連の機能の追加、kdebase/kateの改造を行なっていく予定。
暫定パッチだけでも今月中に作りたいところだけど、ちょっと微妙かな。
一通り出来たら KDE本家への提案へ行きます。
ゆくゆくはKMailのtext attachmentでの対応なども行ないたいところ。
Warning: count(): Parameter must be an array or an object that implements Countable in /home/asaki/www/wordpress/wp-includes/class-wp-comment-query.php on line 405
質問です。文字コードの判定をkdelibs/kutilsに局所化するという考えは
すばらしいと思うのですが、なぜQtへの変更としないのでしょうか？
それとも、それはそれで別に行っていく予定なのでしょうか？
Qtでの対応は考慮していません。理由としてはいくつかありますが、
* 変更が自分の手ではできないこと
* 実装がおそらくQt-4の時点となるため、KDEでの対応が早くても4.0以降となること。(KDEのパッチなら3.3での実装も不可能ではない)
* QTextCodec::codecForContents()という(役に立ってないながらも)自動認識のためのフレームワークがQtには存在するが、まともな実装とする場合、この機能の削除が必要であること。また、QTextCodecの機能としての実装とする場合、実用的なものを作成することが非常に難しいと思われること。
* 認識失敗時のリカバリーなどを考慮すると、QTextStreamなどのクラスで簡単に扱える形での実装はかなり困難であり、Qtの構成的にちぐはぐな機能となりかねないこと。
* Qtでの実装が必須な機能でないこと。
とりあえず、こんなところでしょうか。Qtでの実装を考えた場合、その労力に比べてメリットがほとんどないと考えています。
書き忘れ。
ただし、現状でKDEの機能としてはKLocale周りしか使用するつもりがないため、KDEの機能を使用しないQtベースのライブラリとして実装する方向性は十分に考えられます。また、場合によってはQtも使用しないC++のライブラリとしての実装もありとは思ってます。
このあたりは私の中では些細なことなので、どれが望ましいかは周囲の希望しだいです。
Qtへの変更を行わないことについて、
詳しい説明ありがとうございました。
また、「KDEの機能を使用しないQtベースのライブラリ」
とか「Qtも使用しないC++のライブラリ」としての
実装については、私個人としてはどちらでもいいと思います。
特に作成後の展開も必要になりますし。