アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
Re:LinuxデスクトップがMac OS Xのデスクトップのようになるべきか (スコア:4, すばらしい洞察)
って、ことではなくて。UIの基準・基盤を乱立させないこと、（ある程度）一貫した方針を提供することがチャレンジなのではないでしょうか。
ライトなユーザがLinuxデスクトップに向かったとき、数多のデスクトップ環境とバラバラな方針で作成されたUIを持つアプリケーションが待っている状況がまずい。
ってな感じのことを言いたいのだと深読みしました。
「できる！Linux KDE編」「できる！Linux GNOME編」「できる！Linux Xfce編」「Compizを256倍楽しむ方法」
なんてのから選ばなきゃいけなくて、さらに別のデスクトップ環境に移ると勉強しなおし（って程でもないかも知れないが）って状況はユーザフレンドリではないです。
＃それがLinuxだって意見もあるのは分かる。
妖精哲学の三信
「だらしねぇ」という戒めの心、「歪みねぇ」という賛美の心、「仕方ない」という許容の心
Re: (スコア:1)
Windowsの後追いもMacOSXの後追いも。劣化コピーとか車輪の再発明が
ほんと好きなんだから。
UIも大きなテーマなのは分かるのだけどだけど、GUIの土台の層レベルで
不満（主にファイルシステム）が結構あるのだけど、どうにかならないのかな？
例えば、
1.パス依存。実行ファイルの置き場所を動かしたが最後
→パス非依存。データと実行ファイルの位置関係に束縛しない
2.複雑なリソース／ドライバ管理。ドライバのファイルが何十個もあちこちに
→ドライバはアイコン１つをD&Dするだけ
3.階層ディレクトリのファイル管理。mp3もtxtも完全破綻。
→ラベル／タグなどのメタデータで管理
そう考えると、System7系のUIはなかなか上手く隠蔽出来ていたと思う。
DOSやらターミナルが出発点だとなかなかむずかしいのかな？
Re: (スコア:0)
もしメタデータだけをたよりに探すことになったら，クリックだけじゃなくて条件を入力しないと一覧で出せないですよね(UIで工夫できるかもしれないけど)。でも，「どこにあるか」という情報はないわけだから，「何なのか」とか「いつ作られたのか」とかそういう条件を使っていたら，とても探し出すのに面倒になるでしょう。
例えばこの間のプロジェクトのファイルはどこにいったかな？とかね。
ファイルタイプだけだと必要なものが出てこないかもしれないし、日付条件だけなら要らないものまで出てくるだろうし。
そういうときはどう対処するのですか？
#階層化されていないけどフォルダ名別に出せる，ということだったら許容範囲ですが。
Re: (スコア:0)
「この間のプロジェクト」というスマートフォルダを定義しておけばクリックひとつですが
いちいち脳に場所を記憶しておく間抜けはもうごめんだね
Re: (スコア:1)
と言うか、個人の感覚でメタ情報なんてあいまいなもの付けられたら後から検索なんてできんでしょ。
「この間のプロジェクト」が常に「この間のプロジェクト」であるはずがないわけで。
（見方、切り方は様々ですから）
Re: (スコア:0)
見方や切り口がさまざまだから、階層ディレクトリで割り付けるのは
ダメなのだけど、わかってないなぁ
先コメントでも出てたけど、階層呪縛ってほんとありますよ
古い人って悲しい位の階層ディレクトリ脳で、
ＳＩ現場の文書管理なんて、プロジェクトの後半戦は笑っちゃう
くらい破綻しています。
Re:LinuxデスクトップがMac OS Xのデスクトップのようになるべきか (スコア:1)
> ダメなのだけど、わかってないなぁ
他人が作った階層構造の中から目的の文書を探すことほどイライラすることはないよね。
微妙にネーミングのニュアンスが違って「なんでそっちに入ってんねん！」と言いたくなることがあったり、
一階層目の分類がこっちの目的に合ってないとその階層を横断してあちこちのフォルダを開いて回らないといけなくて
結局全フォルダをfind & grepしてしまうとかよくある話。
> ＳＩ現場の文書管理なんて、プロジェクトの後半戦は笑っちゃう
> くらい破綻しています。
最初にディレクトリ構成のポリシーを決めてかかれという意見もあったけど、
ファイルを作成していく前に決めたディレクトリ構成ってコードを書く前に作った仕様書みたいなもんで、
実際に始めてみないとわからない不都合が必ず出てくる。
実際文書を作ってみると「Aに入れるべきかBに入れるべきか迷う(どちらの性質もある)」とか、新たに細分化しないとだめとか、
そもそも階層分けを考えた奴が現場をわかってなくて根本的にだめだめｗとかよくある話だけど、そこで柔軟に対応していくことができない。
＃柔軟にってのは「新たな分類に対応するディレクトリを追加する」とかいう簡単な話じゃなくて
＃「3階層目と4階層目は入れ替えないと使いにくくて仕方ない！」みたいなレベルの話。
ていうか勝手にディレクトリ構成変えたらポリシーの意味ないね、そういえばｗ