歩み寄るGNOMEとKDE 71
ストーリー by Oliver
勝者はユーザ 部門より
勝者はユーザ 部門より
Ryuzi Kambe 曰く、 "リニューアルした CNET Japan より、GNOME 2.2 リリースを補足する記事がありました。この記事によると、リリースされた GNOME 2.2 には、X Window System のためのデスクトップ環境における相互運用性と共有技術向上のためのプロジェクト、freedesktop.org の仕様を取り入れており、Startup Notification(アプリケーションが常に起動中であることを示し、再度アプリケーションを起動することがないように知らせるシグナル) , icon themes(アイコンのテーマ), recent files(最近使ったファイル) thumbnail management(サムネイルの管理) などが、具体的にその仕様を反映しているということです。Bruecurve でもめたのも記憶に新しいですが、この記事では今週はじめに お互いのの設計ガイドライン(HIG:Human Interface Guide)の親和性を高めることについての検討を前向きに発表した、ということにも触れており、その流れの変化が感じられます。"
GNOMEもうだめぽ (スコア:1, 興味深い)
いいのに。。。
Re:GNOMEもうだめぽ (スコア:2, 興味深い)
KDE3.1と比べGnome2.2は速度面では勝っている。
まぁ、統合環境としては確実に負けている。
Gnome+OpenOffice.org+mozillaで
それなりの環境になっているが、
いろいろ手間がかかるからエンドユーザにはつらいかも。
WindowsXPユーザを移行させるならばKDE3になるんだろうな。
# gdm2カッコイイ!!!
PCにECC Registeredメモリの利用を推奨します。
Re:GNOMEもうだめぽ (スコア:1)
具体的にどんな操作をするのに遅いといっているのかが疑問。
むしろ、KDE3.1 で不満なのは付属の Window Manager の
機能がひどく貧弱なことです。軽快さは KDE3.0 から 3.1 に
なってとても改善されましたが、Sawfish のような高機能な
ウィンドウマネージャーに慣れてしまった身には満足できな
い点が多いです。
アプリケーションごとにウィンドウの装飾を選ぶとか、ウィン
ドウの位置とサイズを指定するとか、起動のショートカットを
定義するとか、1画面以上のワークスペースとか、フォーカス
しないアプリケーションの指定とか。
Re:GNOMEもうだめぽ (スコア:1)
KDE3.1 で不満なのは付属の Window Manager の機能がひどく貧弱なことです。
同感です. 個人的に一時KDE環境に移行しかけたのですが, このアプリケーション毎のウィンドウ挙動の設定が貧弱さに耐えきれずやめました. VJEのステータス表示ウィンドウ(ウィンドウの左下に出るやつ)にタイトルバーが出るのは... kwm以外のウィンドマネージャを無理無理使うこともできるのですが, KDEとの相性が良くなくて逆効果だったりしますし.
今はenlitenmentベースでkonquerorだけ(もちろんkinitなんかは裏で動いていますが)を単純なファイルマネージャとして使用するようにしています.
Re:GNOMEもうだめぽ (スコア:1)
Gnome2.2をmetacityで使っていますが、まず、起動が早い。
プログラムがさくさく動いているように思える。
KDE3.1は、「ぬゅとーん」と起動する。
かといってアニメーションを切るとフリーズしやすくなる。
視覚効果にだまされているだけかもしれませんが、
1ユーザとしての感想です。
PCにECC Registeredメモリの利用を推奨します。
Re:GNOMEもうだめぽ (スコア:1)
これをつけてコンパイルすると、小手先の最適化とは思えな
いほどに起動が速くなります。そこら中のウェブサイトに書
かれていますが、kdebase を
LDFLAGS="-z combreloc"
./configure --enable-objprelink
make && make install
とビルドしています。
視覚効果による起動をはやく見せるトリックがあるとしてもGnome2.2 より遅いということはないと思います。1.13GHz
Pentium3 にて konqueror が初動で 1 秒もかかりませんが、
Nautilus は初動が 2~3秒 かかる、という感じですから。
アニメーションを切るとフリーズしやすくなるというのは、
同感です。「ウィンドウの移動中にウィンドウの中身を表示
する」にチェックがついていないと、ウィンドウをドラッグ
しただけでフリーズしていました。
Re:GNOMEもうだめぽ (スコア:1)
また、objprelink2を使うなら、確かconfigureのオプションはいらなかったと思います。
objprelink2とcombrelocとの関係は・・・忘れてしまった(苦笑
とりあえず、このレポート [sourceforge.net]なんか見る限り、
objprelink1とobjprelink2では雲泥の差のような気がします。
この話については、Kdeveloperのこのメール [kde.gr.jp]や
このメール [kde.gr.jp]を参照して下さい。
Re:GNOMEもうだめぽ (スコア:1)
アプリケーションの起動は Windows とおなじようにメニューエディタでできましたね。すいません。
> 1画面以上のワークスペースというのはXineramaじゃダメなのかな?
いわゆる viewport です。
> ウィンドウの位置とサイズの指定や、フォーカスしない
> アプリケーションの指定ってどういう場合に便利なのでしょうか?
たとえば、gkrellm というシステムモニタがあるのですが、これは常に表示しているだけで、Alt+Tab で巡回するときにフォーカスしなくて良いのです。
他にも手抜きで作った自作の通知ウィンドウにウィンドウ装飾がついてしまったり(もちろんプログラム側で装飾がつかないようにすれば良いのですが、それくらいウィンドウマネージャがやって欲しい。)、などなど。
Re:GNOMEもうだめぽ (スコア:2, 参考になる)
KDEのほうが、コンパイル時間も長く、動作も重く、
KDE3.1のKonquerorのほうが、nautiusよりもバギーだと感じます。
(両方とも、PentiumIII、500MHz、メモリ192MB上で
動作させています。KDEもGnomeも、
実用できる速度で動作します。)
実際、自分もGnome2.2をコンパイルしてみるまでは
ここまで(Gnomeが)良く出来ているとは思いませんでした。
私の設定が悪いのか、Konsoleで日本語フォントを使うと
文字間隔が非常に長く、使用するに耐えられないのですが、
gnome-terminalは、(無論アンチエイリアシングがかかっていて)
日本語フォントも、適切な文字間隔で表示してくれました。
一度、試してみては。
Re:GNOMEもうだめぽ (スコア:1)
今現在は、GNOME 2.0 使ってますが、1.4 から 2.0 になった時点でずいぶん(結構劇的に)パフォーマンスが向上してたように思います。無駄な描画がずっと少なくなったのが大きいのかな。1.4 を見てGNOMEは重いと思ってる人も多いんじゃないかな。2.0 から 2.2 でもパフォーマンスが良くなってるんでしょうか? あれから更に向上できるとなると凄いと思うのです。
の
Re:GNOMEもうだめぽ (スコア:1)
うーん。そうですかー。?
うちでは逆に目に見えて遅くなりました。
こういう情報をよく目にしますが・・・。同意しかねる。
# KDEみたく、デスクトップ全体に一種独特の空気がないぶん、GNOMEのほうが好きなんですが。
hoihoi-p 得意淡然、失意泰然。
Re:GNOMEもうだめぽ (スコア:1, 参考になる)
> 向上してたように思います。
> うーん。そうですかー。?
> うちでは逆に目に見えて遅くなりました。
> こういう情報をよく目にしますが・・・。同意しかねる。
どちらも環境を書いてくれないとので読み手としてはどちらの情報も役立てられません。こういう話は自分の足場を明らかにしてくれないと。
Re:GNOMEもうだめぽ (スコア:1)
環境:VineSeed (セルロン667、RAM-256MB、GIGABYTE GA-6VXE7+、 S3 Savage4)
hoihoi-p 得意淡然、失意泰然。
Re:GNOMEもうだめぽ (スコア:0)
コンパイル時間はユーザには関係ないし、そもそもc++が
時間かかるのは当たり前
>私の設定が悪いのか、Konsoleで日本語フォントを使うと
>文字間隔が非常に長く、
設定が悪いです
Re:GNOMEもうだめぽ (スコア:2, おもしろおかしい)
「北斗のK」と「GNOME野郎 A チーム」というネーミングの時点で既に勝負あったと思う。
Re:GNOMEもうだめぽ (スコア:1)
*個人的には*前者に軍配をあげます。
#国民投票ネタ?
Re:GNOMEもうだめぽ (スコア:1, 興味深い)
KDEがライセンス的に譲歩してくれない限り身を引くとは思えませんが(w
# それなりに譲歩してるような気はするけどRSM的には
# まだまだなんでしょうねぇ
KDEのライセンス (スコア:1, 参考になる)
ただ、ライセンス上は問題がなくなったとはいえ、いち企業が開発する Qt に全面的に依存する KDE は、開発の主導権が完全にコミュニティにあるわけではないという点で、問題があると感じる人もいると思います。
Re:GNOMEもうだめぽ (スコア:2, 参考になる)
QTが基本ライブラリなのに、LGPLじゃなくて、GPLって部分でしょうね。
クローズドのKDE向けソフトはQTを使わないか(KDE向けに書かない)、または QTライセンスを選んでライセンス料を支払うって選択になるわけです。
QTのLINUX以外の版のライセンスはどうなんでしょう?
WINDOWS版QTは全然フリーじゃないって思ってましたけど。
LINUX専用のフリーソフトウエアを作る人達には問題はないでしょうが、
QTはLGPLじゃないので、商用ソフトはライセンスを払ってクローズソースにする必要がある。
作ったソフトをWINDOWSで動かす際に、利用者にとってはフリーじゃなくなる。
って、感じかな? QTのライセンスの件ちゃんと知ってはいないので、知っている人のフォローをお願いします。
Gnome/GTKでは 上の問題は起きないので、それが企業がGnomeに走る理由だと思います。
共有の部分は共有、占有の部分は占有。共有の部分はLGPLであくまで完全共有化
(占有ソフトも共有ソフト(ライブラリ)をフリーで使えるって事で、企業も問題なくライブラリーに貢献できるって事)
RMS的には、LGPLの Lを Library から Lesser に 変えるときに、占有ソフトに塩を送りすぎないように(?)、ライブラリーでも GPLにするべきものは、GPLにすべきだって 言ってましたよね。
Re:GNOMEもうだめぽ (スコア:1, 参考になる)
Re:GNOMEもうだめぽ (スコア:1)
ちょっと調べてみました。いろいろな版はここからたどれます [trolltech.com]が、WINDOWSとMacOSXの QTは、非商業向けライセンスと言うことです。
無料の配付でも開発のセットアップが商業であるとライセンスを買う必要があるそうですから、IBMが KDE用の無料かつコピーレフトのソフトのWINDOWS版を公開したら、IBMはライセンス料を支払う義務があるようです。
WINDOWS/MacOSX用のQtソフトを個人が個人の家のマシンで開発して、無料で公開する場合のみ、Qtの開発ライセンスは不要みたいです。
そういうわけですから、全部が全部コミュニティで共有されているGnome/GTKに比べると、共有度は低くなりますよね。特に企業開発者に取っては。
例えば、OpenOfficeが Gnome/GTK を使ってもフリーソフトウエアとしてどこの環境でも主張できると思いますが、KDEを使うと WINDOWS/MacOSXのOpenOfficeは フリーソフトウエアではないです。
所でですね、QtのX11用GPL版を元に WINDOWSに移植したら、それはGPLで公開が出来るはずだと思うけど、そうなのかな? LGPLに移行することは出来ないですが、Qtの別のブランチを作って配付することも出来るんですよね?
Re:GNOMEもうだめぽ (スコア:1)
時間がないので、ポインタだけで申し訳ないですが、
すでにそのような動きは存在しています [sourceforge.net]。
Re:GNOMEもうだめぽ (スコア:1)
> うーん、意味がいまいちわかんないですね。
はい、ライセンス料を払わずに『ソース不公開のKDE向けのソフト』を配付することは出来ないってことですが、冗談で上の表現を使いました。笑えなかったらゴメン。
>また、開発する際に、QtのGPLとkdelibsのLGPLとはどのように影響するのか
kdelibs は Qtにリンクして使う限り、GPL/Qtライセンスに留まると思います。LGPLとしての扱いはできないと思います。
『ソースを閉じる』/『ライセンス料を払わない』で済ますためには、アップルのしたように、Qtとのリンクを切ることしかないと思います。(または、GPLの Qt/X11を MacOSXに移植する?)
実は、『QtのライセンスをGPLでよしとする』のか、『LGPLになるまでフリーソフトウエアのベースに使うべきではない』とするのか、議論が起きないのを不思議に思っていました。
企業の戦略としては、『LGPLをベースライブラリに適用しているGnome/GTKを可能なかぎり採用する』のは、ごく当然の選択だと思います。
Re:GNOMEもうだめぽ (スコア:0)
多様性と協調関係 (スコア:0)
つか、多様性を維持するためには排他的関係ではなく積極的な協調関係が必要だと痛感する今日このごろ。
Re:多様性と協調関係 (スコア:0)
Re:多様性と協調関係 (スコア:0)
パソコンが高速化して、両方の速度差がほぼ0になったとしても、
「たくさんプロセスが動くからGnomeやKDEは嫌い」という
ユーザの精神衛生上の?(笑)理由や、
単に、画面がすっきりしていたほうが良い、という理由で
WMを利用する人がいてもよいのではないでしょうか。
ただ、「DeskTopを征服する!(Counquer your Desktop)」と
標榜するKDEは、どちらかといえば、旧来のものや他の環境を
置き換えようとする方向で
Re:多様性と協調関係 (スコア:0)
いまはKDEやGnomeは「デスクトップ」という概念です。
Re:多様性と協調関係 (スコア:0)
Re:多様性と協調関係 (スコア:1)
多分ウィンドウマネージャが何かを誤解していると思います。
「デスクトップ環境を救助」 [linux.or.jp]とその後の2、3ページを読みましょう。
Re:多様性と協調関係 (スコア:0)
新旧の構成でどうしても違う点は、プログラム間通信ということになるんでしょうか。
Re:多様性と協調関係 (スコア:1)
デスクトップ(机)というのは個々のファイルやアプリ(ノート、本、鉛筆)を連携させて扱うという概念です。実際のGUI機能としてはファイルその他のオブジェクトのドラック&ドロップ、統一ルック&フィール、共通ダイアログ、埋め込み文書なんかになるでしょう。
また比較するのであれば、Gnome、KDE上で対応アプリケーションやアプレットと非対応アプリケーションを比較するべきです。twmなどで比較しても優位性が出る機能は見えないでしょう。
たとえばデスクトップ対応のアプリでは、フォントだけじゃなく(アプリケーション)メニューやツールバーのスタイルなんかは管理ツールで統一的にスタイルを変更できるわけです。
Re:多様性と協調関係 (スコア:1)
> トがきれいに見えてユーザーインターフェイスに統一感があるこ
> とが「粒度が違う」ということなんでしょうか。
UnixのCLI、twm、現在のGnomeなどを比較してみたら良いと思います。
デスクトップのメタファーの一例ですが、「ファイル」という概念に対し「ファイルアイコン」という視覚的要素があります。このように「デスクトップ」を卓上で実際に使われているものに視覚化することなどがデスクトップと呼ばれた所以です。( 参照 [no-ip.com] )
この点ではWindowsは「デスクトップ」のメタファーを捨てている事が多いのが残念です。たとえば、壁紙とよばれるものが卓上に張られるのは不自然です。マックでもOSXになってかなり捨て去られたような気がします。GnomeやKDEにはより洗練された「デスクトップ」またはそれに代わるものを期待しています。
Re:多様性と協調関係 (スコア:0)
GNOMEやKDEが考えるデスクトップの概念は、日常的なPC操作を行う環境といったところではないでしょうか。
漠然とした言葉のような気がしますが、そのくらい色々な機能を提供するものだと思うので、下手に表現出来ません。(^^;)
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 などなど) があるかないかではアプリケーションの作成しやすさに雲泥の差があります。また、いちいち自分でプリンタのセットアップダイアログから (コモン・ダイアログ)、常駐用の小さなウィンドウから (TaskBar、Panel 上の applet)、preference システムから、何から何まで作らなきゃいけない、となったら、サンデープログラマはみんなさじを投げてしまうでしょう。そういう意味で、アプリケーションに対して、ある程度抽象化されたパーツを提供する「デスクトップ環境」は、特にプログラマにとって非常にメリットがあります。
そしてもちろん、プログラマにメリットがある、ということは、それだけ豊富なアプリケーションが揃う可能性が高まる、というわけで、ユーザにとっても大きなメリットがあるわけです。
僕はこんな風に理解していますけれども。
Only Jav^Hpanese available :-)
Re:多様性と協調関係 (スコア:0)
それが一番重要なんですが。ファイルなどのドラッグ&ドロップを含めて。
> 疑問なのは、ユーザから見た
Re:多様性と協調関係 (スコア:1)
それはちょっと違うと私は考えます. ここで述べられた物は全て単なる部品にすぎません. デスクトップ環境の本質は, アプリケーション間通信(端的にはカット・アンド・ペースト)であり, WindowsのAPIではそれが部品に組み込まれているが故にデスクトップ環境としての協調性が取れているわけです.
でも, ここで私はさらにもう一段考えるのです. アプリケーション通信の大部分(全てではありません)は単なるファイルアサインの動的設定に過ぎないのではないかと.
例えばシェルやJCLではプログラムに対する入出力のアサインを起動時に静的に決定します. しかし多くの対話型プログラムでは, 実行時に動的にアサイン決定を行うことが多くあります. 普通はこれを個々のプログラムで独自に実装するわけですが, この部分を共通化しプログラムから独立したユーザインターフェイスを介してアサインを行う機構こそがデスクトップとして必要な機能のほとんどだと私は考えます.
具体的には, 高機能なファイルマネージャとそれに対するAPIさえ有れば大仰な統合デスクトップ環境はいらないと思っています. おそらくこのような考え方は, 専門化したツールのゆるやかな結合という古典的なUNIXの思想に基づく物でしょうから, 現在においてはあまり賛同が得られるとは思いませんが.
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っすね。
KDE/GNOME To Cooperate On Interface Guidelines (スコア:1)
dot.kdeに出ていたニュースです。
KDE/GNOME To Cooperate On Interface Guidelines [kde.org]
-- Che Che - Bye Bye
Re:つーか (スコア:2, すばらしい洞察)
(特にウィンドウを多く開いている場合)
現時点でのデスクトップとしての完成度は、確かに Windows が勝っていると感じますが、
ウィンドウマネージャとしては逆に低機能ではないでしょうか。
Re:つーか (スコア:1)
同感。
Windows,ウィンドウを多く開いている場合は、最悪。
>(特にウィンドウを多く開いている場合)
なんのアプリケーションが動いているのかは、さっぱりわからないし、切り替えにくい。動作も不安定。
OS/2のWPSが良い、最小化ウィンドウが好きだった。
I am grateful to everyone and you.
Re:つーか (スコア:1)
Linux Planet に、GNOME 版 [linuxplanet.com] と KDE 版 [linuxplanet.com]のデスクトップのスクリーンショットが掲載されています。
GNOME 版については、Flash でその動作の様子がムービーで公開されています [redhat.com](ちょっと Mozilla が速く起動しスギのような気もしますが)。
- Ryuzi Kambe -
Re:つーか (スコア:1, すばらしい洞察)
これが文字化けしないのが当然、と考えるユーザーがでてきたってのは、やはりGnome/KDEの成果なのではないだろうか。
アプリの開発はユーザー中心であるべきなので、文字化けしないのが当然、という考え方が正しいはずなんだが、数年前なら、gtk+-1.0とQt-2.xじゃ内部コードが違うからできないのが当然、という開発者の甘えが、さも正当な意見であるかのようにまかり通ってたから。
Re:つーか (スコア:1)
たぶん、遅くともKDE3.2では大丈夫になるんじゃないかなあ。
(私がどうこうしたわけではないが)
少なくとも、パッチ無しのQt-3.1.2-snapshotとgeditで試した限りは
ちゃんとコピーアンドペーストできたのだけど。