パスワードを忘れた? アカウント作成
4952 story

歩み寄る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)の親和性を高めることについての検討を前向きに発表した、ということにも触れており、その流れの変化が感じられます。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2003年02月10日 6時22分 (#255196)
    正直、GNOMEはもうKDEに追いつけないと思う。さっさと身を引けば
    いいのに。。。
    • by pantora (11989) on 2003年02月10日 8時12分 (#255219)
      >GNOMEはもうKDEに追いつけないと思う。

      KDE3.1と比べGnome2.2は速度面では勝っている。
      まぁ、統合環境としては確実に負けている。
      Gnome+OpenOffice.org+mozillaで
      それなりの環境になっているが、
      いろいろ手間がかかるからエンドユーザにはつらいかも。

      WindowsXPユーザを移行させるならばKDE3になるんだろうな。

      # gdm2カッコイイ!!!
      --
      PCにECC Registeredメモリの利用を推奨します。
      親コメント
      • by shunak (3585) on 2003年02月10日 12時45分 (#255396)
        KDE3.1 が Gnome2.2 より遅いなんてことはないと思います。
        具体的にどんな操作をするのに遅いといっているのかが疑問。

        むしろ、KDE3.1 で不満なのは付属の Window Manager の
        機能がひどく貧弱なことです。軽快さは KDE3.0 から 3.1 に
        なってとても改善されましたが、Sawfish のような高機能な
        ウィンドウマネージャーに慣れてしまった身には満足できな
        い点が多いです。

        アプリケーションごとにウィンドウの装飾を選ぶとか、ウィン
        ドウの位置とサイズを指定するとか、起動のショートカットを
        定義するとか、1画面以上のワークスペースとか、フォーカス
        しないアプリケーションの指定とか。
        親コメント
        • by SteppingWind (2654) on 2003年02月10日 13時41分 (#255454)

          KDE3.1 で不満なのは付属の Window Manager の機能がひどく貧弱なことです。

          同感です. 個人的に一時KDE環境に移行しかけたのですが, このアプリケーション毎のウィンドウ挙動の設定が貧弱さに耐えきれずやめました. VJEのステータス表示ウィンドウ(ウィンドウの左下に出るやつ)にタイトルバーが出るのは... kwm以外のウィンドマネージャを無理無理使うこともできるのですが, KDEとの相性が良くなくて逆効果だったりしますし.

          今はenlitenmentベースでkonquerorだけ(もちろんkinitなんかは裏で動いていますが)を単純なファイルマネージャとして使用するようにしています.

          親コメント
        • by pantora (11989) on 2003年02月10日 21時10分 (#255725)
          >KDE3.1 が Gnome2.2 より遅いなんてことはないと思います。

          Gnome2.2をmetacityで使っていますが、まず、起動が早い。
          プログラムがさくさく動いているように思える。

          KDE3.1は、「ぬゅとーん」と起動する。
          かといってアニメーションを切るとフリーズしやすくなる。

          視覚効果にだまされているだけかもしれませんが、
          1ユーザとしての感想です。
          --
          PCにECC Registeredメモリの利用を推奨します。
          親コメント
          • by shunak (3585) on 2003年02月12日 5時14分 (#256694)
            prelink と combreloc を使ってコンパイルしていますか?
            これをつけてコンパイルすると、小手先の最適化とは思えな
            いほどに起動が速くなります。そこら中のウェブサイトに書
            かれていますが、kdebase を
            LDFLAGS="-z combreloc"
            ./configure --enable-objprelink
            make && make install
            とビルドしています。

            視覚効果による起動をはやく見せるトリックがあるとしてもGnome2.2 より遅いということはないと思います。1.13GHz
            Pentium3 にて konqueror が初動で 1 秒もかかりませんが、
            Nautilus は初動が 2~3秒 かかる、という感じですから。

            アニメーションを切るとフリーズしやすくなるというのは、
            同感です。「ウィンドウの移動中にウィンドウの中身を表示
            する」にチェックがついていないと、ウィンドウをドラッグ
            しただけでフリーズしていました。
            親コメント
            • by Daicki (4060) on 2003年02月12日 20時48分 (#257224) 日記
              objprelinkを使うなら、objprelink2 [sourceforge.net]にした方が良いと思います。
              また、objprelink2を使うなら、確かconfigureのオプションはいらなかったと思います。
              objprelink2とcombrelocとの関係は・・・忘れてしまった(苦笑

              とりあえず、このレポート [sourceforge.net]なんか見る限り、
              objprelink1とobjprelink2では雲泥の差のような気がします。

              アニメーションを切るとフリーズしやすくなるというのは、同感です。「ウィンドウの移動中にウィンドウの中身を表示する」にチェックがついていないと、ウィンドウをドラッグしただけでフリーズしていました。
              この話については、Kdeveloperのこのメール [kde.gr.jp]や
              このメール [kde.gr.jp]を参照して下さい。
              親コメント
    • by Anonymous Coward on 2003年02月10日 10時20分 (#255285)
      Gnome2.2とKDE3.1を両方コンパイルした身としては

      KDEのほうが、コンパイル時間も長く、動作も重く、
      KDE3.1のKonquerorのほうが、nautiusよりもバギーだと感じます。

      (両方とも、PentiumIII、500MHz、メモリ192MB上で
      動作させています。KDEもGnomeも、
      実用できる速度で動作します。)

      実際、自分もGnome2.2をコンパイルしてみるまでは
      ここまで(Gnomeが)良く出来ているとは思いませんでした。
      私の設定が悪いのか、Konsoleで日本語フォントを使うと
      文字間隔が非常に長く、使用するに耐えられないのですが、
      gnome-terminalは、(無論アンチエイリアシングがかかっていて)
      日本語フォントも、適切な文字間隔で表示してくれました。

      一度、試してみては。
      親コメント
      • 私は、全体的な作りは KDE の方が良いんだろうな、と思いつつ GNOME 使ってます。どうも KDE は、微妙に違和感があって好きじゃないと いうのが理由のような気がします。

        今現在は、GNOME 2.0 使ってますが、1.4 から 2.0 になった時点でずいぶん(結構劇的に)パフォーマンスが向上してたように思います。無駄な描画がずっと少なくなったのが大きいのかな。1.4 を見てGNOMEは重いと思ってる人も多いんじゃないかな。2.0 から 2.2 でもパフォーマンスが良くなってるんでしょうか? あれから更に向上できるとなると凄いと思うのです。

        --
        親コメント
        • by hoihoi-p (5571) on 2003年02月10日 12時35分 (#255387) 日記
          >>1.4 から 2.0 になった時点でずいぶん(結構劇的に)パフォーマンスが向上してたように思います。
          うーん。そうですかー。?
          うちでは逆に目に見えて遅くなりました。
          こういう情報をよく目にしますが・・・。同意しかねる。

          # KDEみたく、デスクトップ全体に一種独特の空気がないぶん、GNOMEのほうが好きなんですが。
          --
          hoihoi-p  得意淡然、失意泰然。
          親コメント
          • by Anonymous Coward on 2003年02月10日 12時47分 (#255399)
            > >>1.4 から 2.0 になった時点でずいぶん(結構劇的に)パフォーマンスが
            > 向上してたように思います。
            > うーん。そうですかー。?
            > うちでは逆に目に見えて遅くなりました。
            > こういう情報をよく目にしますが・・・。同意しかねる。

            どちらも環境を書いてくれないとので読み手としてはどちらの情報も役立てられません。こういう話は自分の足場を明らかにしてくれないと。
            親コメント
      • by Anonymous Coward
        >KDEのほうが、コンパイル時間も長く、
        コンパイル時間はユーザには関係ないし、そもそもc++が
        時間かかるのは当たり前

        >私の設定が悪いのか、Konsoleで日本語フォントを使うと
        >文字間隔が非常に長く、
        設定が悪いです
    • Re:GNOMEもうだめぽ (スコア:2, おもしろおかしい)

      by Anonymous Coward on 2003年02月10日 12時47分 (#255398)
      >正直、GNOMEはもうKDEに追いつけないと思う。

      「北斗のK」と「GNOME野郎 A チーム」というネーミングの時点で既に勝負あったと思う。
      親コメント
    • by Anonymous Coward on 2003年02月10日 8時05分 (#255215)

      KDEがライセンス的に譲歩してくれない限り身を引くとは思えませんが(w

      # それなりに譲歩してるような気はするけどRSM的には
      # まだまだなんでしょうねぇ

      親コメント
      • KDEのライセンス (スコア:1, 参考になる)

        by Anonymous Coward on 2003年02月10日 14時33分 (#255484)
        KDEのライセンス問題といえば、Qt のことだと思うのですが、QPL と GPL のデュアルライセンス [ascii24.com]になったので、まったく問題はないと思うのですが。(上記記事では RMS も「うれしい」と言っていますし。)

        ただ、ライセンス上は問題がなくなったとはいえ、いち企業が開発する Qt に全面的に依存する KDE は、開発の主導権が完全にコミュニティにあるわけではないという点で、問題があると感じる人もいると思います。

        親コメント
    • by Anonymous Coward
      むしろ追ってほしくない。 GNOMEにはWindowsユーザーに媚びない独自スタイルを追求してもらいたいです。
    • by Anonymous Coward
      ソフトウェアに限らず、生命圏とか人間関係とか、多様性の維持は大切だぞ。

      つか、多様性を維持するためには排他的関係ではなく積極的な協調関係が必要だと痛感する今日このごろ。
      • 多様性という点で質問なんですが、GNOMEとかKDEって近い将来、旧来のウィンドウマネージャに置き換わる(or 置き換わろうとしている)ものなんでしょうか。それともやっぱり「ちょっと贅沢なウィンドウマネージャ」っていう位置付けなんでしょうか。
        • それは、決定しなくて良いと思います。
          パソコンが高速化して、両方の速度差がほぼ0になったとしても、
          「たくさんプロセスが動くからGnomeやKDEは嫌い」という
          ユーザの精神衛生上の?(笑)理由や、
          単に、画面がすっきりしていたほうが良い、という理由で
          WMを利用する人がいてもよいのではないでしょうか。

          ただ、「DeskTopを征服する!(Counquer your Desktop)」と
          標榜するKDEは、どちらかといえば、旧来のものや他の環境を
          置き換えようとする方向で
        • > 多様性という点で質問なんですが、GNOMEとかKDEって近い将来、旧来のウィンドウマネージャに置き換わる(or 置き換わろうとしている)ものなんでしょうか。

          いまはKDEやGnomeは「デスクトップ」という概念です。
          • いまはKDEやGnomeは「デスクトップ」という概念です。 ウィンドウマネージャとデスクトップは粒度が違う概念です。
            で、その「デスクトップ」ってどういう概念なんですか。フォントがきれいに見えてユーザーインターフェイスに統一感があることが「粒度が違う」ということなんでしょうか。
            • by route99 (7593) on 2003年02月10日 13時06分 (#255417) 日記
              > で、その「デスクトップ」ってどういう概念なんですか。

              多分ウィンドウマネージャが何かを誤解していると思います。
              「デスクトップ環境を救助」 [linux.or.jp]とその後の2、3ページを読みましょう。

              これはメニューや "about" ボックス、 プログラムのツールバー、プログラム間通信、印刷、ファイルの選択、それに その他のことといったような、共通の作業を実行するためなんだ。
              親コメント
              • 誤解していません。よろしければこれ [srad.jp]をお読みいただいてから、さらにコメントをくださるとありがたいです。

                新旧の構成でどうしても違う点は、プログラム間通信ということになるんでしょうか。
              • by route99 (7593) on 2003年02月10日 14時10分 (#255477) 日記
                誤解といったのは、twmとかfvwmとかのウインドウマネージャ実装は移動やリサイズといったウィンドウマネージャ機能だけでなくアプリケーションランチャが合わさったものであり、機能概念と実装をごちゃごちゃに扱っているのではと思ったからです。

                デスクトップ(机)というのは個々のファイルやアプリ(ノート、本、鉛筆)を連携させて扱うという概念です。実際のGUI機能としてはファイルその他のオブジェクトのドラック&ドロップ、統一ルック&フィール、共通ダイアログ、埋め込み文書なんかになるでしょう。

                また比較するのであれば、Gnome、KDE上で対応アプリケーションやアプレットと非対応アプリケーションを比較するべきです。twmなどで比較しても優位性が出る機能は見えないでしょう。
                たとえばデスクトップ対応のアプリでは、フォントだけじゃなく(アプリケーション)メニューやツールバーのスタイルなんかは管理ツールで統一的にスタイルを変更できるわけです。
                親コメント
            • > で、その「デスクトップ」ってどういう概念なんですか。フォン
              > トがきれいに見えてユーザーインターフェイスに統一感があるこ
              > とが「粒度が違う」ということなんでしょうか。

              UnixのCLI、twm、現在のGnomeなどを比較してみたら良いと思います。

              デスクトップのメタファーの一例ですが、「ファイル」という概念に対し「ファイルアイコン」という視覚的要素があります。このように「デスクトップ」を卓上で実際に使われているものに視覚化することなどがデスクトップと呼ばれた所以です。( 参照 [no-ip.com] )

              この点ではWindowsは「デスクトップ」のメタファーを捨てている事が多いのが残念です。たとえば、壁紙とよばれるものが卓上に張られるのは不自然です。マックでもOSXになってかなり捨て去られたような気がします。GnomeやKDEにはより洗練された「デスクトップ」またはそれに代わるものを期待しています。
              親コメント
            • 別のACです。

              GNOMEやKDEが考えるデスクトップの概念は、日常的なPC操作を行う環境といったところではないでしょうか。
              漠然とした言葉のような気がしますが、そのくらい色々な機能を提供するものだと思うので、下手に表現出来ません。(^^;)

        • X Window System上で動いている限り、置き換わるものにはなりえないのでは?
          あくまでプログラムとしてはウィンドウマネージャ+αなものでしょう。

            しかし、アプリケーションが{GNOME | KDE}上で動くことを前提として作成されるようになるかもしれません。
            Linux(別に他のOSでもいいんですが、現実的に見て)が Windowsに置き換わるデスクトップPC向けOSとして成長していった際に、必須環境となる可能性は高いでしょう。
          ;; というか、もうなってるのかな(^
          • #255388 [srad.jp]のACです。
            ちょっと説明がうまくないかなと思ったので、自己フォローです。

            あくまでプログラムとしてはウィンドウマネージャ+αなものでしょう。

            現在のGNOMEやKDEの役割は、むしろ+αの部分がメインですね。 ;; ウィンドウマネージャを

            • GNOMEやKDEは従来のウィンドウマネージャに置き換わるのではなく、まったく別のものだと言う事です。

              旧来の「Xserver + ウィンドウマネージャ(WM) + 諸々のアプリケーション」という構成に対し、「Xserver + {GNOME|KDE}統一パッケージング」という違いはわかるんです。また、環境として一切合切を提供することにより、統一性に優れ、使い勝手も特に初心者にとっては

              • > その新しい構成でなきゃどうしてもできないことってあるのかな、ということなんです。
                 
                出来ること、の絶対的な差異なんてもちろん存在しないと思いますヨ (それを言ったら MS-DOS でだって何でも出来る!)。

                僕が思う「デスクトップ環境」の利点は、ズバリ、プログラムの書きやすさ、です。Windows や Java で GUI のプログラムを書いたことのある人ならばお分かりかと思いますが、高機能なコンポーネント (TreeView や ListView などなど) があるかないかではアプリケーションの作成しやすさに雲泥の差があります。また、いちいち自分でプリンタのセットアップダイアログから (コモン・ダイアログ)、常駐用の小さなウィンドウから (TaskBar、Panel 上の applet)、preference システムから、何から何まで作らなきゃいけない、となったら、サンデープログラマはみんなさじを投げてしまうでしょう。そういう意味で、アプリケーションに対して、ある程度抽象化されたパーツを提供する「デスクトップ環境」は、特にプログラマにとって非常にメリットがあります。

                そしてもちろん、プログラマにメリットがある、ということは、それだけ豊富なアプリケーションが揃う可能性が高まる、というわけで、ユーザにとっても大きなメリットがあるわけです。

                僕はこんな風に理解していますけれども。
                --
                Only Jav^Hpanese available :-)
                親コメント
              • > また、環境として一切合切を提供することにより、統一性に優れ、使い勝手も特に初心者にとってはずっと向上しているってこともわかります。

                それが一番重要なんですが。ファイルなどのドラッグ&ドロップを含めて。

                > 疑問なのは、ユーザから見た
              • by SteppingWind (2654) on 2003年02月11日 2時37分 (#255917)

                それはちょっと違うと私は考えます. ここで述べられた物は全て単なる部品にすぎません. デスクトップ環境の本質は, アプリケーション間通信(端的にはカット・アンド・ペースト)であり, WindowsのAPIではそれが部品に組み込まれているが故にデスクトップ環境としての協調性が取れているわけです.

                でも, ここで私はさらにもう一段考えるのです. アプリケーション通信の大部分(全てではありません)は単なるファイルアサインの動的設定に過ぎないのではないかと.

                例えばシェルやJCLではプログラムに対する入出力のアサインを起動時に静的に決定します. しかし多くの対話型プログラムでは, 実行時に動的にアサイン決定を行うことが多くあります. 普通はこれを個々のプログラムで独自に実装するわけですが, この部分を共通化しプログラムから独立したユーザインターフェイスを介してアサインを行う機構こそがデスクトップとして必要な機能のほとんどだと私は考えます.

                具体的には, 高機能なファイルマネージャとそれに対するAPIさえ有れば大仰な統合デスクトップ環境はいらないと思っています. おそらくこのような考え方は, 専門化したツールのゆるやかな結合という古典的なUNIXの思想に基づく物でしょうから, 現在においてはあまり賛同が得られるとは思いませんが.

                親コメント
              • そうですね。僕があげた実例は軒並み「部品」という単位にフォーカスをあてていますが、もちろん、それらのたくさんの部品を手軽に使おうと思えば、共通の抽象化されたインターフェイスが必要なことは言を俟たず、そのインターフェイスの部分に注目すれば、それこそが「デスクトップ環境の本質」であるとも言えなくもない、と僕も思います。
                /*
                これは例えば Windows ならば COM、KDE ならば DCOP、GNOME ならば CORBA、ということになるのかな? 教えて、偉い人。
                */
                僕の理解では、これらの現存する抽象化インターフェイスは、あるオブジェクトに関する method signature の公開と、そのインスタンスへのバインディング、という思想で基本的には作成されているように思うのですが、「ファイル」を中心に据える、という考え方は unique ですね。しかし、「オブジェクト」がその成り立ちからしてそもそも有目的的で method 自体が意味を持つのに対し、「ファイル」それ自身は所詮無目的な入れ物に過ぎないことを考えると、その構造に関しても何らかの約束ごとを設けなければ結局1から全て作成するのと大差ないことになってしまいそう。で、例えば XML で構造を定義したりなんかしたりすると、ああ、これは SOAP の世界そのもの、って感じになってきますね。
                --
                Only Jav^Hpanese available :-)
                親コメント
              • GNOMEについては全然詳しくないので、KDE関連にだけ。

                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
                親コメント
              • by G7 (3009) on 2003年02月12日 1時26分 (#256617)
                デスクトップという言葉そのものからはちょっと離れますが、

                >アプリケーション間通信(端的にはカット・アンド・ペースト)であり,

                >例えばシェルや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に後から介入する術は基本的には無い。残念。

                そのフレームワークが、何かちょっと違うフレームワークに置き換わる、
                親コメント
              • by G7 (3009) on 2003年02月12日 1時41分 (#256626)
                やっぱりこの手のものの醍醐味は、Objectの、ニーズに即応してなんぼでも出来る、着脱性ですね。

                パソコン(?)の使い勝手の世界は、だんだんとSmalltalkみたいなものに近づいていくのかな(^^;

                で、そう考えると、Unixのプロセスモデルって、その分野へはあんまり貢献しないんだよね。むしろ時として邪魔。
                Unixは基本的に全ての(プログラム間の)繋がりは縦の関係。"実行"という文脈に縛られた関係。
                でも実際にプログラムを作ろう/使おうとすると、横の関係のほうが便利であることが結構多いんだよね。
                特にデスクトップなどのリアルワールド(曲りなりにも)メタファだと、その傾向が顕著。つまりObjectっすね。
                親コメント
  • まともに読んでる余裕が無かったので、ポインタだけ。
    dot.kdeに出ていたニュースです。
    KDE/GNOME To Cooperate On Interface Guidelines [kde.org]
    --
    -- Che Che - Bye Bye
typodupeerror

未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー

読み込み中...