アカウント名:
パスワード:
どうして、同じ設定にするのに、年寄りにさえ見た目の違いが分かるものを置いて、2回やらせるのか。
設定ツールを2セット作る、Web サイトを 2つ作る、 さらに Linux を2機種作るのは引き合わないし望ましくない
Mandrakeでは、Mandrake流のRPMの組み方をすると、 たいていのアプリはKDEとGNOMEの両方のメニューに登録されます。 実際の所、利用者としてさらに「どちらで動くアプリか」というのに こだわる必要は薄かったりしますが、RedHatはどうなんでしょ?
RedHatと比べるとビジネスポリシーを始め様々な点でアプローチの 仕方に違いがありますが、個人的にはRedHatが牽引する時代はもう 終わっていて、Mandrakeあたりがこれから牽引力を発揮するん じゃないかと思ってます。
ネイティブ KDE アプリケーションは Null では取り去られるわけではなく、単にデフォルトのメニューにないだけだ
CとC++との間の溝の深さよ。
#仕方ない(C++じゃそうせざるを得ないので作者氏の責任ではない)とはいえ、ちょっと悲しかったです。
そうかな。メジャーなやり方はテンプレートを使いますよね。
まぁ、テンプレートをサポート
つまり、思想の違うものを統一するのは困難、ということ。たとえ目指すものが統合デスクトップ環境という同じものだとしても。
ま、目指すゴールが違う分、FreeBSDとNetBSDの統一の方が難しいと思うけど。つか、最初から別れてない罠。
Gnome2使って日本語フォントの扱いが変です。 みるとわかりますが、
表示に関しては、pangoのフォント設定($PREFIX/etc/pango/pangox.aliasなど) に問題があるのではないでしょうか?
gnome-terminalでは仮想端末の機能を提供しているlibzvtライブラリで gdk_font系の関数(Gtk+1.x系列の名残)を使っているので今のところ 日本語をちゃんと扱うことはできません。
geditですが、私が持ってるDynalabのフォントでは適切な間隔で表示できています。 gedit-view.c側で怪しげなことはしていないようなので、Pangoのバグでしょうか。 KDEでも再現されるようでしたらfreetype2の問題かもしれません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
いつかは通る道だが (スコア:1)
いつかはKDEとGNOMEを(なんらかの意味で)統合する必要があると思ってるので、
基本的には賛成なのですが…この記事 [internet.com]もなるほどと思う内容だし。
ただ、
> 技術的にはRedHatはGNOMEに精通している技術者が多い 以上、偏りがあるのかもしれない?
なのが気になります。統合するはずが、実はGNOMEしか残らなかった
なんてことにならないことを祈ります。
GNOME 2.0はまだ使ってないんですが、1.4は使うと泣けてくるので。
Re:いつかは通る道だが (スコア:2, すばらしい洞察)
何せ、どうして、同じ設定の、見た目の違いもわからない同じようなものを二つも置いているのか、ということになりかねませんし。
以下、私がデスクトップ環境について思っていること。
「普通の社員」は、どちらか一方しか覚えないし、使わないのだから、苦心して二つのものを同じように設定するのは労力の無駄にしか感じません。それよりは、マニュアルの厚さ(バイト数?)を倍にして、それぞれの環境について最大限活用できるように解説すべきだと思うのですが。そうすれば、統一性にこだわる人は片方の環境に合わせて作られたアプリケーションを使って行けばいいわけですし、そうでない人も、それぞれの特徴に合わせて使い分けられて、みんな幸せ。
これって、そんなに変でも、独創的でもない意見だと思っていたのですが、Red Hatで違う方向に進んでる事を考えると、実は馬鹿げた考えだったのですか?
巧妙に潜伏したバグは心霊現象と区別が付かない。
Re:いつかは通る道だが (スコア:2, すばらしい洞察)
これがムダだと感じられるのに、
> マニュアルの厚さ(バイト数?)を倍にして、それぞれの環境について最大限活用できるように解説
というのがムダだと感じないのはなぜ?
100人以上のユーザーが、隣のデスクではKDEを使い、
向かいのデスクではGNOMEを使っているという状況が生産的であるとは
とても思えませんが。
別に、地球の裏の自分に関係ない人がKDE使おうがGNOME使おうが、
それは構わないと思いますが。
技術の発展のためには競争や切磋琢磨が必要だとは思うけれど、
多様性が生産性に直結しないのは、当たり前だと思いますが。
Re:いつかは通る道だが (スコア:2, すばらしい洞察)
一方、マニュアルを倍にする、即ち二種類のマニュアルを作ると、片方のマニュアルは明らかに無駄になります。しかし、ユーザーは必要なほうを選ぶだけなので問題はありません。ユーザー主体で考えると、後者のほうがよい形なのではないでしょうか。まあ、ディストリビュータにかかる負担が前者<後者なら、パッケージの価格にも跳ね返ってきますので、無条件に後者が良いとはいえなくなりますが。
社内での統一性は、IE禁止or強制令のような物に頼るってことで… よ、弱い?
と、ここまで書いていて、ディストリビューションにKDEとQNOMEの両方を含める事を暗黙の前提条件としていることに気づきました。この条件を外して考えると、企業のデスクトップ機やライトユーザー向けに、片方しか含まないものを作ってもいいですね。何ならKDE版とGNOME版の二種類出しても…て、それじゃマニュアルを二つ作る手間は変わらないか。
両方入ってなくても、パワーユーザーならもう一方をどこからともなく手に入れるでしょうし。
ああ、書けば書くほど妄想モードに突入かつ自分の首を絞めてる。(泣)
デスクトップ環境の巨大なソース or バイナリを持ってくるのはなろーばんどな人間には辛いの~
# かくいう私はKDE使い。GNOMEは使ってませんが、GTK+にはお世話になってます。
# (SylpheedとかGKrellMとかGVIMとか)
# <(ホントはもちろん半角)を使うと投稿結果が変に。 なぜ?
巧妙に潜伏したバグは心霊現象と区別が付かない。
リソースとか、企業の思惑とか・・・ (スコア:1)
ほとんど立ち上げませんのであまり云々言え無いんですが....
RedHatにKDEの技術者が少ないということから、RedHatとしても
社内リソースをどちらかのデスクトップに注力したいというのが
本音でしょうね。GNOMEと比べた訳ではないのですがKDEの開発
ピッチの速さに、製品としての洗練を常に維持できる品質での
追随は大変だと思います。
中途半端なものを入れるなら、「ばっさり」落としたいという
のが内心の気持ちなんだとも思います。
順調に業績を伸ばしているMandrake(デフォルトはKDE)がフランスの
政府調達 [srad.jp]に乗り、KDEにドイツが執心 [srad.jp]という
欧州の状況を見ると、RedHatとしてはGNOMEに注力すること
で何とかビジネスの盛り返しを、とどこかで思ってそう。
とはいえあまり対立するような方策より「どちらに転んでもリカバリが
可能なセン」でとりあえず納めておくというほうが今の戦略としては
正解なんでしょう。少なくともプレス向けのアナウンスとしては。
実際、どちらも入ってないと困ることが多いし、どっちも必要。
どちらの環境から、どちらのアプリもたいてい呼び出せますし、
普通のユーザにとってはそれがKDEのアプリなのか、GNOMEのアプリ
なのかなんてのは、あんまし関係ない感じ。
最適解としてはどちらも同じ程度の注力で出して欲しいところ。
どっちかのデスクトップに統一したいとかいうのは短絡的に過ぎるし
統合もまだ遠いでしょう。
ところで、Mandrakeでは、Mandrake流のRPMの組み方をすると、たいてい
のアプリはKDEとGNOMEの両方のメニューに登録されます。
実際の所、利用者としてさらに「どちらで動くアプリか」というのに
こだわる必要は薄かったりしますが、RedHatはどうなんでしょ?
説明書の件にしても実際のモノとヘルプが対応していないとか、作成中
で止まってたりするものは多々あるし、「最新機能」をうたえば、
マニュアルをきっちり書くためのリソース投入も開発と同じくらいは
かかると思います。
・・・・ていうか、これまでKDEだのGNOMEだののきっちりした説明書を
それらの添付ヘルプシステムの内容以上に充実させてつけてたディストロ
ってあるんでしょうか、そこまで充実したモノをつけてくれるなら
それだけでお金を出す価値はありますが、オンラインで出回ってる
ドキュメントを単にまとめてレイアウトに流し込んだような程度なら
いらねー、と思っちゃいます。
とか思うと、マニュアル云々はなんだか「口実」のように思えてきますね。
# それにしても自身のポリシーで企業をあっさり辞められるという
# のはうらやましいというか、立派というか・・・
-- (ま)
Re:リソースとか、企業の思惑とか・・・ (スコア:1)
おそらく両方に登録されるのではないかと思いますが、
SPECファイルを検証したりしたわけではないので分かりません。
ところで、KDE開発者も多く在籍しているMandrakeでも、
KDEとGNOMEのインタフェースの統一化を図っている [zdnet.co.jp]ようです。
個人的には、RedHatのアプローチとの違いには、非常に興味があります。
Re:リソースとか、企業の思惑とか・・・ (スコア:1)
残ってました。specファイルをちょ~っとだけ改めて見ました。
で、詳細不明ながら、見るとMandrake独自にKDEのメニューのデータ
ストクチャを読んでMandrake共通のメニューデータに変換してますね。
GNOMEで、このデータをどう解析して流しているのかまでは把握してない
のですが、メニューに関しては少なくとも双方のデスクトップに不利益な
干渉をしないように相互操作性を確保しようとしていると思いますよ。
Mandrake9.0はいまようやくDL開始したところで(うちの環境だと3日は
かかる)、RC*は見てないのでなんとも言えませんが、彼らが掲げていた
「Windowsより使いやすいLinux」
という目標は、現実のものにますます近くなってます。
Mandrake8.0のころからずっと使っていて、8.1->8.2と来ても裏切られ
なかったです。これまでの度重なるリリースの度にいっそう強く感じる
ようになりました。
Daickiさんが示されているzdnetの記事を読んでも、NTFSサポート、
WebDAV標準サポート、Supermountにて動的にHotPluggableなデバイス
をmount/unmountしたり・・・と。Windowsで得られていた操作性に
より遙かに高度だとすら思います。実際、Mandrake 8.2はWindowsより
苦労せずにインストールできた印象があります。
Mandrakeはちょっと前は大量レイオフの噂(とはいってもさほど
従業員多くない気もしますが)などあって危ないとさえ言われてた
わけですが、その後の巻き返しの裏にはやっぱりそれなりの事が
あるんだろうなと思ってます。
RedHatと比べるとビジネスポリシーを始め様々な点でアプローチの
仕方に違いがありますが、個人的にはRedHatが牽引する時代はもう
終わっていて、Mandrakeあたりがこれから牽引力を発揮するん
じゃないかと思ってます。
# 故に目が離せない:-)
-- (ま)
Re:リソースとか、企業の思惑とか・・・ (スコア:1)
デスクトップに関しては、UnitedLinux関係各社も同じような方向を目指して欲しいなあ。
#記事とMaxさんの投稿から受けた印象だけを元に書いています。
Re:いつかは通る道だが (スコア:1, 興味深い)
良い結果につながらなかったという過去の現実を見ると
結論らしいものが見えてくるかも。
そして俺はどちらも使わずに、.xsession 書いて twm 環境
Re:いつかは通る道だが (スコア:1)
この記事には、
とあるのですが、これは少なくともKDEとしては非常に使いにくいものでしょう。
GNOMEとKDEを統一したいといった意見は理解できますし、
ユーザーにとっても利益はあると思います。
しかし、やり方は間違っているのではないでしょうか。
Re:いつかは通る道だが (スコア:1)
全面的に同意します。
いいわけになりますが、書き忘れてました(^^;)
> GNOMEとKDEを統一したいといった意見は理解できますし、
> ユーザーにとっても利益はあると思います。
> しかし、やり方は間違っているのではないでしょうか。
うーん、少なくとも自分は方法が思いつきません。
GNOMEやKDEを使ったりfreedesktop.orgを見てると、
このままでは数年経っても何も変わらない気がしてます。
だから、実際のモノを見るまでは何とも言いにくいです。
Re:いつかは通る道だが (スコア:0)
Macと比べると (スコア:1)
カスタマイズ自由なものよりも、みんなで統一したインターフェースが使える。これが、デスクトップOSの条件の内の一つではないでしょうか。
> 技術的にはRedHatはGNOMEに精通している技術者が多い 以上、偏りがあるのかもしれない?
技術的、開発者側の都合でものを語っていたのでは、いつまでたってもデスクトップOSになれませんよ。
// Give me chocolates!
Re:Macと比べると (スコア:0)
CとC++との間の溝の深さよ。
Re:Macと比べると (スコア:1)
CもC++どっちもアプリとかを作るにはイマイチなんだけど、他に選択肢があんまり無いってのが悲しいですね、現状は。
Cに行ったほうもC++に行ったほうも、それぞれ結構馬鹿にならない(小さくない)問題を抱えてる…
#オフトピだけどWideStudioのイベント関数ってC++メソッドじゃなくC関数で実装されるんですってね。
#仕方ない(C++じゃそうせざるを得ないので作者氏の責任ではない)とはいえ、ちょっと悲しかったです。
中(^^;を取ってObjectiveCあたりが良かったんじゃないのかな、とやっぱり思います。
C++と違って「柔らかい系(?)」のOOP言語です(のでアプリを作るのには向いてると思う)し。
え?MacOSX?
Re:Macと比べると (スコア:1)
Re:Macと比べると (スコア:1)
選択肢があまりないというのには激しく同意。
選択肢と言えばPythonみたいなスクリプト言語があるけど、
大きなものになると、やっぱり型付きコンパイル型言語が欲しくなる。
JavaかC#(?)がまともに使えるようになれば良さそうだけど。
Re:Macと比べると (スコア:0)
そうかな。メジャーなやり方はテンプレートを使いますよね。
まぁ、テンプレートをサポート
Re:Macと比べると (スコア:1)
まぁ、可能かといえば可能でないわけではないですが、いろいろと面倒というか障害が多いですね。
「わざわざそんなもん使うくらいならXXX(他の言語には有る機能(あっさりした奴))でいいじゃん。
なに?C++にはXXもないのか?」という感じ。
もちろんそんなこと言い出せば、一般論としてはキリが無いのですが、C++だとちょっとそういう状況が多すぎて…
#たしか本物のMethodPointerを取得することも可能だったような気がしますが、結構アクロバティックな嫌らしいコードだったような…
Re:Macと比べると (スコア:0)
Re:Macと比べると (スコア:0)
Re:いつかは通る道だが (スコア:1, すばらしい洞察)
いやいや、んなことが実現できるなら、今ごろはFreeBSDとNetBSDくらいはマージされてるはずだと思うっす。
#それでもOpenBSDはマージされないと思うのでAC。
Re:いつかは通る道だが (スコア:1)
してでも出来るだけたくさんのプラットフォームで動作することを
念頭においているNetBSDが、FreeBSDといっしょになるのは結構
難しいんじゃないか?
Re:いつかは通る道だが (スコア:1)
つまり、思想の違うものを統一するのは困難、ということ。たとえ目指すものが統合デスクトップ環境という同じものだとしても。
ま、目指すゴールが違う分、FreeBSDとNetBSDの統一の方が難しいと思うけど。つか、最初から別れてない罠。
Re:いつかは通る道だが (スコア:0)
少なくとも初期においては目指すゴール自体は同じだったはずです.386BSDから分岐した時に,何を「優先して」開発するかというポイントにおいてNetBSDとFreeBSDに別れたわけですが,
Re:いつかは通る道だが (スコア:0)
Re:いつかは通る道だが (スコア:1)
>1.4は使うと泣けてくるので。
Gnome2使ってみるとわかりますが、
日本語フォントの扱いが変です。
ま、いいんです。ブラウザとエディタ以外に
日本語を求めませんから。
.::.:... .::....: .::...:: .::.:.:: .::..:.: .:::..:.
I 1 2 B H4[keR. :-)
Re:いつかは通る道だが (スコア:1)
表示に関しては、pangoのフォント設定($PREFIX/etc/pango/pangox.aliasなど) に問題があるのではないでしょうか?
Re:いつかは通る道だが (スコア:1)
>($PREFIX/etc/pango/pangox.aliasなど) に
>問題があるのではないでしょうか?
gnome-terminalや、gedit2で
kochi-gothicなどの複数のコードセットを
持っているフォントの幅が妙に開いたりします。
段々ずれていくので結構気になる。
.::.:... .::....: .::...:: .::.:.:: .::..:.: .:::..:.
I 1 2 B H4[keR. :-)
Re:いつかは通る道だが (スコア:1)
gnome-terminalでは仮想端末の機能を提供しているlibzvtライブラリで gdk_font系の関数(Gtk+1.x系列の名残)を使っているので今のところ 日本語をちゃんと扱うことはできません。
geditですが、私が持ってるDynalabのフォントでは適切な間隔で表示できています。 gedit-view.c側で怪しげなことはしていないようなので、Pangoのバグでしょうか。
KDEでも再現されるようでしたらfreetype2の問題かもしれません。
Re:いつかは通る道だが (スコア:0)
Re:いつかは通る道だが (スコア:1)
わたしは1.4使いですが、2.0を使うと泣けてきます。
進化の方向性が期待してるものとちがう……。
設定項目減らしすぎ。
# Nautilus2はのぞきます。