アカウント名:
パスワード:
runeyokohama 氏のタレコミはツールキットのレベルの話のような気がしたんだけど。「OS 非依存」ということは、現在普及している Linux/BSD/Un*x/Windows/Mac/... などさまざまなシステムの上でそのまま使いたい、というニーズを表現しているのだと思うんですが、そうすると、OS そのものは解には当然なりえないけど、X Window System を変えるのもちょっと大ごとかな、と。
「言語非依存」って書いているので、ユーザからの観点ではなくて開発者からの観点でしょう。(それとも、ここで「言語」って自然言語のこと?)
たとえば Qt は国際化はそこそこいいし X でも Windows でも動くけど C++ という言語に縛られてしまう、とか。
Tk なんかはどうでしょう? X/Win/Mac で動くし、Tcl/Perl/Ruby/Python などが対応してるし、X 上では国際化がいまいちだけど、「Tcl/Tk 日本語版」なんてのもあるし。
X Window System を変えるのもちょっと大ごとかな、と。
たとえば Qt は国際化はそこそこいいし
文字列そのものに触らないようにすれば
正規表現か?(それも multibyte 化すんの大変そうだけど…)
使ってない人はテストできない、というのはその通りで、現在のさまざまなソフトウェアのヘボい m17n が抱えている問題がまさしくそれなんですが、一方で、multibyte も使うし combining character も使うし bidi も使うし、なんていう人は世の中にはそんなにいないので、「テストできなければ良い m17n ができない」という状況を作り出しているようなフレームワーク (OS とか API とかツールキットとか) の側に責任を求めてもいいと思います。つまり、何も考えなくても自然と m17n なアプリケーションが作れてしまう (それに違反するほうが難しい) という状況を作り出していく必要があります。
それでも、もし理想的なフレームワークができたとしても、それが提供してくれるような一般的な m17n だけではだめでもっときめ細かな操作が必要なアプリケーションなんてのもあるだろうから、そういう分野では最後までアプリケーション開発者の責任が残っていくのでしょうが。
mule の入力ルーチンとかについても、他のソフトウェアから使えるようにライブラリだったらいいね、とかいう声を聞いたことがありますが、それを実装したという話を聞いたことがありません。やってみないとわからない困難とかでも、あるのでしょうか。
ちなみに、mule がよくできたソフトウェアだというのは、日本人だけの思い込みかもしれないと思っています。(ぼく自身も、よくできたソフトウェアだとは思っていますが)。たとえば、台湾でさえ Mule が普及していない [srad.jp]という現実があります。
とか、/usr/bin/button とか /usr/bin/label という感じでしょうか。おもしろそう。簡単にできそうな気もするけど、実際に手を動かしてみると、いろんな困難があるかも。作ってみてはいかがでしょうか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
誰にとって最強? (スコア:0)
どのレベルのGUI? (スコア:1)
Xに代わるシステムか、その他のOSに付随したWindow Systemフレームワークの
話かと思ったんですが、・・・みなさんGUIアプリケーションとかWindow Managerの話を
してらっしゃって、どのレベルから唾をつけるべきか混乱してます・・・。
#Xに代わるものとしては、ネットワーク透過性にセキュリティを組み込んだもの、
#ポリシーの明確なものが欲しいですねぇ・・・。
#あ、あとMI/MDの区分がはっきりしていて、VGAの性能をもっと引き出せる仕組みが
#あれば最高なんだけど。
#・・・その上で動くWindow ManagerやGUIアプリケーションは、わたし自身が想定してるものが
#ぼんやりしすぎてるので、明確なイメージを持てないです。
#・・・m17nフレームワークは2バイト文字圏の人が作ったものが欲しいな(苦笑)。
---- redbrick
Re:どのレベルのGUI? (スコア:1)
runeyokohama 氏のタレコミはツールキットのレベルの話のような気がしたんだけど。「OS 非依存」ということは、現在普及している Linux/BSD/Un*x/Windows/Mac/... などさまざまなシステムの上でそのまま使いたい、というニーズを表現しているのだと思うんですが、そうすると、OS そのものは解には当然なりえないけど、X Window System を変えるのもちょっと大ごとかな、と。
「言語非依存」って書いているので、ユーザからの観点ではなくて開発者からの観点でしょう。(それとも、ここで「言語」って自然言語のこと?)
たとえば Qt は国際化はそこそこいいし X でも Windows でも動くけど C++ という言語に縛られてしまう、とか。
Tk なんかはどうでしょう? X/Win/Mac で動くし、Tcl/Perl/Ruby/Python などが対応してるし、X 上では国際化がいまいちだけど、「Tcl/Tk 日本語版」なんてのもあるし。
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]という現実があります。
Re:どのレベルのGUI? (スコア:1)
ここ [kde.org]をご覧いただければ分かりますが、
「Qt(とKDE)をC++以外の言語から使えるようにしよう」というプロジェクトも
いくつか存在しています。
使ったことがないので、現状がどの程度なのかは分かりませんが。
Re:どのレベルのGUI? (スコア:1)
ご指摘のとおりツールキットレベルの話のつもりでタレコミました。よって開発者の視点がメインです。しかし利用者の満足が開発者の使命でありますから、高いユーザービリティを構築できるだけのポテンシャルがほしいですね。
QtやGTK、Tkは、今後の利用者のニーズに答えられるでしょうか? それより先に、必要とされるGUIを規定する必要もありますね。どちらにしても、難しい問題です。
(ちなみに私は、CUI好きですがGUIの可能性に*まだ*希望を持っています)
ツールキットレベルで言えば (スコア:1)
どうして Widget をコマンドにできないんだろうか?
各ウィジェットをコマンドにできて、
そのコマンドは好きな言語で実装できる、っていう設計があれば便利かなぁ、
と思っているんだけど。
# mishimaは本田透先生を熱烈に応援しています
/usr/bin/widget (スコア:1)
とか、/usr/bin/button とか /usr/bin/label という感じでしょうか。おもしろそう。簡単にできそうな気もするけど、実際に手を動かしてみると、いろんな困難があるかも。作ってみてはいかがでしょうか。
Re:/usr/bin/widget (スコア:1)
zope では、http://www.xx.org/animal/lion の形を、lionオブジェクトとして取り扱てているようです。
例えば、 lion/eat?food=zebra
では、lionオブジェクトのeatメソッドを、(food="zebra")と言う引数で呼び出しています。
file:///usr/bin/widget/Button オブジェクトで、引数はコマンドオプションにするとすればこんなかんじでしょうか。
/usr/bin/widget/Button -setLabel="Submit"
Re:/usr/bin/widget (スコア:1)
鵜呑みにしてみる?
Re:/usr/bin/widget (スコア:1)
Zope でそんな面白そうなことができるとは知らなかったな。
まあ、モノがないことにはそれ以上話が進まなかろうということで、
コマンドとして使える widget というものを実際に作ってみようと思う。
# mishimaは本田透先生を熱烈に応援しています
Re:/usr/bin/widget (スコア:1)
各Widget表示に必要な各種Object/Widgetのバイナリデータを管理し、さらにコマンドに対応するWidgetAPIを呼び出すようなサーバがあって、各コマンドはそのサーバと通信するようなものとして実装し、それぞれのオブジェクトは何らかの識別子で特定できて、、、
と、以前から妄想してたのですが、「これってtclshとか言わん? 」とか、「irbでrequire "gtk"とかとするのと同じ?」とか、「遅いんじゃなぁい?」とかの、自分自身からの突っ込みに勝てませんでした。確かに作る事を想像すると楽しそうなのですが。
#オブジェクトがやっぱり階層構造になるので、XMLで表現したらどうかとか、
#ディレクトリにするのもいいかなとかも妄想。お願い!Just for Fanな人。
実装の話になると (スコア:1)
tclsh だったら tcl、irb だったら ruby から離れられないところ。
GUIは(Xのレベルより)もっと抽象化できるはずだし、
その抽象度を保ちつつ各言語から分離できると思うのだ。
で、「言語から分離」する以上はどのスクリプトでも扱えるべきだと思うけど、
現状ですべてのスクリプト言語で同じように扱えるものというと標準入出力くらい。
だから、そこを通信回線にしてしまうのが手っ取り早いと思っているのだが、どうか。
もちろん、ネットワークで使いたければTCP の接続を標準入出力にしてしまって…
で構わんと思うのだが。もちろんクライアントの認証は必要だろうけど。
重さということだとプロセス数の多さが問題になりそうだけど、
「重い」と言ったら他のGUIも一絡げで否定できるし、
むしろ X 同様、サーバとクライアントが異なるマシンと考えれば…
そういうことから言えば、実装する意義は十分あるように思う。
XMLは、プロトコルのレベルで実装してしまうと
クライアント作成の敷居が急に高くなってしまうように思う
(クライアント→サーバは問題ないけど、サーバ→クライアントでは難しい。
awk で XML パースできる?と言われるとねぇ…
もっと長期的な視点では、XML 用の awk というか、
SAXのコマンドでの実装というか、そういうものが必要かもしれないが)。
でも、ディレクトリはおいしいと思う。
.../window
.../window/menu
.../window/menu/File
.../window/menu/Edit
.../window/menu/View
.../window/canvas
.../window/button1
.../window/button1/label
このディレクトリ構造そのものが、UIになってますよー。って感じかな。
# mishimaは本田透先生を熱烈に応援しています
Re:実装の話になると (スコア:1)
>その抽象度を保ちつつ各言語から分離できると思うのだ。
>で、「言語から分離」する以上はどのスクリプトでも扱えるべきだと思うけど、
(略)
>そこを通信回線にしてしまうのが手っ取り早いと思っているのだが、どうか。
本質的には賛成。でも、現状では言語からは独立できても、プログラムがツールキットにべったり依存してしまう。なんか嫌な感じです。機能を既存のツールキットの積集合に限定すると、ツールキットサーバというかダイアログサーバというかで吸収出来ますかね?
>でも、ディレクトリはおいしいと思う。
さらに妄想。各Widgetがディレクトリに対応していて、そのWidgetが管理する属性が.x_positionとかいう名前になっていると、、、。Widgetディレクトリの名前に命名規則を与えることで、描画の順序を規定したりもできるかなぁ、、、。
.../window/001:menu/001:File
とか。GUIの変更も、viでちょちょっとで出来ちゃったりとか。動的な内容変更も、rescanコマンドがツールキットサーバにメッセージを飛ばしてO.K.
#本当にこんな簡単なの?今まで誰もやっていないのは、何か穴があるかと思いますが、、、
#単にマシンパワーの問題で、こういう発想が無かっただけ?
Re:実装の話になると (スコア:1)
でも自分の考えでは、複数の widget をくっつけたりして
独自の widget も作成できるようにし、
それをサーバに簡単に組み込めることで解決を図ろうと思ってる。
[本物のサーバ] ⇔ [自作サーバ] ⇔ [クライアント]
自作サーバは独自拡張 widget についてのみ面倒を見て、
それ以外は全部本物のサーバに流すだけ。
通信プロトコルが単純なら自作サーバの作成もらくちんだと思うんだけど。
ディレクトリによるUIデザインは、インスタンスが複数できる場合はうまくいかないので、
たぶん読み込み専用のテンプレートになるんだと思う
(さもなければディレクトリまるごとコピー?)。
直感的な記述力は高そうな気がするんだけどなぁ…
# mishimaは本田透先生を熱烈に応援しています