アカウント名:
パスワード:
runeyokohama 氏のタレコミはツールキットのレベルの話のような気がしたんだけど。「OS 非依存」ということは、現在普及している Linux/BSD/Un*x/Windows/Mac/... などさまざまなシステムの上でそのまま使いたい、というニーズを表現しているのだと思うんですが、そうすると、OS そのものは解には当然なりえないけど、X Window System を変えるのもちょっと大ごとかな、と。
「言語非依存」って書いているので、ユーザからの観点ではなくて開発者からの観点でしょう。(それとも、ここで「言語」
X Window System を変えるのもちょっと大ごとかな、と。
大事ではあるけど、そろそろXは御役御免にして、次が出てきてほしいなと思いますね。
たとえば Qt は国際化はそこそこいいし
いやぁ、実際はひどい物ですよ。 XIM関連の実装はひどいものだし(gtk+のimmoduleはうらやましい)、 selectionまわりも未だにCOMPOUND_TEXT対応はオリジナルには実装されてません。 よく、multibyte圏のことを忘れて、1byte圏向けにパフォーマンス改善のための修正が入ったりして、 バグ報告をする羽目になったりしますし。 国際化を除いても、最近は検証してないだろうというようなバグ
文字列そのものに触らないようにすれば
正規表現か?(それも multibyte 化すんの大変そうだけど…)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
誰にとって最強? (スコア:0)
どのレベルのGUI? (スコア:1)
Xに代わるシステムか、その他のOSに付随したWindow Systemフレームワークの
話かと思ったんですが、・・・みなさんGUIアプリケーションとかWindow Managerの話を
してらっしゃって、どのレベルから唾をつけるべきか混乱してます・・・。
#Xに代わるものとしては、ネットワーク透過性にセキュリティを組み込んだもの、
#ポリシーの明確なものが欲しいですねぇ・・・。
#あ、あとMI/MDの区分がはっきりしてい
---- redbrick
Re:どのレベルのGUI? (スコア:1)
runeyokohama 氏のタレコミはツールキットのレベルの話のような気がしたんだけど。「OS 非依存」ということは、現在普及している Linux/BSD/Un*x/Windows/Mac/... などさまざまなシステムの上でそのまま使いたい、というニーズを表現しているのだと思うんですが、そうすると、OS そのものは解には当然なりえないけど、X Window System を変えるのもちょっと大ごとかな、と。
「言語非依存」って書いているので、ユーザからの観点ではなくて開発者からの観点でしょう。(それとも、ここで「言語」
Re:どのレベルのGUI? (スコア:3, 参考になる)
大事ではあるけど、そろそろXは御役御免にして、次が出てきてほしいなと思いますね。
いやぁ、実際はひどい物ですよ。
XIM関連の実装はひどいものだし(gtk+のimmoduleはうらやましい)、
selectionまわりも未だにCOMPOUND_TEXT対応はオリジナルには実装されてません。
よく、multibyte圏のことを忘れて、1byte圏向けにパフォーマンス改善のための修正が入ったりして、
バグ報告をする羽目になったりしますし。
国際化を除いても、最近は検証してないだろうというようなバグ
-- Che Che - Bye Bye
M17Nの根本的な問題 (スコア:1)
アプリケーション実装する人間が multibyte 使っていない、
という状況が問題なんだよね。
文字列そのものに触らないようにすれば
ある程度は解決できるんだろうけど( gettext とかが近いかな)、
# mishimaは本田透先生を熱烈に応援しています
char *を使わせるな (スコア:3, 参考になる)
内部はQStringクラスを用いるようになってます。
ときどき、ぎりぎりまでchar *で扱ってて、最後の最後でQStringに変換してQtに渡すアプリがありますが、
素直に作れば入出力のところでQStringに変換されるため、
I18Nを意識していない人が作ったアプリでも、割と楽にI18N化できます。
char *を直接扱えるようなAPIになってると、I18Nですら面倒です。
内部コードと変換関数を用意し、出来る限りはやい時点で(出来れば半自動的に)変換させるようにしてないと難しいでしょうね。
できれば、内部コードとchar *形式とで、互換性がないといいかも。
内部でmultibyte charを使っているようでは国際化は手間がかかるだけです。
wide charを使うべきでしょう。
-- Che Che - Bye Bye
Re:char *を使わせるな (スコア:1)
(生粋のWinプログラマでないのでよく知らない)らしい。
内部で unicode に変換してるらしいんだけど。
wide char だと文字エンコーディングをロケールで判断されるのがどうも…
まあ、一つのアプリケーションで複数言語を扱いたい場合なんてほとんどありえないから、
ツールキットが提供する90%の回答としては十分なのかな。
# mishimaは本田透先生を熱烈に応援しています
Re:char *を使わせるな (スコア:1)
これはこれでアドホックにうまくいっていると思いますが、本当に Unicode 文字列と ANSI 文字列が混ざって出てくる状況では、変換の回数を減らす工夫がないと、あまり解決にならないように思います。
もちろん、道具は特性を知った上でうまく利用すればいいわけですから、 MFC がいいの悪いのという話ではありませんが。
鵜呑みにしてみる?