HPがGNOMEの採用を中止 85
ストーリー by Oliver
ユーザは自分で入れることもできる 部門より
ユーザは自分で入れることもできる 部門より
タレこみ遅れた t 曰く、 "結構古い話題ながら、GNOME関連のニュースを扱っているFootNotesより。
HPは、将来におけるGNOMEの採用予定を取り消した。
2000年8月のGNOME Foundation設立当初は、CDEに変わる標準として将来GNOMEを採用することを公言していたHPだったが、今後もCDEを使い続け、GNOME 2.0は採用しない事を素っ気無いアナウンスで明らかにした。
本家の記事によれば、「2002年末の時点でGNOME 2.0の開発はまだ進行途中で、HPが期待していたほど早期には安定していなかった」事が原因の一つとして挙げられている。またFootNotesには「オープンソースは技術的にベストなソフトウェアを作るが、(いわゆる)商用ソフトウェアは現実的にベストな解決策を作る」「APIに統一性があっても、ユーザにとっての振る舞いの統一性がないことが問題だったのでは」などのコメントがあり、リリース周期の問題も含め、企業とオープンソースプロジェクトとの協調の難しさを示す典型例にも見える。
GNOME追っかけの自分としては残念の一言だが、読者の意見はどうだろう。企業製品の中核要素の一つとしてオープンソース製品が採用されるとしたら、それを円滑にする(あるいは現にそれを可能にしている)良案はないのだろうか。
(なお、Accessibilityへの対応を含め開発に積極的なSunは、GNOME2の採用に乗り気なままである)"
オープンソースへの手厳しい批判 (スコア:4, すばらしい洞察)
とありますがその前
から察せられるのは
技術的には良いものだが、振る舞いの統一が取れていない等 GUI 的見地からは良いとは言えず、利用者の立場から見れば今の大体のオープンソースプロジェクトのアプローチは役立たずだ
という手厳しい批判と、HP はそれを理由としてコミット出来ないと撥ねたのではという予想に思えます。
最も「現実的にベストな解決策」であるものこそが Hack だと思っていたのだけど。む~。
Re:オープンソースへの手厳しい批判 (スコア:3, 興味深い)
「技術屋(≒コンピュータマニヤ)だけでは、普通の人に使いやすいUIを作るのは難しい。デザイナーが要るよね」と言ってたのが、アラン・クーパー。
そして、その本の 訳者後書き [shoeisha.com]で、「(クーパーは)オープンソース・フリーソフトは一般ユーザーに使いやすいシステムは作れない、と実質的に宣言しているに等しい」と書いたのが山形浩生。
なかなか興味深い指摘だと思わない?
Re:オープンソースへの手厳しい批判 (スコア:1)
私個人としては、オープンソースにおけるデザインというのは、「人間の思考」というものがいかにデザインされているか、を垣間見ることのできる素晴らしい機会だと思っているのですが、その視点に立つと、「一般ユーザーに使いやすいシステムは作れ」るように思っています。
ただ、やみくもに作るのではなく、より意識的に作る必要はありそうですね。「ハッカーのためのハッカーのツール作り」と、「一般人のためのハッカーのツール作り」をごっちゃにせず、別の意識を持って取り組んでいけば、数年後には成果が出ると思ってます。
Re:オープンソースへの手厳しい批判 (スコア:1, 参考になる)
書くとしたら,「自分の子供にとって使いやすいソフトウェア」とかかなあ.
ソフトウェア開発のインセンティブ (スコア:1)
とってのインセンティブであるわけで。
(そのインセンティブの部分が一般人には理解されにくいんだと思うが)
プログラマに完全な博愛主義のボランティアを期待されてもね。
一般人に使いやすいソフトウェアを書かせるために、
どんなインセンティブを用意すればいいかといえば
1)金。でもこれは企業じゃないと無理。それとも国が援助する?
2)名誉欲。一般社会が、一般人に使いやすいプログラムを書いた
ハッカーのことを神か英雄かのように褒めちぎればいい。
3)ヒューマンインターフェース関係の研究者に書かせる。
フィールドワークになることがインセンティブ。
くらいしか思い浮かばないな…
# mishimaは本田透先生を熱烈に応援しています
Re:オープンソースへの手厳しい批判 (スコア:1)
まあ、実際にはGUIのフレームワークとか、その裏のカラクリに面白さを感じて作ってるのでしょうけど。ユーザーインターフェイスという「一般人に使い易い」を追求すべき場所で、なんか本末が転倒してる印象は否めないよね。
Re:オープンソースへの手厳しい批判 (スコア:1, 興味深い)
でも、これってゲーム関係(含むフリーソフト)じゃ2000年よりもっと前に
実践されていたと思うし、他にも言っていた人はいると思う。
フリーソフトで使いやすいシステムが作れないとは思わないし、
実際に使いやすいものも存在するが、
方向性の統一や開発チームのすりあわせなんかは重要かつ大変。
しかも、フリーソフトってのは基本は自分のためにだから、
UIのような趣味的な部分のすり合わせは、規模が大きくなるほど
難しくなるとちゃうだろうか?
Re:オープンソースへの手厳しい批判 (スコア:1)
それ故に一例としてGNOMEではWindowManagerは好きに選べる、と。
Re:オープンソースへの手厳しい批判 (スコア:1, 興味深い)
良い物ができない傾向にあると思う
遠慮をしないということは何時か何処かでぶつかる
仕事で企画屋やデザイナーと取っ組み合いの喧嘩になって、どちらかが折れた場合でも仕事だからで割り切れる
(互いに良い物を作ろうとしていることは理解しているし)
仕事じゃない場合は自由に作りたいから
正直、デザイナーと一緒にやるのはやだな
利用者に意見聞き (was: Re:オープンソースへの手厳し (スコア:1)
>他人本位でのプログラミングができるかどうかだと思う。
で、他人本位な――というか利用者指向のプログラミングを
行うのこそ、RedHatなどのディストリビュータの役目だと思っ
ていたのですが、そういうことやっているのでしょうか。
シロウトさん集めてきて使わせて、アンケートを取るとかいった、
MSがやっている(他の業界だとどの会社もふつうにやっている)
ようなことを。
IN EARTH AND SKIE AND SEA STRANGE THYNGES THER BE.
Re:利用者に意見聞き (was: Re:オープンソースへの手 (スコア:1, すばらしい洞察)
>ていたのですが、そういうことやっているのでしょうか。
やっているつもりでは、あるのだろうけど努力不足だと思う。
>シロウトさん集めてきて使わせて、アンケートを取るとかいった、
>MSがやっている(他の業界だとどの会社もふつうにやっている)
>ようなことを。
意見を聞く事も必要だと思うが、もっと圧倒的に欠けてるものがある。
何か意見を持っている人が、意見を言ってくれるとは限らないし、
足りないものを感じてる人が、意見するレベルまで考えを煮詰めてくれるとも限らない。
今ユーザが何を要望しているか、聞こえてこない部分を考え、
それを予測して実装するぐらいの配慮は必要なのではないだろうか。
例え望まれている物が、効率にそぐわない部分を含んでいたとしても。
MSの実装は度々「おせっかい」として批判されるが、
「おせっかい」と思われている事は必要ではないのか?
究極のデスクトップPCは、(軍師+執事)/2の様な、
その人の事情に応じて、要求を手助けしてくるようなものではないだろうか。
プラットフォーム非依存GUIアプリ (スコア:1, 参考になる)
できるだけソースそのままでwin32でも動いて欲しいのです。
現状のgnomeでそれは可能なんでしょうか?
それとも、gtk+のレイヤまで落とさないとだめでしょうか?
それとも、linuxのGUI tool kitでwin32にそのままport可能な他のよい手段はあるでしょうか? (C, C++で)
Re:プラットフォーム非依存GUIアプリ (スコア:2, 興味深い)
ツールキットの選択も重要だが、フォント命名規則やフォントメトリクスの非互換の方がはるかに問題が大きい。
またツールキット+標準ライブラリで事足りるような場合はともかく、OSの機能をある程度利用しようと思えば、 最初から両方で使うことを十分に考慮したコーディングをしておかないと、後で泣く羽目になる(例えば印刷機能等)。
いずれにせよ、#ifdef~#else~#endifが乱立するコードになるのはやむを得ない。
Re:プラットフォーム非依存GUIアプリ (スコア:1)
いまのところWindowsの模倣なんだから開発言語も模倣すれば よかったのに。言い古された意見ですが。
Re:プラットフォーム非依存GUIアプリ (スコア:1)
Re:プラットフォーム非依存GUIアプリ (スコア:1)
げ。最近はそこまで濃ゆいことやってるんですか。
かっこいい。RTTIだの動的Load型だのClosureだのをサラリといってのけるとは…
ただまあ、そこまで重装備(?)でなくても、それこそ関数ポインタというか、関数ポインタの配列へのポインタというか、
そういうのが有るだけでもだいぶ色々と良いですね。
#関数ポインタを各Instanceに持たせるのが馬鹿らしいので、クラス(?)1つ毎に1箇所だけで関数ポインタ配列を抱える。
#で、そう考えると、Delphiに有るようなクラス(static)メソッドの多態も、別に難しい概念じゃないことに気付く…はずなんだけどなあ>C++、java
あとは、ちょっと遅くても我慢するなら、ポインタ配列じゃなくポインタHash表にすると、色々遊べます(^^;
#Hash表の実装は(全然知識が無くても:俺だな)作法本を読めばなんとかなるかと。
Re:プラットフォーム非依存GUIアプリ (スコア:2, すばらしい洞察)
>
>げ。最近はそこまで濃ゆいことやってるんですか。
>かっこいい。RTTIだの動的Load型だのClosureだのをサラリといってのけるとは…
格好いいですか? closureあたりはどう書く/使うのか知らないけど、単にひとつのクラスを書くだけでも (Gtk+-1.xとあまり変わっていないみたいですね) 手で書くコードが 多すぎて [dunkelhain.de] 萎えてしまいますわ。C++で 無理矢理reflection [garret.ru] があまり面白くないのに似た気分。
XXX言語で出来そうにないことをやってのける、ってのが面白いという意見には同意なんですけど、COOLやGObjectさんは手で書くコード量が多すぎないですか。 俺閾値超えちゃってます。面倒だしバグ入れそうだしうーん。 C言語の限界を越えたというよりはC言語の限界を改めて見せつけられているだけに思えてしまいます。
出来そうもないことをやってのけ、かつコード量も減るっていう方が個人的には格好いいです。例えば C++ だけど Boost Lambda Library [cppll.jp] とか。
# CでOOは勘弁してくれと言っているだけな気もするけどID
Re:プラットフォーム非依存GUIアプリ (スコア:1)
だからと言って即Cステということにはならないと思うのですが。GNOMEの目標の一つにlanguage bindingsを用意して様々な言語から利用できるようにするというのがありますけど、そうなると.NET CLIとかParrotみたいなものを別にすれば、現状では選択肢はCとC++くらいしかなくなりますが。
ちなみにGObjectの効用の一つはlanguage bindingsのglue codeを書く手間が省けることで、その辺りの説明はWrap GObjects in Python [ibm.com]に出ています。
Re:プラットフォーム非依存GUIアプリ (スコア:1, 参考になる)
wxWindows [wxwindows.org]なんていかがでしょう?
new/delete処理がちゃんと作ってあれば、ソースの変更無しでwindowsで動きます。
linuxでは、適当に作っても動きます。<new/delete
# 私がlinux→winへの作業で遭遇したバグは、ほとんど↑でした(;_;)
サンプル (スコア:1, 参考になる)
VCL(+Delphi)の代わりになるフレームワークとして試していますが、なかなか便利ですよ。さすがにRADほどのお手軽さはありませんが。
#Ruby でも使用できるようにならないですかねぇ。
野分
Re:プラットフォーム非依存GUIアプリ (スコア:0)
それでも非互換性が気になるなら、CやC++をあきらめて Java をつかになはれ。
アクセシビリティ以前に (スコア:1)
いちばんひどいと感じるのはOK/キャンセルのボタンの並びがGNOME2からいままでと全く逆になってること。
この「改悪」のせいでボタンの押し間違いを何度もしてしまい、
とてもストレスに感じています。
結局いままで使っていたGNOME1.4に戻ってしまいました。
この「改悪」をユーザー側で設定し直すことってできるんでしょうかね?
いろいろ細かい設定項目がなくなっているっていうのも残念です。
Re:アクセシビリティ以前に (スコア:1)
でも今のユーザーインターフェースが一貫性があるとは残念ながら全く感じません。
実際に使ってみてボタンの配置には本当にいらいらさせられました。
むしろGNOME2のみが他の環境(KDE等)と比べて孤立しているように感じたので
使用をやめてしまったのです。
昔からGNOMEを気に入っていて使っていただけに残念です。
白紙撤回? (スコア:0)
GNOME/KDE 以外の選択肢は少なく GNOME や KDE の資産が増え、それを使いたいと顧客が望むと HP もいずれはどちらかを選ばざるを得ないのでは。まさかいつまでも CDE へのポートを負担するワケにもいかないでしょうし… それとも商用 UNIX は用途が特定される等の事情からそんな心配必要ないのでしょうか。
# *NIX 初心者なのでエラい人の解説を期待しつつ AC
Re:白紙撤回? (スコア:0)
言い出せなくて、とりあえず一度GNOMEから離れてKDEを選ぶと
予想したりす。
でも、本心はCDEでも仕事に使うには問題ないので余計なトラブルを
避けたくなったのだと思う、リソースは無料で
Re:白紙撤回? (スコア:1, すばらしい洞察)
いいよな~と思って使っているとバージョンを重ねるごとに自壊に近づいていく。
Re:白紙撤回? (スコア:1)
す、すみません、KISSってなんすか?
#無知をさらして恥ずかしいけどID
(I can't get no) satisfaction
KISS (スコア:1, おもしろおかしい)
Re:KISS (スコア:1)
(I can't get no) satisfaction
Re:白紙撤回? (スコア:1)
> GNOMEはパスしても問題ありません、これを機会にシンプル路線に
> なって欲しいな。
結局、CDEでいいかと思われ。
UNIXを仕事で使う人(開発者を除く)は、
数種類のソフトを素早く起動できればいいんです。
あとはWindowsなり、Macなり使えばいいさ。
PCにECC Registeredメモリの利用を推奨します。
Re:白紙撤回? (スコア:2, すばらしい洞察)
もっと、もっと、、、 (スコア:0)
#gnome2 って freetype 必須でしたっけ?
Re:もっと、もっと、、、 (スコア:0)
LinuxWorld誌
http://www.idg.co.jp./lw/back/200204/20020424_01_solaris.html
stsf
http://stsf.sourceforge.net./about.html
SunがX用の新テキストAPIを公開へ
http://slashdot.jp./article.pl?sid=02/02/13/1925243&topic=84&mode=thread
pango
http://www.pango.org./
pangoの接続:第1回
http://www-6.ibm.com./jp/developerworks/unicode/010525/j_u-pango1-index.html
Re:質問 (スコア:1)
GNOMEはWindowManagerの機能だけではありません。
GNOMEを構成する要素の一つにWindowManagerがありますけどね。
まぁ、GNOMEはおろかXすら滅多に起動しない私がいうのもなんですが(笑)
# rm -rf ./.
Re:質問 (スコア:0)
Re:質問 (スコア:1)
初心者でも、ある程度触れるとか。
じゃないかなーと思う。
私はxfceがあれば、どうでもいい。GNOMEいらない。
PCにECC Registeredメモリの利用を推奨します。
Re:質問 (スコア:1)
[window manager + 各種アプリケーション]の環境を
使いやすくするための枠組みと捕らえるべきでしょう
タレこみ文からもリンクが張られていますが
sunのページにGNOMEの環境のもとで
[window manager + GNOME対応のアプリケーション]使った場合の
うれしいことの例が書かれています
http://jp.sun.com/software/gnome/
X上で、ktermとかしか使わない人はGNOMEは不要でしょうが、
X上で[window manager + 各種アプリケーション]使うならばGNOMEなどは便利だと思います。
Re:質問 (スコア:1)
# mishimaは本田透先生を熱烈に応援しています
Re:質問 (スコア:1)
ここ [leb.net]とかでは、gnomeが今の形に整備される前からDrag&Dropの
機能を実現するライブラリを公開してましたから、特にDrag&Dropに関しては、
gnomeが必要ってわけでは無いと思いますが・・・。
#それとも、gnomeの様な統一したフレームワーク中で行わなければ
#ならない、特殊なDrag&Dropってあるんでしょうか?
---- redbrick
Re:質問 (スコア:2, 参考になる)
> > GNOMEを使うとあざやかにこなせてうれしいことの例を示してください。
という質問だったので。
DnD の例で言えば、ドロップ元とドロップ先が別々の DnD ライブラリ
使ってたらどうするの?ってところを解決しないといけない。
そして GNOME なら自動的にそこを解決できる。
そもそも、GNOME は複数のライブラリの寄せ集めなんだから、
「GNOME でできるウィジェット操作は GTK+ でもできる」
「GNOME でできるサウンド操作は ESound でもできる」
「GNOME でできる…は…でできる」
と、いくらでも言える訳で。
じゃあ、GNOME は何がいいかというと、
それら(の方式)を統一しているところ。
統一した結果メリットが出るところというと、
アプリケーション間のデータのやり取りが一番分かりやすいところだろうな、
ということで先ほどのコメント。
# mishimaは本田透先生を熱烈に応援しています
Re:質問 (スコア:1)
>
>> > GNOMEを使うとあざやかにこなせてうれしいことの例を示してください。
>
>という質問だったので。
ふむ、統一したものだとうれしい、と言うことですか。
その点は納得です。
ただ・・・、
>DnD の例で言えば、ドロップ元とドロップ先が別々の DnD ライブラリ
>使ってたらどうするの?ってところを解決しないといけない。
>そして GNOME なら自動的にそこを解決できる。
??? この説明、ちょっと意味がよく分かりません(汗)。
えーと、わたしの認識だと、DnDなんてものは、各々のアプリケーションが
サポートするものではなく、WindowManagerがサポートするものだと
思ってたんですが・・・。
で、WindowManagerは基本的に一画面で一つだと思ったんで、別のライブラリが、
なんて話はしても意味がないと思ったんですけど、違うんですか(汗)?
---- redbrick
Re:質問 (スコア:1)
GNOMEの肝がORBitだというのは大体理解できているのですが, 実際のところ, たかがDesktop Environmentのためにあれほど大仰な機構は必要なのでしょうか? 個人的にはドラッグ・アンド・ドロップを含めたプログラム間連携の9割以上はURL文字列を含めた文字列交換とファイルのやり取りで片がついてしまうように思えます.
だとすれば, よくできたファイルマネージャが1個あれば, ORBitの様な分散オブジェクト通信を使うよりも, 古典的なファイル交換モデルの方が独立性・柔軟性が高く, 使い勝手が良いように思えます.
まあ, これはenlightenmentとkonquerorとGNOMEアプリケーションを混在して使っている人間のたわごとですけど.
Re:質問 (スコア:1)
Dropするには、その逆が必要です。
DnDを自前で全部準備するには、双方のアプリであらかじめ専用の通信パスを用意しなければなりませんが、GNOMEやKDE等Desktop環境は自分を経由させ(汎用のDnD APIを介す)ることで、AdHocな対応をしなくても良くなります。
# rm -rf ./.
Re:質問 (スコア:1)
>またデータフォーマットも提示しなければなりません。
>Dropするには、その逆が必要です。
なるほど、詳しい説明、どうもありがとうございます。
大変参考になります。
#そーか、その仕組みやルールを含めて統一したものになるから
#うれしい、ってことなのか・・・。
---- redbrick
Re:質問 (スコア:1)
現状、Xでよく使われているDnD ProtocolはXDND Protocol [newplanetsoftware.com]でしょう(利用ライブラリ、アプリ等 [newplanetsoftware.com])。
X上のDND Protocolには他にも、redbrickさんが示されたOffiX drag and drop ProtocolやMotifのProtocol等があるようですが(XDNDのサイトにそれらの比較 [newplanetsoftware.com]があります)、
DnDが使えるためには各アプリが同じDnD Protocolをサポートしている必要があることを考えると、
DE(Desktop Environment)というのはDnDの恩恵を受けることを(ユーザ、開発者ともに)期待できる環境だと思います。
個人的にはDEの恩恵というのはDnDもありますが、
* 統一されたUIによるわかりやすさ
* 基本的な設定を一元化することによる設定の省力化
* コンポーネントの利用によるプログラミングのしやすさ
などがあると思っています。
-- Che Che - Bye Bye
Re:質問 (スコア:1)
ファイルをドラッグアンドドロップ。
Re:質問 (スコア:0)
背後でいろいろとやってくれている。
プリント環境(pdfへの変換機能とかもふくむ)を共通のAPIから利用できたり、
アプリケーション間でイベントを渡しあえたり、いろいろと利点はつきません。
Re:質問 (スコア:0)
どうでもいいことですよね、内部動作がどうなってるかなんて。
Re:まあHP-UXだしな (スコア:1)
HP C++とHP aC++ (スコア:1)
HP aC++ Transition Guide [hp.com]を見ると違いが分かるかも。