アカウント名:
パスワード:
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圏向けにパフォーマンス改善のための修正が入ったりして、 バグ報告をする羽目になったりしますし。 国際化を除いても、最近は検証してないだろうというようなバグ
使ってない人はテストできない、というのはその通りで、現在のさまざまなソフトウェアのヘボい m17n が抱えている問題がまさしくそれなんですが、一方で、multibyte も使うし combining character も使うし bidi も使うし、なんていう人は世の中にはそんなにいないので、「テストできなければ良い m17n ができない」という状況を作り出しているようなフレームワーク (OS とか API とかツールキットとか) の側に責任を求めてもいいと思います。つまり、何も考えなくても自然と m17n なアプリケーションが作れてしまう (それに違反するほうが難しい) という状況を作り出していく必要があります。
それでも、もし理想的なフレームワークができたとしても、それが提供してくれるような一般的な m17n だけではだめでもっときめ細かな操作が必要なアプリケーションなんてのもあるだろうから、そういう分野では最後までアプリケーション開発者の責任が残っていくのでしょうが。
mule の入力ルーチンとかについても、他のソフトウェアから使えるようにライブラリだったらいいね、とかいう声を聞いたことがありますが、それを実装したという話を聞いたことがありません。やってみないとわからない困難とかでも、あるのでしょうか。
ちなみに、mule がよくできたソフトウェアだというのは、日本人だけの思い込みかもしれないと思っています。(ぼく自身も、よくできたソフトウェアだとは思っていますが)。たとえば、台湾でさえ Mule が普及していない [srad.jp]という現実があります。
より多くのコメントがこの議論にあるかもしれませんが、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は本田透先生を熱烈に応援しています
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]という現実があります。