アカウント名:
パスワード:
あくまでプログラムとしてはウィンドウマネージャ+αなものでしょう。
現在のGNOMEやKDEの役割は、むしろ+αの部分がメインですね。 ;; ウィンドウマネージャを
GNOMEやKDEは従来のウィンドウマネージャに置き換わるのではなく、まったく別のものだと言う事です。
旧来の「Xserver + ウィンドウマネージャ(WM) + 諸々のアプリケーション」という構成に対し、「Xserver + {GNOME|KDE}統一パッケージング」という違いはわかるんです。また、環境として一切合切を提供することにより、統一性に優れ、使い勝手も特に初心者にとっては
それはちょっと違うと私は考えます. ここで述べられた物は全て単なる部品にすぎません. デスクトップ環境の本質は, アプリケーション間通信(端的にはカット・アンド・ペースト)であり, WindowsのAPIではそれが部品に組み込まれているが故にデスクトップ環境としての協調性が取れているわけです.
でも, ここで私はさらにもう一段考えるのです. アプリケーション通信の大部分(全てではありません)は単なるファイルアサインの動的設定に過ぎないのではないかと.
例えばシェルやJCLではプログラムに対する入出力のアサインを起動時に静的に決定します. しかし多
より多くのコメントがこの議論にあるかもしれませんが、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ではプログラムに対する入出力のアサインを起動時に静的に決定します. しかし多
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)
パソコン(?)の使い勝手の世界は、だんだんとSmalltalkみたいなものに近づいていくのかな(^^;
で、そう考えると、Unixのプロセスモデルって、その分野へはあんまり貢献しないんだよね。むしろ時として邪魔。
Unixは基本的に全ての(プログラム間の)繋がりは縦の関係。"実行"という文脈に縛られた関係。
でも実際にプログラムを作ろう/使おうとすると、横の関係のほうが便利であることが結構多いんだよね。
特にデスクトップなどのリアルワールド(曲りなりにも)メタファだと、その傾向が顕著。つまりObjectっすね。