アカウント名:
パスワード:
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 化すんの大変そうだけど…)
使ってない人はテストできない、というのはその通りで、現在のさまざまなソフトウェアのヘボい m17n が抱えている問題がまさしくそれなんですが、一方で、multibyte も使うし combining character も使うし bidi も使うし、なんていう人は世の中にはそんなにいないので、「テストできなければ良い m17n ができない」という状況を作り出しているようなフレームワーク (OS とか API とかツールキットとか) の側に責任を求めてもいいと思います。つまり、何も考えなくても自然と m17n なアプリケーションが作れてしまう (それに違反するほうが難しい) という状況を作り出していく必要があります。
それでも、もし理想的なフレームワークができたとしても、それが提供してくれるような一般的な m17n だけではだめでもっときめ細かな操作が必要なアプリケーションなんてのもあるだろうから、そういう分野では最後までアプリケーション開発者の責任が残っていくのでしょうが。
mule の入力ルーチンとかについても、他のソフトウェアから使えるようにライブラリだったらいいね、とかいう声を聞いたことがありますが、それを実装したという話を聞いたことがありません。やってみないとわからない困難とかでも、あるのでしょうか。
ちなみに、mule がよくできたソフトウェアだというのは、日本人だけの思い込みかもしれないと思っています。(ぼく自身も、よくできたソフトウェアだとは思っていますが)。たとえば、台湾でさえ Mule が普及していない [srad.jp]という現実があります。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
誰にとって最強? (スコア: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 とかが近いかな)、
それだけじゃあ当然ダメなんだろうなぁ。
どんな操作があれば文字列操作に必要十分なんだろ?
正規表現か?(それも multibyte 化すんの大変そうだけど…)
# 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 がいいの悪いのという話ではありませんが。
鵜呑みにしてみる?
Re:M17Nの根本的な問題 (スコア:2, 興味深い)
使ってない人はテストできない、というのはその通りで、現在のさまざまなソフトウェアのヘボい m17n が抱えている問題がまさしくそれなんですが、一方で、multibyte も使うし combining character も使うし bidi も使うし、なんていう人は世の中にはそんなにいないので、「テストできなければ良い m17n ができない」という状況を作り出しているようなフレームワーク (OS とか API とかツールキットとか) の側に責任を求めてもいいと思います。つまり、何も考えなくても自然と m17n なアプリケーションが作れてしまう (それに違反するほうが難しい) という状況を作り出していく必要があります。
それでも、もし理想的なフレームワークができたとしても、それが提供してくれるような一般的な m17n だけではだめでもっときめ細かな操作が必要なアプリケーションなんてのもあるだろうから、そういう分野では最後までアプリケーション開発者の責任が残っていくのでしょうが。
Re:M17Nの根本的な問題 (スコア:1)
アプリケーションプログラマが g_string に対する直接操作をできないようにすれば、
たいていのアプリケーションの M17N についてはだいぶ良くなると思うんだけど、どうかな?
(bidi までは難しそうだけど)
#Lisp であることはこの際置いておく。
# mishimaは本田透先生を熱烈に応援しています
Re:M17Nの根本的な問題 (スコア:1)
mule の入力ルーチンとかについても、他のソフトウェアから使えるようにライブラリだったらいいね、とかいう声を聞いたことがありますが、それを実装したという話を聞いたことがありません。やってみないとわからない困難とかでも、あるのでしょうか。
ちなみに、mule がよくできたソフトウェアだというのは、日本人だけの思い込みかもしれないと思っています。(ぼく自身も、よくできたソフトウェアだとは思っていますが)。たとえば、台湾でさえ Mule が普及していない [srad.jp]という現実があります。