アカウント名:
パスワード:
あくまでプログラムとしてはウィンドウマネージャ+αなものでしょう。
現在のGNOMEやKDEの役割は、むしろ+αの部分がメインですね。 ;; ウィンドウマネージャを
GNOMEやKDEは従来のウィンドウマネージャに置き換わるのではなく、まったく別のものだと言う事です。
旧来の「Xserver + ウィンドウマネージャ(WM) + 諸々のアプリケーション」という構成に対し、「Xserver + {GNOME|KDE}統一パッケージング」という違いはわかるんです。また、環境として一切合切を提供することにより、統一性に優れ、使い勝手も特に初心者にとっては
それはちょっと違うと私は考えます. ここで述べられた物は全て単なる部品にすぎません. デスクトップ環境の本質は, アプリケーション間通信(端的にはカット・アンド・ペースト)であり, WindowsのAPIではそれが部品に組み込まれているが故にデスクトップ環境としての協調性が取れているわけです.
でも, ここで私はさらにもう一段考えるのです. アプリケーション通信の大部分(全てではありません)は単なるファイルアサインの動的設定に過ぎないのではないかと.
例えばシェルやJCLではプログラムに対する入出力のアサインを起動時に静的に決定します. しかし多くの対話型プログラムでは, 実行時に動的にアサイン決定を行うことが多くあります. 普通はこれを個々のプログラムで独自に実装するわけですが, この部分を共通化しプログラムから独立したユーザインターフェイスを介してアサインを行う機構こそがデスクトップとして必要な機能のほとんどだと私は考えます.
具体的には, 高機能なファイルマネージャとそれに対するAPIさえ有れば大仰な統合デスクトップ環境はいらないと思っています. おそらくこのような考え方は, 専門化したツールのゆるやかな結合という古典的なUNIXの思想に基づく物でしょうから, 現在においてはあまり賛同が得られるとは思いませんが.
単なるファイルアサインの動的設定に過ぎないのではないか
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
GNOMEもうだめぽ (スコア:1, 興味深い)
いいのに。。。
多様性と協調関係 (スコア:0)
つか、多様性を維持するためには排他的関係ではなく積極的な協調関係が必要だと痛感する今日このごろ。
Re:多様性と協調関係 (スコア:0)
Re:多様性と協調関係 (スコア:0)
あくまでプログラムとしてはウィンドウマネージャ+αなものでしょう。
しかし、アプリケーションが{GNOME | KDE}上で動くことを前提として作成されるようになるかもしれません。
Linux(別に他のOSでもいいんですが、現実的に見て)が Windowsに置き換わるデスクトップPC向けOSとして成長していった際に、必須環境となる可能性は高いでしょう。
;; というか、もうなってるのかな(^
Re:多様性と協調関係 (スコア:0)
ちょっと説明がうまくないかなと思ったので、自己フォローです。
現在のGNOMEやKDEの役割は、むしろ+αの部分がメインですね。 ;; ウィンドウマネージャを
Re:多様性と協調関係 (スコア:0)
旧来の「Xserver + ウィンドウマネージャ(WM) + 諸々のアプリケーション」という構成に対し、「Xserver + {GNOME|KDE}統一パッケージング」という違いはわかるんです。また、環境として一切合切を提供することにより、統一性に優れ、使い勝手も特に初心者にとっては
Re:多様性と協調関係 (スコア:1)
出来ること、の絶対的な差異なんてもちろん存在しないと思いますヨ (それを言ったら MS-DOS でだって何でも出来る!)。
僕が思う「デスクトップ環境」の利点は、ズバリ、プログラムの書きやすさ、です。Windows や Java で GUI のプログラムを書いたことのある人ならばお分かりかと思いますが、高機能なコンポーネント (TreeView や ListView などなど) があるかないかではアプリケーションの作成しやすさに雲泥の差があります。また、いちいち自分でプリ
Only Jav^Hpanese available :-)
Re:多様性と協調関係 (スコア:1)
それはちょっと違うと私は考えます. ここで述べられた物は全て単なる部品にすぎません. デスクトップ環境の本質は, アプリケーション間通信(端的にはカット・アンド・ペースト)であり, WindowsのAPIではそれが部品に組み込まれているが故にデスクトップ環境としての協調性が取れているわけです.
でも, ここで私はさらにもう一段考えるのです. アプリケーション通信の大部分(全てではありません)は単なるファイルアサインの動的設定に過ぎないのではないかと.
例えばシェルやJCLではプログラムに対する入出力のアサインを起動時に静的に決定します. しかし多くの対話型プログラムでは, 実行時に動的にアサイン決定を行うことが多くあります. 普通はこれを個々のプログラムで独自に実装するわけですが, この部分を共通化しプログラムから独立したユーザインターフェイスを介してアサインを行う機構こそがデスクトップとして必要な機能のほとんどだと私は考えます.
具体的には, 高機能なファイルマネージャとそれに対するAPIさえ有れば大仰な統合デスクトップ環境はいらないと思っています. おそらくこのような考え方は, 専門化したツールのゆるやかな結合という古典的なUNIXの思想に基づく物でしょうから, 現在においてはあまり賛同が得られるとは思いませんが.
Re:多様性と協調関係 (スコア:0)
Re:多様性と協調関係 (スコア:1)
/*
これは例えば Windows ならば COM、KDE ならば DCOP、GNOME ならば CORBA、ということになるのかな? 教えて、偉い人。
*/
僕の理解では、これらの現存する抽象化インターフェイスは、あるオブジェクトに関する method signature の公開と、そのインスタンスへのバインディング、という思想で基本的には作成されているように思うのですが、「ファイル」を中心に据える、という考え方は unique ですね。しかし、「オブジェクト」がその成り立ちからしてそもそも有目的的で method 自体が意味を持つのに対し、「ファイル」それ自身は所詮無目的な入れ物に過ぎないことを考えると、その構造に関しても何らかの約束ごとを設けなければ結局1から全て作成するのと大差ないことになってしまいそう。で、例えば XML で構造を定義したりなんかしたりすると、ああ、これは SOAP の世界そのもの、って感じになってきますね。
Only Jav^Hpanese available :-)
Re:多様性と協調関係 (スコア:1)
DCOPはアプリ間通信プロトコルで、部品(コンポーネント)としてはどちらかと言えば利用するのはKPartsの方になります。
KIOも含めてもいいかな。
デスクトップ環境のメリットが大きく見えてくるのはコンポーネント周りがしっかりとしてきて、種類が増えてきたときではないでしょうか。
たとえば、KDEでhtml表示と言えばkhtmlですが、Geckoを使うようにも出来ます。
ユーザ側でtext/htmlのコンポーネントにkmozilla(Geckoを使うためのKDE用コンポーネント)を指定しておけば、
konquerorだけでなく、KDEアプリでtext/htmlを表示する際にはGeckoを使うことができます。
コンポーネントの選択の利点が大きいのはEditorでしょう。
KDEのデフォルトはKateですが、KVimがすでにKTextEditorインターフェースに対応しており、
gideonなどではKateではなく、KVimを埋め込みのエディタとして利用できるはずです。
KMailもKDE3.2に向けてKTextEditor対応を行なっており、
近いうちにエディタコンポーネントを選択できるようになるはずです。
コンポーネントを活用することで、
開発者側は開発にかかる手間を減らし、なおかつ、質をあげることができ、
ユーザ側はアプリが変っても同じコンポーネントを利用できるので、設定や操作が同じものを使える。
というのが従来の環境では実現できない利点であると思います。
-- Che Che - Bye Bye
Re:多様性と協調関係 (スコア:1)
>アプリケーション間通信(端的にはカット・アンド・ペースト)であり,
>例えばシェルやJCLではプログラムに対する入出力のアサインを起動時に静的に決定します. しかし多くの対話型プログラム
>では, 実行時に動的にアサイン決定を行うことが多くあります. 普通はこれを個々のプログラムで独自に実装するわけです
賢いパイプで思い出しましたが、
スラド本家で以前、Pipes In GUI's [slashdot.org]という議論が有ったそうです。
俺は英語がよくわかんないので内容は把握してませんが(笑)、たぶんかなり近い話題だったのではないかと。
さて。それをパイプと呼ぶべきかどうかは別問題としても、正直いって、
OOPに慣れた者(たとえば俺)がUnix Pipeのやり方を見ると、歯がゆさすら感じてしまうんです。
なんせご指摘の通り、起動時に静的にしか結合できない世界。辛すぎます。
OOPではObject間の着脱を実行時にバリバリやるのは茶飯事です。
#個人的には、MAXとかPureDataとかの言語環境を思い出します。Object間を配線し(直し)てプログラムを記述(改造)できます。
しかも接続先の数だって自由です。
Unix Pipeだと入力1つに出力2つですね。特に入力(stdin)は原理的に1つにならざるを得ないっすね。
入力の流れ込みに"依存"してプログラムが動くペースが決められるという構図にしてしまったばっかりに、
入力の数は決定してしまうわけです。
#ところで、Unixにゃselect()って関数があるんでしたよね。
#あれの待ち受けディスクリプタの数は、待ち中に追加/削除出来ないんでしょうか?それこそ関数の起動時(笑)ではなく。
同じ計算機ソフトなのに、この差は何なんでしょう?(T_T)
まあ、そう設計してしまったからだ、と言ってしまえばそれまでですが、ね…
で、OOP屋から見れば「デスクトップ」も「オブジェクト」のサブクラスなんです(笑)。
モノの比喩なんです。
机や机上のモノ(鉛筆や紙…)を想像してみて、それらが「起動時(って何だ??)に静的に」だけ関係を設定できる、
なんてなことになったら、ちょっとデスクワークにならないでしょうね。
どんなデスクワーク初心者だって、必要な時に書類をクリップで留めなおすことくらいすると思います(^^;
細かくいえばこの差は、プログラムを「実行する(される)」ものと捉えるか、それとも
「状態を持ってる」ものと捉えるか、のパラダイムの違いだと思います。
「実行する」という考え方をしてしまった瞬間に、起動パターンと入力がせいぜい1つづつしかない
というフレームワークのアーキテクチャが生まれ、それに縛られてしまうわけです。
OOPなら状態の塊と実行単位とは別問題なんで、Method(起動パターン)を複数持ったり、
入出力を複数持ったり、更にいえば複数のスレッドに同時に見を晒すことだって厭わないという、
「自然な」モデルになる。つまり「モノ」の感覚っすね。
#クリップを留めるのが実行のうちか?と思ったアナタは正解。OOPというかモノの世界では、
#なんでもかんでも「実行」と呼ぶこたぁないんです。
結局、Unix Pipeの世界観から解脱しない限り、作って意味のある「デスクトップ」環境は
成しえなかった、と考えるのが妥当なのだと思います。
だから、
>具体的には, 高機能なファイルマネージャとそれに対するAPIさえ有れば大仰な統合デスクトップ環境はいらないと思って
敢えて言えば、「APIが」あるかどうかというよりも、それ以前に、
OOPやそれに似たパラダイムを持ち込むかどうか、という点に
違いが顕在化すると思います。
#まあ、イベントループ関数に突入!でも一応のものは作れるんですけど、なんか代用品くさいっすね。
>おそらくこのような考え方は, 専門化したツールのゆるやかな結合という古典的なUNIXの思想に基づく物でしょうから, 現在においてはあまり賛同が得られるとは思いませんが.
Unixにだって巨大なフレームワークがあり、それに基づいて我々はアプリを書いています。
つまり、アプリごとに唯一存在するmain()メソッド(笑)とか、stdin/out/errとかが存在する、
というフレームワークです。
#ちなみにWindowsのアプリは、WinMainという唯一のClassMethod(Constructor?)と、WinProcという唯一のInstanceMethodを持っていますね。つまり2つあるわけです。
#一方我らがUnixには前者の相当品であるmainしかなく、いったん生成されたProcessInstanceに後から介入する術は基本的には無い。残念。
そのフレームワークが、何かちょっと違うフレームワークに置き換わる、
Re:多様性と協調関係 (スコア:1)
パソコン(?)の使い勝手の世界は、だんだんとSmalltalkみたいなものに近づいていくのかな(^^;
で、そう考えると、Unixのプロセスモデルって、その分野へはあんまり貢献しないんだよね。むしろ時として邪魔。
Unixは基本的に全ての(プログラム間の)繋がりは縦の関係。"実行"という文脈に縛られた関係。
でも実際にプログラムを作ろう/使おうとすると、横の関係のほうが便利であることが結構多いんだよね。
特にデスクトップなどのリアルワールド(曲りなりにも)メタファだと、その傾向が顕著。つまりObjectっすね。
UNIX素人ですか? (スコア:0)