アカウント名:
パスワード:
runeyokohama 氏のタレコミはツールキットのレベルの話のような気がしたんだけど。「OS 非依存」ということは、現在普及している Linux/BSD/Un*x/Windows/Mac/... などさまざまなシステムの上でそのまま使いたい、というニーズを表現しているのだと思うんですが、そうすると、OS そのものは解には当然なりえないけど、X Window System を変えるのもちょっと大ごとかな、と。
「言語非依存」って書いているので、ユーザからの観点ではなくて開発者からの観点でしょう。(それとも、ここで「言語」
とか、/usr/bin/button とか /usr/bin/label という感じでしょうか。おもしろそう。簡単にできそうな気もするけど、実際に手を動かしてみると、いろんな困難があるかも。作ってみてはいかがでしょうか。
より多くのコメントがこの議論にあるかもしれませんが、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? (スコア: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は本田透先生を熱烈に応援しています