アカウント名:
パスワード:
runeyokohama 氏のタレコミはツールキットのレベルの話のような気がしたんだけど。「OS 非依存」ということは、現在普及している Linux/BSD/Un*x/Windows/Mac/... などさまざまなシステムの上でそのまま使いたい、というニーズを表現しているのだと思うんですが、そうすると、OS そのものは解には当然なりえないけど、X Window System を変えるのもちょっと大ごとかな、と。
「言語非依存」って書いているので、ユーザからの観点ではなくて開発者からの観点でしょう。(それとも、ここで「言語」
X Window System を変えるのもちょっと大ごとかな、と。
たとえば Qt は国際化はそこそこいいし
文字列そのものに触らないようにすれば
正規表現か?(それも multibyte 化すんの大変そうだけど…)
使ってない人はテストできない、というのはその通りで、現在のさまざまなソフトウェアのヘボい m17n が抱えている問題がまさしくそれなんですが、一方で、multibyte も使うし combining character も使うし bidi も使うし、なんていう人は世の中にはそんなにいないので、「テストできなければ良い m17n ができない」という状況を作り出しているようなフレームワーク (OS とか API とかツールキットとか) の側に責任を求めてもいいと思います。つまり、何も考えなくても自然と m17n なアプリケーションが作れてしまう (それに違反するほうが難しい) という状況を作り出していく必要があります。
それでも、もし理想的なフレームワークができたとしても、それが提供してくれるような一般的な m17n だけではだめでもっときめ細かな操作が必要なアプリケーションなんてのもあるだろうから、そういう分野では最後までアプリケーション開発者の責任が残っていくのでしょうが。
mule の入力ルーチンとかについても、他のソフトウェアから使えるようにライブラリだったらいいね、とかいう声を聞いたことがありますが、それを実装したという話を聞いたことがありません。やってみないとわからない困難とかでも、あるのでしょうか。
ちなみに、mule がよくできたソフトウェアだというのは、日本人だけの思い込みかもしれないと思っています。(ぼく自身も、よくできたソフトウェアだとは思っていますが)。たとえば、台湾でさえ Mule が普及していない [srad.jp]という現実があります。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
誰にとって最強? (スコア: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, 参考になる)
いやぁ、実際はひどい物ですよ。
XIM関連の実装はひどいものだし(gtk+のimmoduleはうらやましい)、
selectionまわりも未だにCOMPOUND_TEXT対応はオリジナルには実装されてません。
よく、multibyte圏のことを忘れて、1byte圏向けにパフォーマンス改善のための修正が入ったりして、
バグ報告をする羽目になったりしますし。
国際化を除いても、最近は検証してないだろうというようなバグを含んだ形でリリースされることが多いですね。
Qt2系は2.3.1が未だに推奨バージョンです(しかるべきパッチを当てれば2.3.2も多分大丈夫)。
Qt3系は3.0.2が一応推奨バージョンですが、3.0.2リリース直後に多数の修正が入ってきています。
defaultのXIM入力スタイルがOnTheSpotでその実装が駄目駄目なことを考慮すると、好きもの以外にはQt3系は進められませんね。
KDE3はかなり良くなってきているだけに(日本語対応もかなり本家に取り込まれました。問題はまだまだ残ってるけど)、そのあたりが残念。
使いやすいtoolkitだし、パッチを当てた上で細かいところを気にしなければ通常は充分なことのほうが多いですけどね。
-- 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]という現実があります。