理想的なUI【ユーザインタフェース】を考える
1 ：梨：
単刀直入に、UIの理想形を追求します。
「Win vs Mac」対決は下記の関連スレに譲りますが、
何を理想としているかがわかれば、決着はすぐにつくはずです。
Mac VS. WinどっちのUIが優れているか対決！
http://pc.2ch.net/test/read.cgi/jobs/996135239/
なんだこりゃ? マクの破綻したGUI
http://pc.2ch.net/test/read.cgi/jobs/997160386/
Win<UNIXだからUNIX＋MacGUIが最強！
http://pc.2ch.net/test/read.cgi/jobs/1005134807/
「Win vs Mac」対決は下記の関連スレに譲りますが、
何を理想としているかがわかれば、決着はすぐにつくはずです。
Mac VS. WinどっちのUIが優れているか対決！
http://pc.2ch.net/test/read.cgi/jobs/996135239/
なんだこりゃ? マクの破綻したGUI
http://pc.2ch.net/test/read.cgi/jobs/997160386/
Win<UNIXだからUNIX＋MacGUIが最強！
http://pc.2ch.net/test/read.cgi/jobs/1005134807/
|
|
|
2 ：梨：02/09/29 13:27
最初のお題は「ゴミ箱」。
1つの動作（ゴミ箱へのドロップ）に、
2つ以上の意味（ファイルの削除とボリュームのイジェクト）があるけれど、
対象によって動作が変わるような仕組みは、理想的なんだろか？
ゴミ箱の他に取り出し用の操作（Windowsだと右クリック）を用意して、
ゴミ箱はファイルの削除に徹した方がわかりやすいのでは無いだろうか？
なんて話で、どうでしょう。
1つの動作（ゴミ箱へのドロップ）に、
2つ以上の意味（ファイルの削除とボリュームのイジェクト）があるけれど、
対象によって動作が変わるような仕組みは、理想的なんだろか？
ゴミ箱の他に取り出し用の操作（Windowsだと右クリック）を用意して、
ゴミ箱はファイルの削除に徹した方がわかりやすいのでは無いだろうか？
なんて話で、どうでしょう。
3 ：村澤：02/09/29 13:31
／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
| いまだ2ゲットー
＼＿＿＿＿＿＿＿ ＿＿＿＿＿＿＿
∨
∧＿∧ ／
⊂ ⌒（ ´∀【◎】 ｶｼｬ!
≡≡ ⊂＿ ＿つ９ ＼
ｽﾞｻﾞｰｰｰｰｰｯ
| いまだ2ゲットー
＼＿＿＿＿＿＿＿ ＿＿＿＿＿＿＿
∨
∧＿∧ ／
⊂ ⌒（ ´∀【◎】 ｶｼｬ!
≡≡ ⊂＿ ＿つ９ ＼
ｽﾞｻﾞｰｰｰｰｰｯ
4 ：村澤：02/09/29 13:34
／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
| いまだ3ゲットー
＼＿＿＿＿＿＿＿ ＿＿＿＿＿＿＿
∨
∧＿∧ ／
⊂ ⌒（ ´∀【◎】 ｶｼｬ!
≡≡ ⊂＿ ＿つ９ ＼
ｽﾞｻﾞｰｰｰｰｰｯ
| いまだ3ゲットー
＼＿＿＿＿＿＿＿ ＿＿＿＿＿＿＿
∨
∧＿∧ ／
⊂ ⌒（ ´∀【◎】 ｶｼｬ!
≡≡ ⊂＿ ＿つ９ ＼
ｽﾞｻﾞｰｰｰｰｰｯ
5 ：村澤：02/09/29 13:35
1つぐらいズレてたってええじゃないかええじゃないか
>>5
2つぐらいズレた投稿がある気がするのは漏れだけか？ｗ
2つぐらいズレた投稿がある気がするのは漏れだけか？ｗ
7 ：●~*：02/09/29 13:45
一応ゴミ箱っていうメタファーが使ってあるけど、冷静に考えてみるとゴミ箱で
ファイル削除ってのも少し変かもしれない、分かりやすくはあるけど。
ぶっちゃけ、焼却炉でも何でもよかったのではないかなぁ。
ファイル削除ってのも少し変かもしれない、分かりやすくはあるけど。
ぶっちゃけ、焼却炉でも何でもよかったのではないかなぁ。
9 ：●~*：02/09/29 13:52
>>2
俺は、不要なファイルを掴んで、すばやく放り投げるようにしたら
ゴミ箱に入って、ゴミ箱にマウス近づけると、中が見えてゴミ箱に
手を突っ込んで、取り出す
ゴミ箱を右ボタンクリックすると火が出て、ゴミに火をつけて燃やす
そんなUIがいいな。
俺は、不要なファイルを掴んで、すばやく放り投げるようにしたら
ゴミ箱に入って、ゴミ箱にマウス近づけると、中が見えてゴミ箱に
手を突っ込んで、取り出す
ゴミ箱を右ボタンクリックすると火が出て、ゴミに火をつけて燃やす
そんなUIがいいな。
旧MacOSの場合、なんかの作業する際にデスクトップっていうけっこう
広い道路を通して、各タスクを連携しているわけで、ゴミ箱はファイルを
削除するっていうよか、目に見えるアイコンを消したいときに使うものなん
かもしれんね。
イジェクト、ファイル削除も、その時目障りなものを見えなくするっていう
役割も果たすわけだし。
作業が単純な時代は、Finderでよかったかもしれないけれど、正直現
状を鑑みると、それほどあれは使いやすいものではないと思うよ。
広い道路を通して、各タスクを連携しているわけで、ゴミ箱はファイルを
削除するっていうよか、目に見えるアイコンを消したいときに使うものなん
かもしれんね。
イジェクト、ファイル削除も、その時目障りなものを見えなくするっていう
役割も果たすわけだし。
作業が単純な時代は、Finderでよかったかもしれないけれど、正直現
状を鑑みると、それほどあれは使いやすいものではないと思うよ。
>>9
使うの楽しそうだw
使うの楽しそうだw
12 ：●~*：02/09/29 14:06
で、ここで論議された結果で、
Linuxかなんかのデスクトップ作るんですか？
もしくはKDEとかGNOMEに企画提出するの？
それとも妄想と談話で終わるの？
Linuxかなんかのデスクトップ作るんですか？
もしくはKDEとかGNOMEに企画提出するの？
それとも妄想と談話で終わるの？
13 ：梨：02/09/29 14:12
>>12
それは旧板の事ですから、妄想と談話で終わります。ｗ
つーか、理想形がまとまってもいないのに行動考えても仕方ないかと。
まずは「考える」で、その後にいい成果が出たら活用法でも考える、と。
>>9
漏れはゴミは箱から取り出してゴミ捨て場に持っていった段階で終わりなので、
「ゴミ箱を空にする」動作は別に今のままでもいいなあｗ
>>8
メタファは後でいいやｗ
>>7
Macが先の人は「そういうもんだから」という納得の仕方をしてると思うんだけど。
それは旧板の事ですから、妄想と談話で終わります。ｗ
つーか、理想形がまとまってもいないのに行動考えても仕方ないかと。
まずは「考える」で、その後にいい成果が出たら活用法でも考える、と。
>>9
漏れはゴミは箱から取り出してゴミ捨て場に持っていった段階で終わりなので、
「ゴミ箱を空にする」動作は別に今のままでもいいなあｗ
>>8
メタファは後でいいやｗ
>>7
Macが先の人は「そういうもんだから」という納得の仕方をしてると思うんだけど。
>>12
Linuxのデスクトップ環境って、なんかアプローチ変な気がするよ。
新規ユーザーが、なんでウインドウズと同じようでありながら、出来の悪いもの使うと思うんだろう。
自分たちがあれを使いたいから作ってるんなら、文句なしだけど。
Linuxのデスクトップ環境って、なんかアプローチ変な気がするよ。
新規ユーザーが、なんでウインドウズと同じようでありながら、出来の悪いもの使うと思うんだろう。
自分たちがあれを使いたいから作ってるんなら、文句なしだけど。
15 ：●~*：02/09/29 14:19
16 ：梨：02/09/29 14:20
たとえば、「ゴミ箱」が「物を安全にシステムの外に追いやる」という点で、
動作は異なるが目的は同じである、としよう。
リムーバブルボリュームを「ゴミにする」のは、メディアを排出すること。
ファイルを「ゴミ」にするのは、削除すること。（※語弊含む）
たとえば、このポリシーを徹底するのであれば、
「ゴミにする」事が出来るものはすべてゴミ箱への操作で良いと思うのよ。
固定ディスクボリュームを「ゴミにする」のは、フォーマットすること。
アプリケーションを「ゴミにする」のは、アンインストールすること。
でも、そうする事で意味は増え続けて、ややこしくなる。
最近のMacは、それを踏まえてアイコンへの動作を単機能にしたのでは無いかな。
動作は異なるが目的は同じである、としよう。
リムーバブルボリュームを「ゴミにする」のは、メディアを排出すること。
ファイルを「ゴミ」にするのは、削除すること。（※語弊含む）
たとえば、このポリシーを徹底するのであれば、
「ゴミにする」事が出来るものはすべてゴミ箱への操作で良いと思うのよ。
固定ディスクボリュームを「ゴミにする」のは、フォーマットすること。
アプリケーションを「ゴミにする」のは、アンインストールすること。
でも、そうする事で意味は増え続けて、ややこしくなる。
最近のMacは、それを踏まえてアイコンへの動作を単機能にしたのでは無いかな。
梨はなぜそんなにややこしく物事を変換できるのか。
>>15
べつに、返答しているつもりはないが。
逆に問うているんだよ。
必ずしも、GUIでなくてもいいでしょ、Linuxは。
初心者が導入しやすいCUIのあり方を考えてもいいわけで。
実際使っているユーザーや普及させようと頑張っている人から、
なんでそういう声が上がらんのか、不思議でたまらん。
新しいこと考えるのは、しんどいけど。
べつに、返答しているつもりはないが。
逆に問うているんだよ。
必ずしも、GUIでなくてもいいでしょ、Linuxは。
初心者が導入しやすいCUIのあり方を考えてもいいわけで。
実際使っているユーザーや普及させようと頑張っている人から、
なんでそういう声が上がらんのか、不思議でたまらん。
新しいこと考えるのは、しんどいけど。
19 ：梨：02/09/29 14:27
>>15
「理想的なUIを考える」という表題だけで、先の展望は見えてると思うが。
君が望むのであれば、
「理想的なUIを考えるスレの結果を企画書にして提出するスレ」
でも立てて音頭を取ればいいと思う。
少なくともここは２ちゃんねる内のスレッドに過ぎない訳だから、
ここに書き込まれた内容を誰がどのように扱うか、漏れが制限する権利はない。
具体的な行動を明確にしたくない理由は、
企画書を出すなら出す先に対してアプローチが変わるから。
Linuxで作るならLinuxに向いたアプローチしか出来なくなるから。
OSネイティブなUIなんてのは語り尽くされたし、
「このOSではそれが仕様だから」と言われてしまえばそれまでだと思う。
「理想的なUIを考える」という表題だけで、先の展望は見えてると思うが。
君が望むのであれば、
「理想的なUIを考えるスレの結果を企画書にして提出するスレ」
でも立てて音頭を取ればいいと思う。
少なくともここは２ちゃんねる内のスレッドに過ぎない訳だから、
ここに書き込まれた内容を誰がどのように扱うか、漏れが制限する権利はない。
具体的な行動を明確にしたくない理由は、
企画書を出すなら出す先に対してアプローチが変わるから。
Linuxで作るならLinuxに向いたアプローチしか出来なくなるから。
OSネイティブなUIなんてのは語り尽くされたし、
「このOSではそれが仕様だから」と言われてしまえばそれまでだと思う。
20 ：梨：02/09/29 14:29
>>17
上で企画を出すとかLinuxで開発するとか身構えちゃう人がいる通りに、
ややこしい話をするスレである事は百も承知なので。
>>18
声はあがっているよ。どういうアプローチかはまだ知らないけど、
あれはUIレベルでの改善じゃなくて、アプリのラインナップ的な改善にも見える。
上で企画を出すとかLinuxで開発するとか身構えちゃう人がいる通りに、
ややこしい話をするスレである事は百も承知なので。
>>18
声はあがっているよ。どういうアプローチかはまだ知らないけど、
あれはUIレベルでの改善じゃなくて、アプリのラインナップ的な改善にも見える。
21 ：●~*：02/09/29 14:33
壁キャッチボールスレになってしまった訳だが。
22 ：梨：02/09/29 14:34
>>16の続き。
言い換えれば
「メタファとして統一出来ないものを統一してはいけない」
って事なんだろうね。
ゴミ箱は「捨てようと思った物を溜めておいて、取り出したり削除出来る」
から、ああいうメタファになったのであって、
既に箱では無く、ドロップすると即座にメディアを排出する
「イジェクト機能」とは統一出来ないように見える。
そこで新しい概念としてAppleが打ち出したのは、
「メタファ」に依存せずに、ターゲットが違うと、アイコン自体の形を変えて、
「物を安全にシステムの外に追いやる機能」として括ったんだろうね。
ごみを捨てる時はごみ箱になって、
CDを焼却する（？）時には焼却炉になる。
これで、「ターゲットによって、目的は同じでも動作が異なりますよ」
と主張出来ている事になるわけだ。
言い換えれば
「メタファとして統一出来ないものを統一してはいけない」
って事なんだろうね。
ゴミ箱は「捨てようと思った物を溜めておいて、取り出したり削除出来る」
から、ああいうメタファになったのであって、
既に箱では無く、ドロップすると即座にメディアを排出する
「イジェクト機能」とは統一出来ないように見える。
そこで新しい概念としてAppleが打ち出したのは、
「メタファ」に依存せずに、ターゲットが違うと、アイコン自体の形を変えて、
「物を安全にシステムの外に追いやる機能」として括ったんだろうね。
ごみを捨てる時はごみ箱になって、
CDを焼却する（？）時には焼却炉になる。
これで、「ターゲットによって、目的は同じでも動作が異なりますよ」
と主張出来ている事になるわけだ。
23 ：●~*：02/09/29 14:36
>>20
身構えてる訳じゃ無くて、実のならない木に栄養を与えてもどうしようも無いという事っす。
身構えてる訳じゃ無くて、実のならない木に栄養を与えてもどうしようも無いという事っす。
>>20
あくまで、ちょっとインストールししてみての感想なんだが、なんかVineにはバカにされた気がしたw
GUIアプリケーションの設定やらなんやらは、ウイソ位には簡単にできるけれども、それなら今ある
ウイソを使うよって話で。
その奥に進むのになんか訳の分からん障害がたくさんあるみたいな感じだよ。
Gentooはインストールすら出来なかったけども、オモシロイとおもった。
もうチョイ分かりやすかったら、入門にぴったりじゃないのかな。
日本での評判はどうなんだろ。
っていうかUIの話じゃないね、これ。
あくまで、ちょっとインストールししてみての感想なんだが、なんかVineにはバカにされた気がしたw
GUIアプリケーションの設定やらなんやらは、ウイソ位には簡単にできるけれども、それなら今ある
ウイソを使うよって話で。
その奥に進むのになんか訳の分からん障害がたくさんあるみたいな感じだよ。
Gentooはインストールすら出来なかったけども、オモシロイとおもった。
もうチョイ分かりやすかったら、入門にぴったりじゃないのかな。
日本での評判はどうなんだろ。
っていうかUIの話じゃないね、これ。
>>24
インストーラーも重要なUIです。
インストーラーも重要なUIです。
LinuxのKDEというかKonquerorの目指す方向性はいいと思うんだが。
今はLinuxなんてhttp://unit.aist.go.jp/it/knoppix/
でちょっと触るぐらいだが、
いまのBetaが完成したら本格的に使おうと思っている。
ただ、なんでも自前でやろうとする姿勢はうなずけない。
今はLinuxなんてhttp://unit.aist.go.jp/it/knoppix/
でちょっと触るぐらいだが、
いまのBetaが完成したら本格的に使おうと思っている。
ただ、なんでも自前でやろうとする姿勢はうなずけない。
27 ：梨：02/09/29 14:42
なんかまわりくどい言い方だな。
「アイコンが変わってしまうから、メタファはどうでも良くなった」
「インタフェースを沢山作って、やりたい事と動作が一対一になるのがWin。
1つのインタフェースで似たような目的が達成出来るのがMac」
という事です。簡単に言うと。
これをOOP用語で「多態性」(ポリモーフィズム)って言うんだけど、
これを採用する事の問題は、
「本当にMacは様々な物を多態性で表現出来るのか？」
という点にあると思うのです。どうでしょ？
「アイコンが変わってしまうから、メタファはどうでも良くなった」
「インタフェースを沢山作って、やりたい事と動作が一対一になるのがWin。
1つのインタフェースで似たような目的が達成出来るのがMac」
という事です。簡単に言うと。
これをOOP用語で「多態性」(ポリモーフィズム)って言うんだけど、
これを採用する事の問題は、
「本当にMacは様々な物を多態性で表現出来るのか？」
という点にあると思うのです。どうでしょ？
30 ：梨：02/09/29 14:49
>>23
漏れはまだ「考える」レベルでがんばってるんで、
企画書が出せるレベルにいる君は、Linux開発者のMLなり
なんなりに行って直接意見交換をした方が良いと思うよ。
繰り返すけど、特定のUI開発者の身になるために
考える訳では無いので、即物的な貢献はどこにも無いです。
>>24
「まずはWinを目指す」というだけでも成長したんでないのかね。
結果的にWinをまねる必要なんかは全くないわけだけれど。
>>26
うわ、これ初めて知った。面白そう。
オンメモリブートに使えないかなー。ふふふ。
漏れはまだ「考える」レベルでがんばってるんで、
企画書が出せるレベルにいる君は、Linux開発者のMLなり
なんなりに行って直接意見交換をした方が良いと思うよ。
繰り返すけど、特定のUI開発者の身になるために
考える訳では無いので、即物的な貢献はどこにも無いです。
>>24
「まずはWinを目指す」というだけでも成長したんでないのかね。
結果的にWinをまねる必要なんかは全くないわけだけれど。
>>26
うわ、これ初めて知った。面白そう。
オンメモリブートに使えないかなー。ふふふ。
31 ：梨：02/09/29 14:53
>>29
「Macは直感的だ！ おおざっぱにでも扱えるから！」という言い分と、
「Winはわかりやすい！ 一覧から目的の動作を探すだけだから！」
という言い分のいいとこどりをする方法が無いかなー、と。
Winが細かいのは、厳密にやりたい事を指定させるからだと思うよ。
自分のしたい事がわかってれば、操作はわかりやすい。
「Macは直感的だ！ おおざっぱにでも扱えるから！」という言い分と、
「Winはわかりやすい！ 一覧から目的の動作を探すだけだから！」
という言い分のいいとこどりをする方法が無いかなー、と。
Winが細かいのは、厳密にやりたい事を指定させるからだと思うよ。
自分のしたい事がわかってれば、操作はわかりやすい。
GUI＝デスクトップということではないような気がするのは折れだけ？
もうちょっといろいろな可能性を考えてみると話が広がる気がする。
もうちょっといろいろな可能性を考えてみると話が広がる気がする。
補足
ゴミ箱というのはデスクトップという概念があるから存在する。
理想的なUIを考えるというｽﾚﾀｲなので、ゴミ箱一つにこだわらずにもっといろいろ考えてみてもいいのでは思ったので。
わかりにくくてｽﾏｿ
ゴミ箱というのはデスクトップという概念があるから存在する。
理想的なUIを考えるというｽﾚﾀｲなので、ゴミ箱一つにこだわらずにもっといろいろ考えてみてもいいのでは思ったので。
わかりにくくてｽﾏｿ
34 ：梨：02/09/29 15:01
>>32
問題提起のために、現状からボトムアップ式に話そうかと思ってたんよ。
「Finderからファイルシステム以外の物が、
まるでファイルのように見えてしまうUI」
を次のお題にしてみたり、
「Dockやタスクバーを超える作業の管理方法」を議論してみたり。
そんな事しなくても「これが理想的だ！」ってのが既にある程度あるなら、
そいつを聞いてみたほうが圧倒的に話は早いだろうなあ。よろしくです。
問題提起のために、現状からボトムアップ式に話そうかと思ってたんよ。
「Finderからファイルシステム以外の物が、
まるでファイルのように見えてしまうUI」
を次のお題にしてみたり、
「Dockやタスクバーを超える作業の管理方法」を議論してみたり。
そんな事しなくても「これが理想的だ！」ってのが既にある程度あるなら、
そいつを聞いてみたほうが圧倒的に話は早いだろうなあ。よろしくです。
35 ：梨：02/09/29 15:03
>>33
補足
「UI」って書いたので、「GUI」じゃなくてもいいです。
ただ「脳波を使って、考えたことをそのまま実行する」みたいなのは嫌だな。ｗ
今使っているコンピュータに対して実現可能なネタがよろしいかと。
補足
「UI」って書いたので、「GUI」じゃなくてもいいです。
ただ「脳波を使って、考えたことをそのまま実行する」みたいなのは嫌だな。ｗ
今使っているコンピュータに対して実現可能なネタがよろしいかと。
36 ：名無しさん＠お腹いっぱい：02/09/29 15:10
sage
37 ：梨：02/09/29 15:19
もうちょっと書くか。
「ゴミ箱」アイコンが形を変えたのと同じく、
「デスクトップ」が、現実の「机」と同じである必要性は全くない。
状況によって形を変えて、時にはディスクの中になったり、
時には作業スペースになったり、時にはメニューや通知に成り下がる。
MacユーザにとってOS9が「直感的」だったのは、
実は「メタファ」では無くて、
あれとそれとを同じように扱える「多態性」だったのでは無かろうか？
OSXになって、「あれはあれ、それはそれ」と厳密に区別されたせいで、
「多態性」を諦めさせられて不便になったような気がするんだが。
「ゴミ箱」アイコンが形を変えたのと同じく、
「デスクトップ」が、現実の「机」と同じである必要性は全くない。
状況によって形を変えて、時にはディスクの中になったり、
時には作業スペースになったり、時にはメニューや通知に成り下がる。
MacユーザにとってOS9が「直感的」だったのは、
実は「メタファ」では無くて、
あれとそれとを同じように扱える「多態性」だったのでは無かろうか？
OSXになって、「あれはあれ、それはそれ」と厳密に区別されたせいで、
「多態性」を諦めさせられて不便になったような気がするんだが。
38 ：梨：02/09/29 15:23
「ゴミ箱」はOSXで良くなったけど、
「機能拡張」はわかりにくくなったと思う。
「システムフォルダも所詮フォルダだからコピーが自由」ってのも無くなったし、
「コントロールパネルも所詮フォルダ（以下略）」も、
設定がHomeとetcとNetInfoに分かれたのも、
「多態性によって得られる操作の統一感」を損なったが故に不便だな、と。
「機能拡張」はわかりにくくなったと思う。
「システムフォルダも所詮フォルダだからコピーが自由」ってのも無くなったし、
「コントロールパネルも所詮フォルダ（以下略）」も、
設定がHomeとetcとNetInfoに分かれたのも、
「多態性によって得られる操作の統一感」を損なったが故に不便だな、と。
39 ：●~*：02/09/29 15:23
40 ：32：02/09/29 15:27
優しいスレですね。
デスクトップのメリットというのはなんなのか、ということを考えてみたいです。
デスクトップがなく、プレステやファミコンのようにカートリッジ形式にして、ソフトを本体に突っ込んだら即起動、みたいなものだったらいちいちデスクトップを経由する必要なんてないのではと思う。
こうすればコピーもある程度防止できるしソフトがOSに悪さしてコンフリクトが起きるようなこともなくなるのでは・・・。それにディレクトリとか階層とかいちいち考える必要ないし、そもそもOSというものを感じなくて済むようになるのでは？
まあでも複数のアプリを同時に起動できないという罠（カートリッジ増やせばいい？）。しかもソフト間の連携とれないし。普通に考えたらﾀﾞﾒだけど、用途が限られていたら一つの方向性としては可能だと思われ。
こんな感じで幅広い発想と議論が出来たらおもしろいと思う。
なんか一人で違う方向に突っ走ってる気が・・・
デスクトップのメリットというのはなんなのか、ということを考えてみたいです。
デスクトップがなく、プレステやファミコンのようにカートリッジ形式にして、ソフトを本体に突っ込んだら即起動、みたいなものだったらいちいちデスクトップを経由する必要なんてないのではと思う。
こうすればコピーもある程度防止できるしソフトがOSに悪さしてコンフリクトが起きるようなこともなくなるのでは・・・。それにディレクトリとか階層とかいちいち考える必要ないし、そもそもOSというものを感じなくて済むようになるのでは？
まあでも複数のアプリを同時に起動できないという罠（カートリッジ増やせばいい？）。しかもソフト間の連携とれないし。普通に考えたらﾀﾞﾒだけど、用途が限られていたら一つの方向性としては可能だと思われ。
こんな感じで幅広い発想と議論が出来たらおもしろいと思う。
なんか一人で違う方向に突っ走ってる気が・・・
梨が長文を書く時は、会社で嫌な事があったという法則。
43 ：梨：02/09/29 16:00
>>41
別に嫌なことは無いがｗ
最近、日常生活にポリモーフィズムを導入したくて、
それをとっかかりにしてUIの話がしたかった、というのはあるけどね。
>>39
ウィナに言わせれば「ゴミとCDはゴミ箱へ」というように
行動を「統一」される事が嫌なのさ。
マカは逆に、行動を「具体化」させられるのが嫌なんだろうな。
Winは「具体的な行動を詳細に」行わされて、
Macは「抽象的な行動を統一して」行わされる。
別のスレで「Macはオブジェクト的だ」と言ってた人がいたけど、
オブジェクト的なのはWinも一緒で、MacとWinが違うのは、
「抽象的かどうか」すなわち「OOP的かどうか」なんだと思ったよ。
別に嫌なことは無いがｗ
最近、日常生活にポリモーフィズムを導入したくて、
それをとっかかりにしてUIの話がしたかった、というのはあるけどね。
>>39
ウィナに言わせれば「ゴミとCDはゴミ箱へ」というように
行動を「統一」される事が嫌なのさ。
マカは逆に、行動を「具体化」させられるのが嫌なんだろうな。
Winは「具体的な行動を詳細に」行わされて、
Macは「抽象的な行動を統一して」行わされる。
別のスレで「Macはオブジェクト的だ」と言ってた人がいたけど、
オブジェクト的なのはWinも一緒で、MacとWinが違うのは、
「抽象的かどうか」すなわち「OOP的かどうか」なんだと思ったよ。
44 ：梨：02/09/29 16:05
>>40
ハードディスクが出来るまでは、そうだったんだよね。
そのような形態にしなかったのは、単にコスト的な問題にも見えるから、
セキュアなSDカードみたいな物にアプリを入れて売るってのは楽しいと思う。
少なくとも今みたいな、OSとアプリが糞味噌になってる状態は打破できるね。
その打破を世の中で一番好まないのはMSなんだと思うけど。ｗ
ちなみに>>26で紹介されてるCDが、
「ソフト本体に突っ込んだら即起動して使えるLinux」です。
ハードウェアの互換性を確保するためと、基本的な操作性を提供するために、
OSはハードディスクに存在しててもいいと思うんで、
それを踏まえてカートリッジ式になってるなら、良いと思う。目から鱗。
ハードディスクが出来るまでは、そうだったんだよね。
そのような形態にしなかったのは、単にコスト的な問題にも見えるから、
セキュアなSDカードみたいな物にアプリを入れて売るってのは楽しいと思う。
少なくとも今みたいな、OSとアプリが糞味噌になってる状態は打破できるね。
その打破を世の中で一番好まないのはMSなんだと思うけど。ｗ
ちなみに>>26で紹介されてるCDが、
「ソフト本体に突っ込んだら即起動して使えるLinux」です。
ハードウェアの互換性を確保するためと、基本的な操作性を提供するために、
OSはハードディスクに存在しててもいいと思うんで、
それを踏まえてカートリッジ式になってるなら、良いと思う。目から鱗。
>>44
そうそう、OSはHDDに入ってる状態です。これだともうホント最小限の構成で済むから構造も単純かできると思う。
で、冷静にこのことについて考えいたのだが、
>>40で述べたことを実現できるのは、MSかSONY＋IBMだと思われ。
MSはまあおいといて、ここで問題なのはSONY＋IBM。
今のプレステ２ですでにLinuxが動くことは実践済み。じゃあ、ということでプレステ３になったときにどうなるかを考えると・・・・。もう40で言ったようなことまんま実現可能なわけよね。
しかもCELLとかいって並列分散処理を目指すようなCPU積むってんだから、これもうやんなっちゃうね。
SONYの家庭用サーバにファイルは保存。ソフトはカートリッジ式で。OSはプレステの中に搭載。重い処理も分散処理で！。動画像編集はHDD＋DVDレコーダーでどうぞ。みたいな感じで・・・。一家に何台もプレステが・・・。
ってかもうすでに実現してある技術ばっかじゃん！！あとは実行のみ。MSの次はVAIOですか。気づいたら
PC板ん中にVAIOとかできてそう。VAIOﾏﾝｾｰがｲﾊﾟｰｲいそうだ。
鬱だ。
そうそう、OSはHDDに入ってる状態です。これだともうホント最小限の構成で済むから構造も単純かできると思う。
で、冷静にこのことについて考えいたのだが、
>>40で述べたことを実現できるのは、MSかSONY＋IBMだと思われ。
MSはまあおいといて、ここで問題なのはSONY＋IBM。
今のプレステ２ですでにLinuxが動くことは実践済み。じゃあ、ということでプレステ３になったときにどうなるかを考えると・・・・。もう40で言ったようなことまんま実現可能なわけよね。
しかもCELLとかいって並列分散処理を目指すようなCPU積むってんだから、これもうやんなっちゃうね。
SONYの家庭用サーバにファイルは保存。ソフトはカートリッジ式で。OSはプレステの中に搭載。重い処理も分散処理で！。動画像編集はHDD＋DVDレコーダーでどうぞ。みたいな感じで・・・。一家に何台もプレステが・・・。
ってかもうすでに実現してある技術ばっかじゃん！！あとは実行のみ。MSの次はVAIOですか。気づいたら
PC板ん中にVAIOとかできてそう。VAIOﾏﾝｾｰがｲﾊﾟｰｲいそうだ。
鬱だ。
と、まあ妄想はそれくらいにして、本当にカートリッジ式みたいな方法は理想的なUIと言えるのか考えてみたい。
確かにOSを意識させないことはいいことだと思われるが、その分柔軟性に欠けるという欠点もあるわけで。
そこんとこをもうちょっと考えてみたいですな。
あと、使う人によっても変わってくることを考慮しなければいかんですな。
たとえ今パソコン使ってない人にとって使いやすくとも、今ｳｨｿやﾏｸ使ってる人にとっても使いやすいものにならなければ意味がないからね。
確かにOSを意識させないことはいいことだと思われるが、その分柔軟性に欠けるという欠点もあるわけで。
そこんとこをもうちょっと考えてみたいですな。
あと、使う人によっても変わってくることを考慮しなければいかんですな。
たとえ今パソコン使ってない人にとって使いやすくとも、今ｳｨｿやﾏｸ使ってる人にとっても使いやすいものにならなければ意味がないからね。
47 ：梨：02/09/30 11:31
スレタイトル、UIじゃなくて「ヒューマンインタフェース」にすれば良かったね。
>>45-46
Appleがやっても良いんじゃないかと思うし、
今のハードディスク主体のPCから移行する必然性が無いとどうしようもない気もする。
まーでも、OSをファームウェアみたいな物だと捉えれば、
利用者にとってはファミコン感覚（ビデオデッキ感覚でもいい）なんだし、
ユーザビリティとコピー防止の両方の利点から、
ソフトハウスやサポートをするPC販売メーカに訴求する事は可能かと。
でも、並列分散処理の解釈は微妙に違う気がするよｗ
>>45-46
Appleがやっても良いんじゃないかと思うし、
今のハードディスク主体のPCから移行する必然性が無いとどうしようもない気もする。
まーでも、OSをファームウェアみたいな物だと捉えれば、
利用者にとってはファミコン感覚（ビデオデッキ感覚でもいい）なんだし、
ユーザビリティとコピー防止の両方の利点から、
ソフトハウスやサポートをするPC販売メーカに訴求する事は可能かと。
でも、並列分散処理の解釈は微妙に違う気がするよｗ
48 ：梨：02/09/30 11:43
ソフトウェア的な視点から、>>40のアイデアを設計してみる。
「唯物主義的ヒューマンインタフェース」とでもしておくか。
まず、記録媒体は現在世に普及していて、
媒体自体の完全コピーが困難らしい（？）DVD-ROMを標準とする。
ユーザはアプリケーションDVD-ROMを差し替える事で、
インストールせずに、DVD-ROMから直接アプリを実行できる。
データは、メモリーカード（FDのような物、統一規格が望ましい）
に記録される。
OSは本体ハードディスクにインストールされ、
システムの管理、デバイスの管理、UIの提供に専念する。
これらが大原則。
で、上級ユーザもしくはアプリ併用のために、
DVD-ROMの内容をまるごとHDDにコピーする事が出来る。
（従来のインストール作業に相当。印象としては仮想CDみたいな感じ）
さらに、メモリーカードのかわりに、擬似的にHDDを利用できる。
基本的には、メモリーカードと同容量の仮想領域を作成して、
カード１枚に丸ごと復元／待避が可能となる。
「唯物主義的ヒューマンインタフェース」とでもしておくか。
まず、記録媒体は現在世に普及していて、
媒体自体の完全コピーが困難らしい（？）DVD-ROMを標準とする。
ユーザはアプリケーションDVD-ROMを差し替える事で、
インストールせずに、DVD-ROMから直接アプリを実行できる。
データは、メモリーカード（FDのような物、統一規格が望ましい）
に記録される。
OSは本体ハードディスクにインストールされ、
システムの管理、デバイスの管理、UIの提供に専念する。
これらが大原則。
で、上級ユーザもしくはアプリ併用のために、
DVD-ROMの内容をまるごとHDDにコピーする事が出来る。
（従来のインストール作業に相当。印象としては仮想CDみたいな感じ）
さらに、メモリーカードのかわりに、擬似的にHDDを利用できる。
基本的には、メモリーカードと同容量の仮想領域を作成して、
カード１枚に丸ごと復元／待避が可能となる。
49 ：梨：02/09/30 11:50
>>48
この案の利点は、現状のハードウェアで容易に実現が可能だという事だ。
もちろん、DVD-ROMドライブを2機にして、片方をシステム専用にするとか、
ROMを搭載して更新不可能なシステムを提供する展望もありそう。
この案の一番の欠点は、ソフトウェアのアップデートが出来なくなる事。
これは、DVD-ROM以外の書き込み可能なハードウェア(DVDでもいいが)
を扱う事で緩和出来るかも知れない。
この案の問題点は、
技術者にとって、それでも多少なりの不便さを抱かせてしまうこと、かも。
この案の利点は、現状のハードウェアで容易に実現が可能だという事だ。
もちろん、DVD-ROMドライブを2機にして、片方をシステム専用にするとか、
ROMを搭載して更新不可能なシステムを提供する展望もありそう。
この案の一番の欠点は、ソフトウェアのアップデートが出来なくなる事。
これは、DVD-ROM以外の書き込み可能なハードウェア(DVDでもいいが)
を扱う事で緩和出来るかも知れない。
この案の問題点は、
技術者にとって、それでも多少なりの不便さを抱かせてしまうこと、かも。
>>48
PS2みたいだね。
PS2みたいだね。
51 ：梨：02/09/30 12:24
やっぱり、DVD-RAM（書き込めれば何でもいいけど）の方がいいなあ。
>>50
そうよ。PS2に限らず、どのゲーム機も似たり寄ったりだよね。
それをゲーム機じゃなくてパソコンでやってしまおうってだけ。
ゲーム機のヒューマンインタフェースは洗練されてると思うよ。
>>50
そうよ。PS2に限らず、どのゲーム機も似たり寄ったりだよね。
それをゲーム機じゃなくてパソコンでやってしまおうってだけ。
ゲーム機のヒューマンインタフェースは洗練されてると思うよ。
>>52
売りたい物と買いたい物は別なんですよ、
とか言ったら、デベロッパーとしての腕を疑われるかな。
（↑うさんくさすぎて疑う以前の問題な訳だが）
まーでも、律儀にテスト用にWinXPインストール済みPCを用意するくらい、
一般の方々に迎合する覚悟は出来てまっせ。
Windowsで商売するなら常識的、という気もする。あーあ。
売りたい物と買いたい物は別なんですよ、
とか言ったら、デベロッパーとしての腕を疑われるかな。
（↑うさんくさすぎて疑う以前の問題な訳だが）
まーでも、律儀にテスト用にWinXPインストール済みPCを用意するくらい、
一般の方々に迎合する覚悟は出来てまっせ。
Windowsで商売するなら常識的、という気もする。あーあ。
>>53
2kで動いてXPで動かないものもそろそろ出てきたのかな。（既にあるのかな）
それよりMacは買わないの？
旧板住人として、律儀にテスト用Macを用意とか。
まあ、今Macの新機種買うのは奨めないけどね。
2kで動いてXPで動かないものもそろそろ出てきたのかな。（既にあるのかな）
それよりMacは買わないの？
旧板住人として、律儀にテスト用Macを用意とか。
まあ、今Macの新機種買うのは奨めないけどね。
>>54
ゲームキューブ買って、金無くなっちゃった。てへ。
別に止められたから買わない訳じゃないんだが、
母艦壊れてテンパってた時に、
「余裕無い時にMacは買わないほうがいいよー」
と助言を受けてしまったので、
L5戻ってきて経済状況が安定してから検討しようかと。
ゲームキューブ買って、金無くなっちゃった。てへ。
別に止められたから買わない訳じゃないんだが、
母艦壊れてテンパってた時に、
「余裕無い時にMacは買わないほうがいいよー」
と助言を受けてしまったので、
L5戻ってきて経済状況が安定してから検討しようかと。
>>55
一応、PPCなのね。ｗ
正直、梨がMac買うのが先かアポーが逝くのが先か・・・予測がむずい。
UIの話にもどるけど、最近のHDDカーナビは良いところをついてると思うんだけど、どう？
基本はゲーム機と大差ないかもしれないけど、運転しながら使えるだけあって、なかなか良く考えられていると思うんだけどね。
一応、PPCなのね。ｗ
正直、梨がMac買うのが先かアポーが逝くのが先か・・・予測がむずい。
UIの話にもどるけど、最近のHDDカーナビは良いところをついてると思うんだけど、どう？
基本はゲーム機と大差ないかもしれないけど、運転しながら使えるだけあって、なかなか良く考えられていると思うんだけどね。
>>57
アポゥが逝く前に、梨が逝くに50Xbox
アポゥが逝く前に、梨が逝くに50Xbox
理想的な物を考えてなぜ現状よりめんどくさい方向に行くんだろう。
そうだ
デスクトップに例えずに部屋に例えてUIの名前を考えよう
デスクトップパターン＞カーペット
ゴミ箱＞ゴミ箱
メニューバー＞コントロールメニュー
フォルダ＞フォルダ
他には？
デスクトップに例えずに部屋に例えてUIの名前を考えよう
デスクトップパターン＞カーペット
ゴミ箱＞ゴミ箱
メニューバー＞コントロールメニュー
フォルダ＞フォルダ
他には？
>>57
最近のカーナビについてだけど、確かに良いところついてると思う。
いろいろ機能が増えちゃって今のパソコンみたいになっちゃったら元の木阿弥だけど、今の機能に留めるならもっと使いやすくなる可能性が考えられるし現状でも実用に耐えうる。スピードも現実的なレベルにやっとなったしね。
で、カーナビには音声認識機能がどれも付いてるけど、音声認識が必要とされるものって現在ではこれだけじゃないの？それ以外のモノで音声認識が実用的だったり必要なモノってないような気がする。（障害者用は除く）
それと、トヨタのG-BOOKとかホンダのインターナビ・プレミアムクラブとか各社車のIT化に躍起になってるけど、これってかなりバランスが難しいものだと思う。
あくまで必要最低限のものだけにしないと、大変なことになると思う。もっといろんな機能つけてって、なんか情報受信するたんびに押しつけがましく表示されたら運転に集中できなく恐れあり。
この辺はでも自動運転とかとからんでくるから難しいところだね。
このｽﾚはﾏﾀｰﾘしててｲｲですね。
最近のカーナビについてだけど、確かに良いところついてると思う。
いろいろ機能が増えちゃって今のパソコンみたいになっちゃったら元の木阿弥だけど、今の機能に留めるならもっと使いやすくなる可能性が考えられるし現状でも実用に耐えうる。スピードも現実的なレベルにやっとなったしね。
で、カーナビには音声認識機能がどれも付いてるけど、音声認識が必要とされるものって現在ではこれだけじゃないの？それ以外のモノで音声認識が実用的だったり必要なモノってないような気がする。（障害者用は除く）
それと、トヨタのG-BOOKとかホンダのインターナビ・プレミアムクラブとか各社車のIT化に躍起になってるけど、これってかなりバランスが難しいものだと思う。
あくまで必要最低限のものだけにしないと、大変なことになると思う。もっといろんな機能つけてって、なんか情報受信するたんびに押しつけがましく表示されたら運転に集中できなく恐れあり。
この辺はでも自動運転とかとからんでくるから難しいところだね。
このｽﾚはﾏﾀｰﾘしててｲｲですね。
OQOはいつでるんじゃ～
http://pc3.2ch.net/test/read.cgi/mobile/1033142840/
すっかり忘れていたが、まだでていないらしい。
ﾀﾌﾞﾚｯﾄPCよか、こっちのほうが良い感じだよね。
http://pc3.2ch.net/test/read.cgi/mobile/1033142840/
すっかり忘れていたが、まだでていないらしい。
ﾀﾌﾞﾚｯﾄPCよか、こっちのほうが良い感じだよね。
ここは梨の隔離スレに認定されました。
64 ：梨：02/10/01 11:07
>>56
ちらっと見てみたけど、凄そうね。
でも、次に買うのはゼルダかな、と。
漏れは１本買ったらクリアするまで次のゲームは遊ばない主義なんで、
とりあえずPSOやってきますよ。
>>57
PPC搭載と考えると、C/Pは最高に近いよねｗ
漏れはアポーは当分逝かない気がしてきた。
カーナビの解説求む。
>>60
マイコンピュータ
マイネットワーク
マイドキュメント
マイミュージック
マイピクチャー
あらあら、違和感が無いようなｗ
>>62
買っちゃいそうだが、使い道は思いつかないなｗ
ちらっと見てみたけど、凄そうね。
でも、次に買うのはゼルダかな、と。
漏れは１本買ったらクリアするまで次のゲームは遊ばない主義なんで、
とりあえずPSOやってきますよ。
>>57
PPC搭載と考えると、C/Pは最高に近いよねｗ
漏れはアポーは当分逝かない気がしてきた。
カーナビの解説求む。
>>60
マイコンピュータ
マイネットワーク
マイドキュメント
マイミュージック
マイピクチャー
あらあら、違和感が無いようなｗ
>>62
買っちゃいそうだが、使い道は思いつかないなｗ
http://cycles-of-life.dip.jp/conconcon/mac/
真ん中あたりの使用状況が、スバラシイ。
真ん中あたりの使用状況が、スバラシイ。
66 ：梨：02/10/01 11:15
>>59
過去これまでにある程度技術が発達してきて、
その場の判断とかアドリブで「楽そうな物」を開発したツケってのを、
どこかで整理する事が必要なんだと思う。
「ハードディスクがあれば糞味噌もごっちゃに出来て、
どさくさに紛れてソフトの更新とかウィルス配布したり、
ファイルのメンテをしたりパーティションの管理も出来ます」
というのを、
「ハードディスク内には抽象的なシステム領域と、
仮想アプリケーションDVDと、仮想メモリカードしかありません。
だから、システムとアプリの切り分けもパーティション管理も不要です」
と再定義する事で、アプリの移動やデータの移動を明快に出来るってわけ。
「システムのコピーが簡単に出来る」とか、
「アプリケーションを自由自在に移動できる」というのは、
どこぞのOSユーザさんが最大限に賛辞する機能だと思うんだけどな。
そういった部分が無秩序になる事で、OSXは今のところ不便になったと。
過去これまでにある程度技術が発達してきて、
その場の判断とかアドリブで「楽そうな物」を開発したツケってのを、
どこかで整理する事が必要なんだと思う。
「ハードディスクがあれば糞味噌もごっちゃに出来て、
どさくさに紛れてソフトの更新とかウィルス配布したり、
ファイルのメンテをしたりパーティションの管理も出来ます」
というのを、
「ハードディスク内には抽象的なシステム領域と、
仮想アプリケーションDVDと、仮想メモリカードしかありません。
だから、システムとアプリの切り分けもパーティション管理も不要です」
と再定義する事で、アプリの移動やデータの移動を明快に出来るってわけ。
「システムのコピーが簡単に出来る」とか、
「アプリケーションを自由自在に移動できる」というのは、
どこぞのOSユーザさんが最大限に賛辞する機能だと思うんだけどな。
そういった部分が無秩序になる事で、OSXは今のところ不便になったと。
67 ：梨：02/10/01 11:23
>>61
> 今の機能に留めるならもっと使いやすくなる
> あくまで必要最低限のものだけにしないと、大変なことになると思う。
でも、技術の進化とか消費者心理としては、
「新機能を搭載してより活用の幅が広がる」事を、
デフォルトで期待しているし、その流れは止められないんだよね。
進化するにあたって、
「拡張すべき部分だけの拡張に留めて方向性を定めること」と、
「定めた方向性の束縛から解放されるための努力をすること」を、
常に天秤にかけて開発していかなきゃならんのだろうな。
私見だけど、Winは前者、Macは後者の努力が「足りない」ね。
>>65
無茶な使用だけなら負けないかもｗ
> 今の機能に留めるならもっと使いやすくなる
> あくまで必要最低限のものだけにしないと、大変なことになると思う。
でも、技術の進化とか消費者心理としては、
「新機能を搭載してより活用の幅が広がる」事を、
デフォルトで期待しているし、その流れは止められないんだよね。
進化するにあたって、
「拡張すべき部分だけの拡張に留めて方向性を定めること」と、
「定めた方向性の束縛から解放されるための努力をすること」を、
常に天秤にかけて開発していかなきゃならんのだろうな。
私見だけど、Winは前者、Macは後者の努力が「足りない」ね。
>>65
無茶な使用だけなら負けないかもｗ
（＾＾）
70 ：●~*：03/03/29 00:24
メニューバーってどうよ？
ウインドウズみたいに個別でも別にいいよな？？
今使ってるアプリがどれか分かりやすいし
終了したつもりが別のアプリだったりするし
ウインドウズみたいに個別でも別にいいよな？？
今使ってるアプリがどれか分かりやすいし
終了したつもりが別のアプリだったりするし
71 ：●~*：03/03/29 00:25
まだあったのか、このスレ
結構真面目に語ってるなー昔の漏れ。
UIを語るじゃなくて「ユーザビリティを語る」になってるけど、正解やね。
で、なんとなく、最近の考えでは、
「ユーザがUIをカスタマイズできるべき」
という結論に向かいつつある。
ユーザがカスタマイズしたものは確実だし、
オフィシャルに組み込むことで標準化を追随出来る。
UIを語るじゃなくて「ユーザビリティを語る」になってるけど、正解やね。
で、なんとなく、最近の考えでは、
「ユーザがUIをカスタマイズできるべき」
という結論に向かいつつある。
ユーザがカスタマイズしたものは確実だし、
オフィシャルに組み込むことで標準化を追随出来る。
ほしゅ
74 ：●~*：03/04/13 16:04
OpenDogみたなアプローチかね＞UIのカスタマイズ
OpenDocとCyberDogを混ぜないように。
逝ってきます
いや、そんな急逝せんでも。ｶﾑﾊﾞｰｯｸ!
OpenDocはOLEと比較されるけどﾁｮﾄ違う気がする。
InDesignの方が構造は似てる。用途は全然
違うんだけど。
あと、UIのカスタマイズって結構微妙なんだよね。
標準と大幅に違うからこそ「おおっ！」って思って
ｲﾝｽｺするんだけど、慣れちゃってインパクトが薄れると
あんまり便利じゃなかったりして結局デフォルトに戻る。
かといって標準仕様と大差ない見た目だと
そもそもｲﾝｽｺする気が起きない。
キーバインドとかのカスタマイズも便利なんだけど
つい忘れて人に説明すると話が噛み合わないことも
あったり。
OpenDocはOLEと比較されるけどﾁｮﾄ違う気がする。
InDesignの方が構造は似てる。用途は全然
違うんだけど。
あと、UIのカスタマイズって結構微妙なんだよね。
標準と大幅に違うからこそ「おおっ！」って思って
ｲﾝｽｺするんだけど、慣れちゃってインパクトが薄れると
あんまり便利じゃなかったりして結局デフォルトに戻る。
かといって標準仕様と大差ない見た目だと
そもそもｲﾝｽｺする気が起きない。
キーバインドとかのカスタマイズも便利なんだけど
つい忘れて人に説明すると話が噛み合わないことも
あったり。
>>75
ありがとう
UIのカスタマイズというとせこいレベルだとファイラやランチャなんかも範囲に入るよね
んでそう言うところの多様性をOS自体の仕組みとして提供する事は出来るのかな
現状ではアドオンで色々入れても所詮ネイティブな環境と同じ事は難しいから小手先で誤魔化してしまう事も有るよね
昔はFinderを置き換えてしまうような物もあったけどいまいちだったし
あと昔からのマカーがよく言うアプリケーションがちがくても同じ操作性を補償するというのは
UIのカスタマイズとは基本的に相反するところが有るよね
現状でもUIを自前で処理してるソフトは多いからね
ありがとう
UIのカスタマイズというとせこいレベルだとファイラやランチャなんかも範囲に入るよね
んでそう言うところの多様性をOS自体の仕組みとして提供する事は出来るのかな
現状ではアドオンで色々入れても所詮ネイティブな環境と同じ事は難しいから小手先で誤魔化してしまう事も有るよね
昔はFinderを置き換えてしまうような物もあったけどいまいちだったし
あと昔からのマカーがよく言うアプリケーションがちがくても同じ操作性を補償するというのは
UIのカスタマイズとは基本的に相反するところが有るよね
現状でもUIを自前で処理してるソフトは多いからね
>>78
> んでそう言うところの多様性をOS自体の仕組みとして提供する事は出来るのかな
どうだろうねえ。
漏れはどちらかというと、あるソフトでやったカスタマイズが、
他のソフトや他のPCに対して簡単に反映出来る仕組みを、
OS側で提供できたらいいなーと思う。
もちろん、APIを整備してカスタマイズ可能な状態を作ることも大事だけど、
それは素性の良いソフトがあれば出来る事だし、OSには関係ないからなー。
でも、漏れの発想って、つまるところエンドユーザコンピューティングなのよね。
未成熟な業界に対して過渡期的に働くだけで、
「理想的な」UIとしては、カスタマイズの必要が無いくらい完璧であるべきなんだろうな。
> んでそう言うところの多様性をOS自体の仕組みとして提供する事は出来るのかな
どうだろうねえ。
漏れはどちらかというと、あるソフトでやったカスタマイズが、
他のソフトや他のPCに対して簡単に反映出来る仕組みを、
OS側で提供できたらいいなーと思う。
もちろん、APIを整備してカスタマイズ可能な状態を作ることも大事だけど、
それは素性の良いソフトがあれば出来る事だし、OSには関係ないからなー。
でも、漏れの発想って、つまるところエンドユーザコンピューティングなのよね。
未成熟な業界に対して過渡期的に働くだけで、
「理想的な」UIとしては、カスタマイズの必要が無いくらい完璧であるべきなんだろうな。
>>78
おかえりー。
>UIのカスタマイズというとせこいレベルだとファイラやランチャなんかも範囲に入るよね
痒いところに手が届く的な定番ユーティリティは、どのOSでも
あるとは思うんだけど、それを全部標準化して組み込めるような
枠組みって言うと結構ムズカシイものがあるかもしれない。
（Linuxとかのフリーの奴だと、あんまり標準って線引きがないけどね）
最近のMacOS XではKonfabulator辺りが注目株ではあるね。
梨だったらWigetくらい、ちょいちょいと作れそうｗ
自由に設定できてしまうと、メーカーのサポート要員が泣きそうな
気もするし、そこら辺から考えないといかんと思う。
おかえりー。
>UIのカスタマイズというとせこいレベルだとファイラやランチャなんかも範囲に入るよね
痒いところに手が届く的な定番ユーティリティは、どのOSでも
あるとは思うんだけど、それを全部標準化して組み込めるような
枠組みって言うと結構ムズカシイものがあるかもしれない。
（Linuxとかのフリーの奴だと、あんまり標準って線引きがないけどね）
最近のMacOS XではKonfabulator辺りが注目株ではあるね。
梨だったらWigetくらい、ちょいちょいと作れそうｗ
自由に設定できてしまうと、メーカーのサポート要員が泣きそうな
気もするし、そこら辺から考えないといかんと思う。
>漏れはどちらかというと、あるソフトでやったカスタマイズが、
>他のソフトや他のPCに対して簡単に反映出来る仕組みを、
>OS側で提供できたらいいなーと思う。
あー、それ欲しい。
そういうのってMacよかWinのが得意そうね。
パソコン使ったことない人向けの理想的なUIってのは完成可能かもしれない。
でも、ある程度使いなれた人ってのは慣れとかこれまでの習慣なんかがあるんで、
御仕着せのUIはイヤなんだろうなぁ。
銀行振込みさえ、Ctrl+h のキーバインドで削除したくなる、折れは。
>他のソフトや他のPCに対して簡単に反映出来る仕組みを、
>OS側で提供できたらいいなーと思う。
あー、それ欲しい。
そういうのってMacよかWinのが得意そうね。
パソコン使ったことない人向けの理想的なUIってのは完成可能かもしれない。
でも、ある程度使いなれた人ってのは慣れとかこれまでの習慣なんかがあるんで、
御仕着せのUIはイヤなんだろうなぁ。
銀行振込みさえ、Ctrl+h のキーバインドで削除したくなる、折れは。
konfabulatorってシェアウェアなんだよねぇ。
値段が高いか安いかは人それぞれだけど
おいらは登録すること自体が面倒くせーな人間だから・・・
開発者の皆さんごめんちゃい。
2003.04号のマーパにカラーで紹介されてるね。
Quartz対応でとっても綺麗。
この手のデスクトップアクセサリーって結局邪魔になって
消しちゃうことが多いけどカレンダーは便利そう。
値段が高いか安いかは人それぞれだけど
おいらは登録すること自体が面倒くせーな人間だから・・・
開発者の皆さんごめんちゃい。
2003.04号のマーパにカラーで紹介されてるね。
Quartz対応でとっても綺麗。
この手のデスクトップアクセサリーって結局邪魔になって
消しちゃうことが多いけどカレンダーは便利そう。
>「理想的な」UIとしては、カスタマイズの必要が無いくらい完璧であるべきなんだろうな。
Appleが狙っているのは、ソコって気はするけれど、それって
結局は大勢のニーズに対しての折衷案って感じになりがちでは
あるよね。「究極のＵＩ」っちゅーのを天才が発明すれば話は別だけど。
ＭＳは「設定でお好みに使って」みたいな感じで放任主義では
あるけれど、自由度を増せば設定が複雑になってとっつきにくい。
それにあそこの会社は設定パネルを1箇所に上手に纏めるのが
今ひとつ上手くない。
ネットを仲介してUIを共有できるようにするのは面白いと思う。
リモートデスクトップの延長線上でできそうな感じはするし。
サポート要員の人も泣かなくて済むかもしれないｗ
konfabulatorは今のところアクセサリっぽいイメージなんだけど
リアルタイムでオンエア中のＴＶ番組表や道路渋滞を表示する
Widgetとかあるので、本来ＭＳがActiveDesktopでやろうとして
いた事に近いのかもしれないと思ってる。
Appleが狙っているのは、ソコって気はするけれど、それって
結局は大勢のニーズに対しての折衷案って感じになりがちでは
あるよね。「究極のＵＩ」っちゅーのを天才が発明すれば話は別だけど。
ＭＳは「設定でお好みに使って」みたいな感じで放任主義では
あるけれど、自由度を増せば設定が複雑になってとっつきにくい。
それにあそこの会社は設定パネルを1箇所に上手に纏めるのが
今ひとつ上手くない。
ネットを仲介してUIを共有できるようにするのは面白いと思う。
リモートデスクトップの延長線上でできそうな感じはするし。
サポート要員の人も泣かなくて済むかもしれないｗ
konfabulatorは今のところアクセサリっぽいイメージなんだけど
リアルタイムでオンエア中のＴＶ番組表や道路渋滞を表示する
Widgetとかあるので、本来ＭＳがActiveDesktopでやろうとして
いた事に近いのかもしれないと思ってる。
>漏れはどちらかというと、あるソフトでやったカスタマイズが、
> 他のソフトや他のPCに対して簡単に反映出来る仕組みを、
> OS側で提供できたらいいなーと思う。
これって出来ない事では無いだろうけど
でも根本的に異なる操作大系を実現するのは難しいよね
結局有る程度インターファイスのガイドラインみたいな物を作って
その中で若干の幅を持たせるくらいが関の山だと思う
> 他のソフトや他のPCに対して簡単に反映出来る仕組みを、
> OS側で提供できたらいいなーと思う。
これって出来ない事では無いだろうけど
でも根本的に異なる操作大系を実現するのは難しいよね
結局有る程度インターファイスのガイドラインみたいな物を作って
その中で若干の幅を持たせるくらいが関の山だと思う
>>84
ＸＰのエクスプローラとか、表示の仕方はＸＭＬっぽい記述で
設定されていると思ったんだけど。
その延長でウィンドウのデザイン自体やコントロールパネルの
レイアウトとかも記述できるような仕組みになれば大分、近くは
なるんじゃないかと。
MacOS XのQuartzも確かPDFかなんかで記述する筈なので
おおよそ全部のパーツは、どっかにテンプレート化してあると
思うんだよね。(システムの権限で無理っぽいけど）そこらが
弄れるツールがあれば、できそうな気もする。
ＸＰのエクスプローラとか、表示の仕方はＸＭＬっぽい記述で
設定されていると思ったんだけど。
その延長でウィンドウのデザイン自体やコントロールパネルの
レイアウトとかも記述できるような仕組みになれば大分、近くは
なるんじゃないかと。
MacOS XのQuartzも確かPDFかなんかで記述する筈なので
おおよそ全部のパーツは、どっかにテンプレート化してあると
思うんだよね。(システムの権限で無理っぽいけど）そこらが
弄れるツールがあれば、できそうな気もする。
86 ：●~*：03/04/16 02:25
技術的なことは疎いのですが
例えばですね使いやすいかどうかは別にしてマウスのジェスチャーですべての操作をしたい人がいたとして
そう言う操作を可能にすることはアドオンのソフトでも可能だと思います
でもそう言う操作で使うのに最適な見た目であるとかそういった事を実現するのはちょっと難しいでしょ？
ボタンが不要だからといって画面から消して表示領域を増やすことができますか？
結局ユーザカスタマビリティの保証は中途半端なレベルで我慢するしかないのではないかな
例えばですね使いやすいかどうかは別にしてマウスのジェスチャーですべての操作をしたい人がいたとして
そう言う操作を可能にすることはアドオンのソフトでも可能だと思います
でもそう言う操作で使うのに最適な見た目であるとかそういった事を実現するのはちょっと難しいでしょ？
ボタンが不要だからといって画面から消して表示領域を増やすことができますか？
結局ユーザカスタマビリティの保証は中途半端なレベルで我慢するしかないのではないかな
87 ：VAIOユーザZ：03/04/16 03:12
いい加減にして頂けますか！
僕は遊びも仕事も真剣勝負なITエリートです。
僕は遊びも仕事も真剣勝負なITエリートです。
（＾＾）
89 ：75：03/04/17 12:37
UIって外観だけでなくて、ショートカットとかもありだよね。
emacs とか使っていると、全部emacs風味な操作をしたくなる。
そういうのって、MacやWinのアプリでもあると思うのよ。
ショートカットだけでも統一出来れば嬉しいなぁ。
emacs とか使っていると、全部emacs風味な操作をしたくなる。
そういうのって、MacやWinのアプリでもあると思うのよ。
ショートカットだけでも統一出来れば嬉しいなぁ。
91 ：●~*：03/04/17 20:17
おれはあるインターフェースがそれ単体としてつかいやすいかどうかよりも
システム標準として採用した時にどれだけ多くの種類の作業に普遍的に適用出来るかッて事に興味が有るな
そのいみでアップルのヒューマンインターフェースガイドラインは当時としてはかなり良い出来だったと思う
あとアレを敢えて逸脱するソフト（例ハイパーカード）にはそれなりのインターフェースに対する提案があったんだよね
そう言う点でも優れた標準が有ると言う事には意味が有ると思う
システム標準として採用した時にどれだけ多くの種類の作業に普遍的に適用出来るかッて事に興味が有るな
そのいみでアップルのヒューマンインターフェースガイドラインは当時としてはかなり良い出来だったと思う
あとアレを敢えて逸脱するソフト（例ハイパーカード）にはそれなりのインターフェースに対する提案があったんだよね
そう言う点でも優れた標準が有ると言う事には意味が有ると思う
∧＿∧
（ ＾＾ ）＜ ぬるぽ（＾＾）
（ ＾＾ ）＜ ぬるぽ（＾＾）
94 ：●~*：03/04/20 23:03
上げとくぜ
ひとそれぞれなんて言うやつは自分でＯＳ作れよ
96 ：●~*：03/04/24 23:34
おい。梨マックだぜ。
http://www.ut-info.com/macin/immac/
http://www.ut-info.com/macin/immac/
>92
q,w,s,z,x,c,v,p,a,o,n,f,g,.
ぐらいなら、強制しようと思えば出来ると思う。
で、それらを強制したとして、ほかのコンビネーションはどうするか、ってことになると思うよ。
普通のアプリケーションは上のキー+r,u,i,h
あたりをはずして独自の機能をどのコンビネーションに割り当てるかを勝手に決めてる。
それがほかアプリではまったく違う機能であることは当然のように起こる。
で、そのまったく違う無数にあるであろう機能をひとつの枠に収めるのは至難の業だと思うよ。
q,w,s,z,x,c,v,p,a,o,n,f,g,.
ぐらいなら、強制しようと思えば出来ると思う。
で、それらを強制したとして、ほかのコンビネーションはどうするか、ってことになると思うよ。
普通のアプリケーションは上のキー+r,u,i,h
あたりをはずして独自の機能をどのコンビネーションに割り当てるかを勝手に決めてる。
それがほかアプリではまったく違う機能であることは当然のように起こる。
で、そのまったく違う無数にあるであろう機能をひとつの枠に収めるのは至難の業だと思うよ。
>>97
全ては無理かもしれないが、共通化できるものだけでも
やってもらえるとありがたいでつ。
キーコンビネーションではShift+Command+Sなんかは
共通化されててもいいと思いますのよ。
それとショートカットキーを語るならキーボードのキー配置にも言及したいです。
Ctrlキーが左下の隅っこにあって、更に小さかったりするとキーコンビが押しづらく
ショートカットキーの恩恵をあまり受けられないので、ハードメーカーも協力して
使い勝手を向上してもらいたいなぁ。
UIについてはモニター上だけでなく入力装置も含めて総合的に語りたいものです・・・
話がまとまらなくなるかもｗ
全ては無理かもしれないが、共通化できるものだけでも
やってもらえるとありがたいでつ。
キーコンビネーションではShift+Command+Sなんかは
共通化されててもいいと思いますのよ。
それとショートカットキーを語るならキーボードのキー配置にも言及したいです。
Ctrlキーが左下の隅っこにあって、更に小さかったりするとキーコンビが押しづらく
ショートカットキーの恩恵をあまり受けられないので、ハードメーカーも協力して
使い勝手を向上してもらいたいなぁ。
UIについてはモニター上だけでなく入力装置も含めて総合的に語りたいものです・・・
話がまとまらなくなるかもｗ
>98
>97では言いたいことが文章になってませんでした、すみません。
言いたかったことは、
たとえば、あるアプリケーションの独自機能（い）に Cmd+D が、
別のアプリケーションの独自機能（ろ）にも Cmd+D が割り当てられているときに、
1,新規作成を Cmd+D に変えた場合、（い）（ろ）は同時に Cmd+N に振り返られるのか？
2,（い）を Cmd+K に変えた場合、同時に（ろ）も Cmd+K に変わるのか？
3,（い）を Cmd+K （ろ）を Cmd+L に変えることは可能なのか？
ということです。
意味的な変更を考えるなら、3,が可能である方が好ましいと思われるが、
そうした場合、「アプリケーション単位での切り替え」機能を備えざるを得なくなります。
この機能を備えてしまうと、UIの破綻を招く恐れがありますし、
変更方法の複雑化につながります。
多ボタンマウスのドライバにも同様の機能がよくありますが、
アプリケーション単位での切り替えはわかり辛いと思います。
#使ってりゃ慣れるだろといわれればそれまでですが。
ようは、ショートカット<->機能が一対多である以上、
一部を統一化してもその他の部分にしわ寄せがきてしまうということです。
んで、>97最終行につづく。
>97では言いたいことが文章になってませんでした、すみません。
言いたかったことは、
たとえば、あるアプリケーションの独自機能（い）に Cmd+D が、
別のアプリケーションの独自機能（ろ）にも Cmd+D が割り当てられているときに、
1,新規作成を Cmd+D に変えた場合、（い）（ろ）は同時に Cmd+N に振り返られるのか？
2,（い）を Cmd+K に変えた場合、同時に（ろ）も Cmd+K に変わるのか？
3,（い）を Cmd+K （ろ）を Cmd+L に変えることは可能なのか？
ということです。
意味的な変更を考えるなら、3,が可能である方が好ましいと思われるが、
そうした場合、「アプリケーション単位での切り替え」機能を備えざるを得なくなります。
この機能を備えてしまうと、UIの破綻を招く恐れがありますし、
変更方法の複雑化につながります。
多ボタンマウスのドライバにも同様の機能がよくありますが、
アプリケーション単位での切り替えはわかり辛いと思います。
#使ってりゃ慣れるだろといわれればそれまでですが。
ようは、ショートカット<->機能が一対多である以上、
一部を統一化してもその他の部分にしわ寄せがきてしまうということです。
んで、>97最終行につづく。
100 ：VAIOユーザN505=74：03/05/01 01:50
>>97,98,99
なるほど良く分かりました
95での書き込みはあんまり良く考え手なかったってことです
ただし例えば自由に割り当てられる領域を制限すれば部分的な解決にはなるでしょう
例えばキーボードの左右で左を共通機能右を独自機能にするなど
使って無いキーでもいくつかリザーブしておくとか
あと2の方向性での解決としてショートカットを使う時はキーマップを仮想的に変化させると言う物が考えられるかと
またもう一つの考え方としてはアプリ独自のショートカットとシステム共通の物とで機能キーをわけると言うのも手です
例えばコマンドキーはシステム共通で使いオプションキーはアプリの独自機能に使うなど
これならばショートカット変更の衝突がさけられるので良いのでは無いでしょうか
アプリ独自部分にかんしてはアプリそれぞれによって変化させるつまり３の方向での解決もできるのでは？
またこの方法ならばあるアプリが独自に搭載してきたショートカットを後からシステム標準として採用する際にも
混乱を最小限に押さえる効果があると思われます
考えながらうったので後の方の案程より良い案だと考えています
なるほど良く分かりました
95での書き込みはあんまり良く考え手なかったってことです
ただし例えば自由に割り当てられる領域を制限すれば部分的な解決にはなるでしょう
例えばキーボードの左右で左を共通機能右を独自機能にするなど
使って無いキーでもいくつかリザーブしておくとか
あと2の方向性での解決としてショートカットを使う時はキーマップを仮想的に変化させると言う物が考えられるかと
またもう一つの考え方としてはアプリ独自のショートカットとシステム共通の物とで機能キーをわけると言うのも手です
例えばコマンドキーはシステム共通で使いオプションキーはアプリの独自機能に使うなど
これならばショートカット変更の衝突がさけられるので良いのでは無いでしょうか
アプリ独自部分にかんしてはアプリそれぞれによって変化させるつまり３の方向での解決もできるのでは？
またこの方法ならばあるアプリが独自に搭載してきたショートカットを後からシステム標準として採用する際にも
混乱を最小限に押さえる効果があると思われます
考えながらうったので後の方の案程より良い案だと考えています
101 ：VAIOユーザN505：03/05/01 02:42
をー
きり番ゲットしてたー
何かきり番とる時ってこんなんばっかしっすよ
たまにはマトモに10０ゲットとかしてみたい
きり番ゲットしてたー
何かきり番とる時ってこんなんばっかしっすよ
たまにはマトモに10０ゲットとかしてみたい
>>100
アプリのＵＩは、AdobeがMacromediaをパクリで告訴したり
Macromediaが逆提訴したりしているので、メニューの配置や
ショートカットを、あえて違うようにデザインしている節もあるな。
全てのアプリで共有できる機能（アプリ終了とか）のキーバインドや
メニューの位置は統一されていた方が便利だと思う。
問題は、グラフィック系固有の機能の標準的なショートカットが
ワープロ系では違う機能のショートカットで普及してたりすると
ちょっと、厄介かも。
アプリのＵＩは、AdobeがMacromediaをパクリで告訴したり
Macromediaが逆提訴したりしているので、メニューの配置や
ショートカットを、あえて違うようにデザインしている節もあるな。
全てのアプリで共有できる機能（アプリ終了とか）のキーバインドや
メニューの位置は統一されていた方が便利だと思う。
問題は、グラフィック系固有の機能の標準的なショートカットが
ワープロ系では違う機能のショートカットで普及してたりすると
ちょっと、厄介かも。
>>100
それじゃあまるでWindowsの域を脱していないｗ
Ctrlがアプリ用、Altがウィンドウシステム用と、なんとなく分かれている。
「すべて強制する」という方向に持っていくのが事実上無理なら、
「すべて自由化可能である」という遊びを持たせた方がいいのでは。
「不便だけど一般的だから仕方ない」と言ううちは、
まだまだトレードオフが発生していて「理想的」とは言えない気がするな。
ショートカットキーがうまく統一出来ないのは、
所詮それがパソコンであり、キーボード操作であるが故だと思うよ。
それじゃあまるでWindowsの域を脱していないｗ
Ctrlがアプリ用、Altがウィンドウシステム用と、なんとなく分かれている。
「すべて強制する」という方向に持っていくのが事実上無理なら、
「すべて自由化可能である」という遊びを持たせた方がいいのでは。
「不便だけど一般的だから仕方ない」と言ううちは、
まだまだトレードオフが発生していて「理想的」とは言えない気がするな。
ショートカットキーがうまく統一出来ないのは、
所詮それがパソコンであり、キーボード操作であるが故だと思うよ。
それよりも、誰か「ファイルを保存」ダイアログを撤廃させないかな。
あれは無駄の極みだと思うんだけどなー。
ダウンロードのデフォルトをデスクトップに固定したMacIEは偉いと思う。
ファイルシステムとの親和性をあげるために、
すべてのファイルの一時保存先をデスクトップにしてはどうだろうか。
そうするとあのダイアログは出さなくて済むし、
ファイルシステムの操作によって片づけがおこなえると思うんだけど。
まあ「デスクトップが散らかっても気にしない（ﾟεﾟ）」人が
少なくない現状を考えると、それを綺麗にする方法も必要かも知れないね。
さもなくば、アプリごとに固定のフォルダに保存する設定が出来るといいけど、
それでも「デスクトップからどう行けばそこにたどり着くか」を、
ユーザに理解させる事が難しいって点で、あまり良くはないと思うなあ。
あれは無駄の極みだと思うんだけどなー。
ダウンロードのデフォルトをデスクトップに固定したMacIEは偉いと思う。
ファイルシステムとの親和性をあげるために、
すべてのファイルの一時保存先をデスクトップにしてはどうだろうか。
そうするとあのダイアログは出さなくて済むし、
ファイルシステムの操作によって片づけがおこなえると思うんだけど。
まあ「デスクトップが散らかっても気にしない（ﾟεﾟ）」人が
少なくない現状を考えると、それを綺麗にする方法も必要かも知れないね。
さもなくば、アプリごとに固定のフォルダに保存する設定が出来るといいけど、
それでも「デスクトップからどう行けばそこにたどり着くか」を、
ユーザに理解させる事が難しいって点で、あまり良くはないと思うなあ。
>>104
対象はデスクトップでもマイドキュメントでも構わないんだけど
OS側で、一定のルールに従って自動的にデータを振り分ける
ようになっていると便利かな、とは思った。
メールソフトの「ルール」設定みたいな感じ。
対象はデスクトップでもマイドキュメントでも構わないんだけど
OS側で、一定のルールに従って自動的にデータを振り分ける
ようになっていると便利かな、とは思った。
メールソフトの「ルール」設定みたいな感じ。
>>106
メールだと、差出人、受取人、件名、本分中のキーワード等で
コピー、移動や削除のルール設定がユーザー側で、できるように
なってるけどその辺を、ファイルの保存に適したモノで
考えてみれば良いんだよね。
>ソフトごとに分けるのが正しい分け方だという前提があるなら、
拡張子で選別するか、アプリごとに選別するかは、ルールの
設定次第にもできると思う。
システムで認識しているアプリ、拡張子、ファイルネームの一部、日時
（Macならクリエータやファイルタイプもあるね）とかで、ルールを決めて
おいてアプリ側で「保存」ってやった場合は、自動的にルールで処理。
アプリをインスコする時にデベロッパーの作ったルールを自動的に
読み込むか、任意で選択できるようになっている。
……と、いう感じ？
メールだと、差出人、受取人、件名、本分中のキーワード等で
コピー、移動や削除のルール設定がユーザー側で、できるように
なってるけどその辺を、ファイルの保存に適したモノで
考えてみれば良いんだよね。
>ソフトごとに分けるのが正しい分け方だという前提があるなら、
拡張子で選別するか、アプリごとに選別するかは、ルールの
設定次第にもできると思う。
システムで認識しているアプリ、拡張子、ファイルネームの一部、日時
（Macならクリエータやファイルタイプもあるね）とかで、ルールを決めて
おいてアプリ側で「保存」ってやった場合は、自動的にルールで処理。
アプリをインスコする時にデベロッパーの作ったルールを自動的に
読み込むか、任意で選択できるようになっている。
……と、いう感じ？
／::::::::::::::::::::::::::::::::::::::::::::::::::＼
／::::::::::::::::::::::::＾::::::::::::＼
/::::::::::/|::::::::/ﾉ::::::::／ヽ:人::::::::::ヽ
/::::::::::/ |:::／/∧::::ﾉ ｿ ヾ::::::::::::丶
|:::::::::::/ |/ |ﾉ |/ ﾉ |:::/ヾ::::::::|
|::::::::::/ ::::::::::::: ::::::::::V:: |:::::::|
|:::::::/￣￣￣￣ヽ===/￣￣￣￣ヽ |::::|
| =ﾛ -=・=- |, | -=・=- ﾛ= |
|:/丶 /ﾉ ヽ / ヽ|ヽ
/|/ ｀─── / ｀ ─── | |
（|| （●＿●） |ﾉ ／￣￣￣￣￣￣￣￣￣
| l l ｜ ＜ (!ﾟ∞ﾟ!)それが出来たら苦労はしない
｜ __--￣｀´￣--__ ｜ ＼＿＿＿＿＿＿＿＿
| -二二二二- |
＼ ／
ヽ _-￣￣￣-_ ／
丶 ／
／| ＼＿＿＿＿＿＿＿／ |￣＼
／￣＼ 丶 ／
／::::::::::::::::::::::::＾::::::::::::＼
/::::::::::/|::::::::/ﾉ::::::::／ヽ:人::::::::::ヽ
/::::::::::/ |:::／/∧::::ﾉ ｿ ヾ::::::::::::丶
|:::::::::::/ |/ |ﾉ |/ ﾉ |:::/ヾ::::::::|
|::::::::::/ ::::::::::::: ::::::::::V:: |:::::::|
|:::::::/￣￣￣￣ヽ===/￣￣￣￣ヽ |::::|
| =ﾛ -=・=- |, | -=・=- ﾛ= |
|:/丶 /ﾉ ヽ / ヽ|ヽ
/|/ ｀─── / ｀ ─── | |
（|| （●＿●） |ﾉ ／￣￣￣￣￣￣￣￣￣
| l l ｜ ＜ (!ﾟ∞ﾟ!)それが出来たら苦労はしない
｜ __--￣｀´￣--__ ｜ ＼＿＿＿＿＿＿＿＿
| -二二二二- |
＼ ／
ヽ _-￣￣￣-_ ／
丶 ／
／| ＼＿＿＿＿＿＿＿／ |￣＼
／￣＼ 丶 ／
109 ：梨：03/05/01 19:14
>>107
その程度なら可能だろうね。使い道は微妙だけど。
今MSが作ろうとしてるデータベースベースの
ファイルシステムみたいな感じになるのだろうか。
今どういう設定になってるかをアプリごとに一覧したり設定したり。
微妙に手間かなーとも思えなくもない。
最初から「ドキュメントフォルダにアプリ名でフォルダを作る」
みたいな統一ルールを用意した方が話が早いのかなー。
まったくもってそれらを無視するか、すべて受け入れるかの二択。
これなら設定もチェックボックス１つで済みそうな。
キーバインドもそうだけど、設定を柔軟にするってことは、
設定の持ち運びが生じるだけ手間なんだよねぇ。
なんかデフォルト主義みたくなってきた。
その程度なら可能だろうね。使い道は微妙だけど。
今MSが作ろうとしてるデータベースベースの
ファイルシステムみたいな感じになるのだろうか。
今どういう設定になってるかをアプリごとに一覧したり設定したり。
微妙に手間かなーとも思えなくもない。
最初から「ドキュメントフォルダにアプリ名でフォルダを作る」
みたいな統一ルールを用意した方が話が早いのかなー。
まったくもってそれらを無視するか、すべて受け入れるかの二択。
これなら設定もチェックボックス１つで済みそうな。
キーバインドもそうだけど、設定を柔軟にするってことは、
設定の持ち運びが生じるだけ手間なんだよねぇ。
なんかデフォルト主義みたくなってきた。
110 ：bloom：03/05/01 19:17
名前：●~* ：03/05/01 18:17
／ ■＼ ／￣￣￣
／|＼（ ｀∀´） <やっぱモロでしゅ
⌒⌒ （ ） ＼＿＿＿
←-┤ ｜ |
（_＿）＿）
／ ■＼ ／￣￣￣
／|＼（ ｀∀´） <やっぱモロでしゅ
⌒⌒ （ ） ＼＿＿＿
←-┤ ｜ |
（_＿）＿）
／::::::::::::::::::::::::::::::::::::::::::::::::::＼
／::::::::::::::::::::::::＾::::::::::::＼
/::::::::::/|::::::::/ﾉ::::::::／ヽ:人::::::::::ヽ
/::::::::::/ |:::／/∧::::ﾉ ｿ ヾ::::::::::::丶
|:::::::::::/ |/ |ﾉ |/ ﾉ |:::/ヾ::::::::|
|::::::::::/ ::::::::::::: ::::::::::V:: |:::::::|
|:::::::/￣￣￣￣ヽ===/￣￣￣￣ヽ |::::|
| =ﾛ -=・=- |, | -=・=- ﾛ= |
|:/丶 /ﾉ ヽ / ヽ|ヽ
/|/ ｀─── / ｀ ─── | |
（|| （●＿●） |ﾉ ／￣￣￣￣￣￣￣￣￣
| l l ｜ ＜ (!ﾟ∞ﾟ!) 空気読め
｜ __--￣｀´￣--__ ｜ ＼＿＿＿＿＿＿＿＿
| -二二二二- |
＼ ／
ヽ _-￣￣￣-_ ／
丶 ／
／| ＼＿＿＿＿＿＿＿／ |￣＼
／￣＼ 丶 ／
／::::::::::::::::::::::::＾::::::::::::＼
/::::::::::/|::::::::/ﾉ::::::::／ヽ:人::::::::::ヽ
/::::::::::/ |:::／/∧::::ﾉ ｿ ヾ::::::::::::丶
|:::::::::::/ |/ |ﾉ |/ ﾉ |:::/ヾ::::::::|
|::::::::::/ ::::::::::::: ::::::::::V:: |:::::::|
|:::::::/￣￣￣￣ヽ===/￣￣￣￣ヽ |::::|
| =ﾛ -=・=- |, | -=・=- ﾛ= |
|:/丶 /ﾉ ヽ / ヽ|ヽ
/|/ ｀─── / ｀ ─── | |
（|| （●＿●） |ﾉ ／￣￣￣￣￣￣￣￣￣
| l l ｜ ＜ (!ﾟ∞ﾟ!) 空気読め
｜ __--￣｀´￣--__ ｜ ＼＿＿＿＿＿＿＿＿
| -二二二二- |
＼ ／
ヽ _-￣￣￣-_ ／
丶 ／
／| ＼＿＿＿＿＿＿＿／ |￣＼
／￣＼ 丶 ／
>>109
初期のBeOSも、なんかそんなファイルシステムを
うたい文句にしていた記憶があったり。
実際メールソフトで、ルール設定を使ってない人も
いるだろうから、利便性という点では微妙。
Webブラウザとかで、頻繁にバージョンアップするフリーソフトを
ダウンする時とか、自動振り分けがあると便利そう。
ファイルネームの頭何文字かで自動的に保存先を判別して
フォルダに格納されるようにしとくとか。
>キーバインドもそうだけど、設定を柔軟にするってことは、
>設定の持ち運びが生じるだけ手間なんだよねぇ。
上の方で、話題になっているけれど、ランデブーのような技術で
環境設定ファイルがネット上で参照できるようになっていると
いいかも。
初期のBeOSも、なんかそんなファイルシステムを
うたい文句にしていた記憶があったり。
実際メールソフトで、ルール設定を使ってない人も
いるだろうから、利便性という点では微妙。
Webブラウザとかで、頻繁にバージョンアップするフリーソフトを
ダウンする時とか、自動振り分けがあると便利そう。
ファイルネームの頭何文字かで自動的に保存先を判別して
フォルダに格納されるようにしとくとか。
>キーバインドもそうだけど、設定を柔軟にするってことは、
>設定の持ち運びが生じるだけ手間なんだよねぇ。
上の方で、話題になっているけれど、ランデブーのような技術で
環境設定ファイルがネット上で参照できるようになっていると
いいかも。
114 ：梨：03/05/01 20:18
>>113
ネットワーク上のコンピュータが前提になってくると、
仕事の幅も広がっていい感じやねｗ
盗難が怖いけど。
で、そうそう、自動バージョンアップは今後標準化したらいいのにね。
ソフトウェア・アップデートにサードパーティ製のソフトを
登録するわけにはいかないんだろうか？
できたらすごい便利だと思うんだけど。
ネットワーク上のコンピュータが前提になってくると、
仕事の幅も広がっていい感じやねｗ
盗難が怖いけど。
で、そうそう、自動バージョンアップは今後標準化したらいいのにね。
ソフトウェア・アップデートにサードパーティ製のソフトを
登録するわけにはいかないんだろうか？
できたらすごい便利だと思うんだけど。
115 ：●~*：03/05/01 20:32
なんでおれの乳毛が臭いって解ったんですか？
あぼーん
>>114
セキュリティに関しては専門家になんとかしてもらうとして(w
ファイル保存のルール設定と登録アプリのキーバインドを自由に
出来る機能が（ランデブー対応で）OS側でサポートされると
俺は便利そうだな、と思う。ランデブー自体の存在意義も明確になるし。
ソフトウェア・アップデートもWinだったら「プログラムの追加と削除」に
「アップデート」も組み込めばいいと思うよ。
Macの「ソフトウェア･アップデート｣は仕様公開してるのかな？
非公開なのか、公開してるけど例のごとくデベロッパーに支持されて
いないとか。「インストーラ」と統合化すると便利かもね。
セキュリティに関しては専門家になんとかしてもらうとして(w
ファイル保存のルール設定と登録アプリのキーバインドを自由に
出来る機能が（ランデブー対応で）OS側でサポートされると
俺は便利そうだな、と思う。ランデブー自体の存在意義も明確になるし。
ソフトウェア・アップデートもWinだったら「プログラムの追加と削除」に
「アップデート」も組み込めばいいと思うよ。
Macの「ソフトウェア･アップデート｣は仕様公開してるのかな？
非公開なのか、公開してるけど例のごとくデベロッパーに支持されて
いないとか。「インストーラ」と統合化すると便利かもね。
118 ：梨：03/05/01 21:05
>>117
自動更新されないとつまんないので、
Windowsなら「自動更新」（露骨なネーミングだなあ）に対応かな。
ソフトウェア・アップデートも、Apple製品と糞味噌にするんでなくて、
区別した上でデベロッパーに開放すれば、
開発する側としても嬉しいんだけどな。
みんなに最新版を使って貰いやすくなるわけだし。
とか思いながら、今日はソフトウェア・アップデートみたいなものを
書いてたなりよ。汎用的にして広く普及すればおいしいと思うけどなあ。
自動更新されないとつまんないので、
Windowsなら「自動更新」（露骨なネーミングだなあ）に対応かな。
ソフトウェア・アップデートも、Apple製品と糞味噌にするんでなくて、
区別した上でデベロッパーに開放すれば、
開発する側としても嬉しいんだけどな。
みんなに最新版を使って貰いやすくなるわけだし。
とか思いながら、今日はソフトウェア・アップデートみたいなものを
書いてたなりよ。汎用的にして広く普及すればおいしいと思うけどなあ。
>>118
確かにバージョンチェックや更新情報を集めたサイトとか
重宝がられているし、自動更新チェックはあった方が
良いだろうね。
ま、更新アラートが頻繁に出るとウザイかもしれんけど(w
ttp://www.apple.co.jp/server/macosx/pdfs/NetInstall_TB_J.pdf
こーゆーのも、あるみたいなんだけど普及はしてなさそ。
AppleもAkamaiかなんかで、これを稼動させて.mac会員か
有料ADC会員に開放するとかしてみれば良いのにね。
MacOS X Serverの運用実績にもなるんだし。
確かにバージョンチェックや更新情報を集めたサイトとか
重宝がられているし、自動更新チェックはあった方が
良いだろうね。
ま、更新アラートが頻繁に出るとウザイかもしれんけど(w
ttp://www.apple.co.jp/server/macosx/pdfs/NetInstall_TB_J.pdf
こーゆーのも、あるみたいなんだけど普及はしてなさそ。
AppleもAkamaiかなんかで、これを稼動させて.mac会員か
有料ADC会員に開放するとかしてみれば良いのにね。
MacOS X Serverの運用実績にもなるんだし。
ちょっち話題に乗り遅れました。
ファイルの保存と開くに関しては以前マーパに、
ファイルに細かいデータを付与することでCmd+Oの代わりに
Cmd+Fを使えないかって感じの記事があったような・・・
以下私見。単独使用に限定ですが・・・
ファイルの保存場所はDocumentフォルダに固定する。
Cmd+Oのダイアログ画面をOSXのリスト表示みたいにして
ソートや検索ができるようにする。
当然リストの項目は全てのアプリで共通化する。
という感じでどうでしょう。
マーパの記事ではデータベース化したファイルを瞬時に検索できるようになれば
ファイルをどこに保存するかは問題でなくなる、って書いてあった・・と思う。
素人考えなので真剣に突っ込まないで下さいｗ
ファイルの保存と開くに関しては以前マーパに、
ファイルに細かいデータを付与することでCmd+Oの代わりに
Cmd+Fを使えないかって感じの記事があったような・・・
以下私見。単独使用に限定ですが・・・
ファイルの保存場所はDocumentフォルダに固定する。
Cmd+Oのダイアログ画面をOSXのリスト表示みたいにして
ソートや検索ができるようにする。
当然リストの項目は全てのアプリで共通化する。
という感じでどうでしょう。
マーパの記事ではデータベース化したファイルを瞬時に検索できるようになれば
ファイルをどこに保存するかは問題でなくなる、って書いてあった・・と思う。
素人考えなので真剣に突っ込まないで下さいｗ
>>118
>とか思いながら、今日はソフトウェア・アップデートみたいなものを
>書いてたなりよ。汎用的にして広く普及すればおいしいと思うけどなあ。
車輪の再発明は信条に反するのでは？(wというのを
ツッコミ忘れた（冗談です）
そういう機能をカバーしたインストーラ開発キットみたいなのが
あればいんでしょうねえ。
>>120
そういう方向のアプローチは各社やってるみたいだよね。
どのOSでも、ファイルダイアログはとかく評判が悪いしね。
ダイアログを差し替えるフリーソフトもあるし。
存在意義の薄くなったSherlockをちょっと改造して
ダイアログに流用するとできそうな感じがする。
>とか思いながら、今日はソフトウェア・アップデートみたいなものを
>書いてたなりよ。汎用的にして広く普及すればおいしいと思うけどなあ。
車輪の再発明は信条に反するのでは？(wというのを
ツッコミ忘れた（冗談です）
そういう機能をカバーしたインストーラ開発キットみたいなのが
あればいんでしょうねえ。
>>120
そういう方向のアプローチは各社やってるみたいだよね。
どのOSでも、ファイルダイアログはとかく評判が悪いしね。
ダイアログを差し替えるフリーソフトもあるし。
存在意義の薄くなったSherlockをちょっと改造して
ダイアログに流用するとできそうな感じがする。
122 ：梨：03/05/01 22:19
なんてことだ。帯域資源が乏しいとPDFのひとつもよめしないのか。
>>119
それこそ「自動更新」みたいに「勝手にやっといておくれ」モードがあればいい。
それだけでメディアになりそうな気がするけどな。
誰か真剣に幾千のソフトのバージョンアップをサービスしたい人いたら、
相談に乗るよ。つーかベクターにでも営業いってくるか。
>>120
個人的には固定ってアプローチがいいんでないかと思うぞ。
「初心者モード」みたいなさ。Macにはうってつけだと思うけどなあ。
>>121
多対多の接続をサポートする汎用アップデータって、
漏れの見聞の範囲内では見たことが無いなあ。あったら教えておくれ。
インストーラ開発キットって、地味に儲かりそうよね。
InstallShieldくらいのポテンシャルがあって10万以下なら、
十分競争になるのでは。
Macの場合は、そのへんはAppleが頑張るしか無いだろうけどね。
>>119
それこそ「自動更新」みたいに「勝手にやっといておくれ」モードがあればいい。
それだけでメディアになりそうな気がするけどな。
誰か真剣に幾千のソフトのバージョンアップをサービスしたい人いたら、
相談に乗るよ。つーかベクターにでも営業いってくるか。
>>120
個人的には固定ってアプローチがいいんでないかと思うぞ。
「初心者モード」みたいなさ。Macにはうってつけだと思うけどなあ。
>>121
多対多の接続をサポートする汎用アップデータって、
漏れの見聞の範囲内では見たことが無いなあ。あったら教えておくれ。
インストーラ開発キットって、地味に儲かりそうよね。
InstallShieldくらいのポテンシャルがあって10万以下なら、
十分競争になるのでは。
Macの場合は、そのへんはAppleが頑張るしか無いだろうけどね。
123 ：梨：03/05/01 22:22
InstallShieldって商品名だったんだ。
初めて知った・・・
てことはInstaller Vise（だっけ？）とかいうのも。。。
初めて知った・・・
てことはInstaller Vise（だっけ？）とかいうのも。。。
>>122
>誰か真剣に幾千のソフトのバージョンアップをサービスしたい
それこそ、管理画面のUIが課題かなあ。間違っても
「プログラムの追加と削除」みたいに全部一覧で表示されても
探すのが大変そうだし、階層化表示も一長一短。
>>123
そーですねー。クライアント側の自動更新チェックはないし。
>>119は「AppleもAkamaiかなんかで～運用実績にもなるんだし。」と
言うサービスの仕方はできんもんかな？と言う話なので。
これとかCVSとかRPMとか、あともう一歩だと思うんだけねえ。
やっぱり、セキュリティがネックなのかな。なりすましとか。
>>124
その通り。
Apple謹製の「インストーラ」とViseは思い切り競合してる。
どうなるんだろう？
>誰か真剣に幾千のソフトのバージョンアップをサービスしたい
それこそ、管理画面のUIが課題かなあ。間違っても
「プログラムの追加と削除」みたいに全部一覧で表示されても
探すのが大変そうだし、階層化表示も一長一短。
>>123
そーですねー。クライアント側の自動更新チェックはないし。
>>119は「AppleもAkamaiかなんかで～運用実績にもなるんだし。」と
言うサービスの仕方はできんもんかな？と言う話なので。
これとかCVSとかRPMとか、あともう一歩だと思うんだけねえ。
やっぱり、セキュリティがネックなのかな。なりすましとか。
>>124
その通り。
Apple謹製の「インストーラ」とViseは思い切り競合してる。
どうなるんだろう？
126 ：梨：03/05/01 23:03
>>125
Appleのインターネット技術はどいつもこいつも「あと一歩」さｗ
「プログラムの追加と削除」と同水準にならざるを得ないかと。
要は、原則的にいちいち取捨選択しなくてもいいように、
セキュリテイフィックスと機能追加で分けるとか、
Windows Updateみたいな形にしてしまえばいいのかと。
Appleのインターネット技術はどいつもこいつも「あと一歩」さｗ
「プログラムの追加と削除」と同水準にならざるを得ないかと。
要は、原則的にいちいち取捨選択しなくてもいいように、
セキュリテイフィックスと機能追加で分けるとか、
Windows Updateみたいな形にしてしまえばいいのかと。
>>126
梨にいつもの調子が戻ってきて、何より(w
余力が有り過ぎる割には本質を見落としがちで「あと一歩」の
部分を何十種類も用意するMSもカワイイけど、余力がなくて
いつも転んでるAppleも結構好き。
>「プログラムの追加と削除」と同水準にならざるを得ないかと。
うん、まあ、常識的な線では、そうだろうね。
メーカー謹製のソフト＋インストールされている他社製ソフトの
更新情報だとしても、毎回凄い数のアップデートがある訳でも
ないだろうし。
半歩手前のアプローチとして、Yahoo! Alertみたいなサービスを
ベクターに営業してくるといいかもよ？(w
梨にいつもの調子が戻ってきて、何より(w
余力が有り過ぎる割には本質を見落としがちで「あと一歩」の
部分を何十種類も用意するMSもカワイイけど、余力がなくて
いつも転んでるAppleも結構好き。
>「プログラムの追加と削除」と同水準にならざるを得ないかと。
うん、まあ、常識的な線では、そうだろうね。
メーカー謹製のソフト＋インストールされている他社製ソフトの
更新情報だとしても、毎回凄い数のアップデートがある訳でも
ないだろうし。
半歩手前のアプローチとして、Yahoo! Alertみたいなサービスを
ベクターに営業してくるといいかもよ？(w
128 ：梨：03/05/01 23:30
話題があるっていいことやねｗ
>>127
人的資源の配分って難しいやね。
「もう一歩」と言えば、UNIX系の開発者をうまく取り込んで欲しいな。
ベクターって今どんなサービスやってるんだろ？
もし本当に売りに行くなら、収益モデルを考えないとなあ。
UIの話に無理矢理戻すと、ソフトウェア的な面では、
統合と分散を交互に繰り返して進化していくのがベターなのかねえ。
何万ものフィードバックを受ける時期と、
それを優れた設計者がまとめあげる時期に分かれるようなイメージ。
それを両方いっぺんに高速に出来たらいいんだけどなあ。
>>127
人的資源の配分って難しいやね。
「もう一歩」と言えば、UNIX系の開発者をうまく取り込んで欲しいな。
ベクターって今どんなサービスやってるんだろ？
もし本当に売りに行くなら、収益モデルを考えないとなあ。
UIの話に無理矢理戻すと、ソフトウェア的な面では、
統合と分散を交互に繰り返して進化していくのがベターなのかねえ。
何万ものフィードバックを受ける時期と、
それを優れた設計者がまとめあげる時期に分かれるようなイメージ。
それを両方いっぺんに高速に出来たらいいんだけどなあ。
さて、寝るか。
>>128
取り込み第1弾がXonXとかなんだろうね。OS標準で組み込まれる位の
完成度にもっていってくれると期待感は増すと思う。（これも「あと一歩」で
挫折なんてオチは勘弁して欲しい）
ベクターを覗いてみたら「MyVector」ってサービスで更新のメール通知
らしきサービスは稼動しているみたい。考えることは一緒、ってことで
やはり営業するなら自動更新マネージャか(w
UIの話。統合・分散は「どこまでやるか」って、メーカーにしても
手探り部分はあるから、交互に繰り返すのはしょうがないのかもね。
突然変異的な進化っていうのも、相応の能力と先見性が要求される
だろうし。
フィードバックしてきた意見も多種多様で、その平均的な部分（多数派）が
必ずしも最良という訳じゃないし。見極めが難しいと思う。
取り込み第1弾がXonXとかなんだろうね。OS標準で組み込まれる位の
完成度にもっていってくれると期待感は増すと思う。（これも「あと一歩」で
挫折なんてオチは勘弁して欲しい）
ベクターを覗いてみたら「MyVector」ってサービスで更新のメール通知
らしきサービスは稼動しているみたい。考えることは一緒、ってことで
やはり営業するなら自動更新マネージャか(w
UIの話。統合・分散は「どこまでやるか」って、メーカーにしても
手探り部分はあるから、交互に繰り返すのはしょうがないのかもね。
突然変異的な進化っていうのも、相応の能力と先見性が要求される
だろうし。
フィードバックしてきた意見も多種多様で、その平均的な部分（多数派）が
必ずしも最良という訳じゃないし。見極めが難しいと思う。
あぼーん
132 ：●~*：03/05/02 07:33
歌えました
133 ：●~*：03/05/02 07:34
魔境でつか
134 ：●~*：03/05/02 07:35
結局自分の思い通りに行かないと拗ねる奴ばっかなんだよ
この板は
この板は
>>130
MyVectorから自動更新に切り替えることで起きる影響は、
・トラフィックが増大する
・マルチプラットフォーム対応が難しい
・ホームページに来るユーザが減る
・開発者は最新版を使って貰えて嬉しい
・話題にはなるし多くのソフトを取り込める
ってな事なんで、実はVectorには最初から向いてない。
これから新規にVectorとはりあうようなビジネスをする場合にしか、
自動更新機能を中心にしたソフトウェア情報提供モデルは使えないのよね。
2ch.tora3.netがやりたかった事って、そういう事でないかと思うんだけど、
あれがビジネスを回避したって事は、モデルの成立が難しいのかもね。
仕事ネタになるんで自動更新の話はここで終わり。
MyVectorから自動更新に切り替えることで起きる影響は、
・トラフィックが増大する
・マルチプラットフォーム対応が難しい
・ホームページに来るユーザが減る
・開発者は最新版を使って貰えて嬉しい
・話題にはなるし多くのソフトを取り込める
ってな事なんで、実はVectorには最初から向いてない。
これから新規にVectorとはりあうようなビジネスをする場合にしか、
自動更新機能を中心にしたソフトウェア情報提供モデルは使えないのよね。
2ch.tora3.netがやりたかった事って、そういう事でないかと思うんだけど、
あれがビジネスを回避したって事は、モデルの成立が難しいのかもね。
仕事ネタになるんで自動更新の話はここで終わり。
アプリに一部持ってもらえば良いんだよ。
一度目の起動時に自分がバージョンアップ機構に対応していることをバージョンアップ機構に教える。
特定のメッセージで自分のバージョンを返す。
もしくはOS Xのように、特定のファイルにバージョンを記しておく。
Windowsなら、レジストリに記すのがいいのかな？
これだけやってくれればあとはバージョンアップ機構で勝手に出来る。
問題は検索機構だけど、一番安易な方法はSunが始めてAppleが真似した
ドメインをひっくり返す"com.apple.Application"見たいな奴を使うのがいいと思う。
検索方法はDNSと一緒。
自分がインデックスを持ってなければ、上に聞きにいく。
問題はドメインがない場合だけど、これも商売にしようと思えば出来るし。
一度目の起動時に自分がバージョンアップ機構に対応していることをバージョンアップ機構に教える。
特定のメッセージで自分のバージョンを返す。
もしくはOS Xのように、特定のファイルにバージョンを記しておく。
Windowsなら、レジストリに記すのがいいのかな？
これだけやってくれればあとはバージョンアップ機構で勝手に出来る。
問題は検索機構だけど、一番安易な方法はSunが始めてAppleが真似した
ドメインをひっくり返す"com.apple.Application"見たいな奴を使うのがいいと思う。
検索方法はDNSと一緒。
自分がインデックスを持ってなければ、上に聞きにいく。
問題はドメインがない場合だけど、これも商売にしようと思えば出来るし。
>>130
XonXは本末転倒だと思うのは漏れだけでつか。
いや、仕方ないんだけど、
本当はAquaがXアプリを完全に取り込むべきでしょ。
「少しずつでもいいから常に進化して周囲の反応を伺う」という
凡才形式の発展が許されるのは、β版OSだけよね。
「商用製品として理想的」というなら、
「原則かなりの部分が固定。でもカスタマイズ可能」ってな所なのかな。
・カスタマイズを受け入れて設定ファイルやサーバに保持する仕組み。
・カスタマイズできなくて不便な部分はカスタマイズ可能なように発展。
・新規ユーザは望まない限り全カスタマイズはデフォルト状態で提供される。
・キーバインドのデフォルトはできるだけ統一の方向に向かう。
・ファイルシステムはデフォルトで隠蔽され、保存先は固定する。
・ファイルの検索条件を増やし、ルールによる振り分けも出来る。
いまのところ、そんなもんかね。
XonXは本末転倒だと思うのは漏れだけでつか。
いや、仕方ないんだけど、
本当はAquaがXアプリを完全に取り込むべきでしょ。
「少しずつでもいいから常に進化して周囲の反応を伺う」という
凡才形式の発展が許されるのは、β版OSだけよね。
「商用製品として理想的」というなら、
「原則かなりの部分が固定。でもカスタマイズ可能」ってな所なのかな。
・カスタマイズを受け入れて設定ファイルやサーバに保持する仕組み。
・カスタマイズできなくて不便な部分はカスタマイズ可能なように発展。
・新規ユーザは望まない限り全カスタマイズはデフォルト状態で提供される。
・キーバインドのデフォルトはできるだけ統一の方向に向かう。
・ファイルシステムはデフォルトで隠蔽され、保存先は固定する。
・ファイルの検索条件を増やし、ルールによる振り分けも出来る。
いまのところ、そんなもんかね。
>>136
それでも良いんだけど、上述の話だとインストーラで記すんだと思う。
すべてのアプリが独自に機構に書き込むと、手間だし危険なので、
統一したインストーラを提供して、その機能としてアップデートを含める。
まあ、前述の通り、政治的にはWindowsでしか実現できんわな。これは。
検索についてはもっといい案があるけど、一応秘密にしておくｗ
それでも良いんだけど、上述の話だとインストーラで記すんだと思う。
すべてのアプリが独自に機構に書き込むと、手間だし危険なので、
統一したインストーラを提供して、その機能としてアップデートを含める。
まあ、前述の通り、政治的にはWindowsでしか実現できんわな。これは。
検索についてはもっといい案があるけど、一応秘密にしておくｗ
>>135
ベクターもオープンソース系のボランティアって訳じゃあ
ないし、自動更新システムの運用コストとか、そこに書いて
あるようなメリット･デメリットは当然考えるよな。
今のスタイルが最高とは誰も思ってないので、大勢の
開発者や企画者が頭をひねっているとは思うよ。
>仕事ネタになるんで自動更新の話はここで終わり。
ごちそうさまでした(w
>>136
純粋にアプリ側での対応というのは、それなりに独自の
実装でなされているものもあるよね。起動時にチェックする
やつとか。
ただ、各社好きにやっている状態だと思うので、クライアント側で
統括して一元管理を可能にするには、AppleやMSが開発ツールや
SDKとして正式に対応して十分なサポートをするか、デファクト
スタンダードなインストーラ開発ツールが、そういう機構を持つか
って感じだよね。
ベクターもオープンソース系のボランティアって訳じゃあ
ないし、自動更新システムの運用コストとか、そこに書いて
あるようなメリット･デメリットは当然考えるよな。
今のスタイルが最高とは誰も思ってないので、大勢の
開発者や企画者が頭をひねっているとは思うよ。
>仕事ネタになるんで自動更新の話はここで終わり。
ごちそうさまでした(w
>>136
純粋にアプリ側での対応というのは、それなりに独自の
実装でなされているものもあるよね。起動時にチェックする
やつとか。
ただ、各社好きにやっている状態だと思うので、クライアント側で
統括して一元管理を可能にするには、AppleやMSが開発ツールや
SDKとして正式に対応して十分なサポートをするか、デファクト
スタンダードなインストーラ開発ツールが、そういう機構を持つか
って感じだよね。
>>137
XonXがCarbon並みに全体と馴染むのなら余り問題はない
とも思うけど。Cocoa、Carbon、Java2に新しい実行環境が
増えた、という見方だけど。
>凡才形式の発展が許されるのは、β版OSだけよね。
市場が小さいから(w
>・ファイルシステムはデフォルトで隠蔽され、保存先は固定する。
>・ファイルの検索条件を増やし、ルールによる振り分けも出来る。
保存場所を、むき出しのフォルダ名とファイル名で指定する
のではなく、もっと抽象化したものをユーザーに選んでもらって
見えないところでOSが色々な属性値から判断するという方法論も
ありなのかな？
どこまでカスタマイズできるかって議論は微妙だ。
ヘビーユーザーとｷﾆｼﾅｲユーザーでは、ニーズが
異なると思う。ここら辺を、どう切り分けて共棲させるかが
ミソだな。
XonXがCarbon並みに全体と馴染むのなら余り問題はない
とも思うけど。Cocoa、Carbon、Java2に新しい実行環境が
増えた、という見方だけど。
>凡才形式の発展が許されるのは、β版OSだけよね。
市場が小さいから(w
>・ファイルシステムはデフォルトで隠蔽され、保存先は固定する。
>・ファイルの検索条件を増やし、ルールによる振り分けも出来る。
保存場所を、むき出しのフォルダ名とファイル名で指定する
のではなく、もっと抽象化したものをユーザーに選んでもらって
見えないところでOSが色々な属性値から判断するという方法論も
ありなのかな？
どこまでカスタマイズできるかって議論は微妙だ。
ヘビーユーザーとｷﾆｼﾅｲユーザーでは、ニーズが
異なると思う。ここら辺を、どう切り分けて共棲させるかが
ミソだな。
>>139
そ。「自動更新をすると誰が得するか」って問題やね。
で、Windows Installerが標準になれない政治的事情もある。
デファクトスタンダードで統制をとることが前提なら、
Appleのほうがソフトを押しつけるには有利。
というか、Project Builderみたいな物を押しつけて開発環境を独占したんだから、
インストーラも面倒みて欲しいよな。
とはいえ、MacOSXってまだ統一されたソフトウェア管理画面って無いんだっけか。
rpmだって簡単に管理操作出来る昨今、どーにかして欲しいけど。
ドラッグアンドドロップでインストールするならするでいいんで、
とにかくダブルスタンダード状態は早いとこ解決して欲しいなあ。
そ。「自動更新をすると誰が得するか」って問題やね。
で、Windows Installerが標準になれない政治的事情もある。
デファクトスタンダードで統制をとることが前提なら、
Appleのほうがソフトを押しつけるには有利。
というか、Project Builderみたいな物を押しつけて開発環境を独占したんだから、
インストーラも面倒みて欲しいよな。
とはいえ、MacOSXってまだ統一されたソフトウェア管理画面って無いんだっけか。
rpmだって簡単に管理操作出来る昨今、どーにかして欲しいけど。
ドラッグアンドドロップでインストールするならするでいいんで、
とにかくダブルスタンダード状態は早いとこ解決して欲しいなあ。
>>140
わかる人とわからない人の落差は一層激しくなると思うよ。
で、市場は必ず「最もわからない人」に向けて動いて良い。
ただし、次点で「最もわかる人」をおざなりにしてはいけない。
実行環境は、これ以上増やしてどうするんですか、という感想。
まあ、そうせざるを得ないだろうけどね。
いっそ統一する気が無いなら、増えるだけ増えた方がいいだろうし。
Appleに開発環境を「整えてやる」事は無理。これも「あと一歩」か。
わかる人とわからない人の落差は一層激しくなると思うよ。
で、市場は必ず「最もわからない人」に向けて動いて良い。
ただし、次点で「最もわかる人」をおざなりにしてはいけない。
実行環境は、これ以上増やしてどうするんですか、という感想。
まあ、そうせざるを得ないだろうけどね。
いっそ統一する気が無いなら、増えるだけ増えた方がいいだろうし。
Appleに開発環境を「整えてやる」事は無理。これも「あと一歩」か。
ゴミ箱を使った新しいインストールの仕組みは前に提案したけど、
色々な意見を聞いた上でもうちょっと書いてみる。
・原則、CD-ROMから本体をドラッグしてインストールする。
・CD-ROM内の本体をダブルクリックするとCDで起動。
・CD-ROM内のインストーラをダブルクリックすると所定の位置にコピー。
・初回起動時に必要な処理や初期設定の配置をする。
・初回起動時に自動更新に必要な情報を登録する。
・自動更新はバックグラウンド巡回が原則。
・アンインストールはごみ箱に捨てるだけ。自動更新情報も消える。
これだけでずいぶんすっきりすると思うんだけどなあ。
精細にインストールオプションを選びたい人は、
インストーラをダブルクリックすればいいわけで。
色々な意見を聞いた上でもうちょっと書いてみる。
・原則、CD-ROMから本体をドラッグしてインストールする。
・CD-ROM内の本体をダブルクリックするとCDで起動。
・CD-ROM内のインストーラをダブルクリックすると所定の位置にコピー。
・初回起動時に必要な処理や初期設定の配置をする。
・初回起動時に自動更新に必要な情報を登録する。
・自動更新はバックグラウンド巡回が原則。
・アンインストールはごみ箱に捨てるだけ。自動更新情報も消える。
これだけでずいぶんすっきりすると思うんだけどなあ。
精細にインストールオプションを選びたい人は、
インストーラをダブルクリックすればいいわけで。
>>142
>で、市場は必ず「最もわからない人」に向けて動いて良い。
>ただし、次点で「最もわかる人」をおざなりにしてはいけない。
それは結構禿しく同意。
元々、PC自体が技術者の研究対象かマニアの道楽って感じ
だったので、どうしても「最もわかる人」の方へ引っ張られる傾向が
あると思うんだよな。開発もマスコミも「最もわかる人」系だからね。
>>実行環境は、これ以上増やしてどうするんですか、という感想。
元々DarwinがUnixの亜種でXFree86とかがDarwinに
対応してたから、そんなに無理やり新しい実行環境として
捻じ込んだ訳でもなさそうに見えるけどね。
XonXでUnix系の開発者が簡単にMacOS Xに移植できるなら
それはそれで便利だと思うし、エンドユーザーに全く区別が
付かないのであれば、メリットも多いと思う。
問題は、環境整備の労力や、OS側に起因する不具合が
発生した時にバグの洗い出しがより困難なったり、そういう
面倒を受け入れるAppleのサポート体制かな。
>で、市場は必ず「最もわからない人」に向けて動いて良い。
>ただし、次点で「最もわかる人」をおざなりにしてはいけない。
それは結構禿しく同意。
元々、PC自体が技術者の研究対象かマニアの道楽って感じ
だったので、どうしても「最もわかる人」の方へ引っ張られる傾向が
あると思うんだよな。開発もマスコミも「最もわかる人」系だからね。
>>実行環境は、これ以上増やしてどうするんですか、という感想。
元々DarwinがUnixの亜種でXFree86とかがDarwinに
対応してたから、そんなに無理やり新しい実行環境として
捻じ込んだ訳でもなさそうに見えるけどね。
XonXでUnix系の開発者が簡単にMacOS Xに移植できるなら
それはそれで便利だと思うし、エンドユーザーに全く区別が
付かないのであれば、メリットも多いと思う。
問題は、環境整備の労力や、OS側に起因する不具合が
発生した時にバグの洗い出しがより困難なったり、そういう
面倒を受け入れるAppleのサポート体制かな。
>>141
MacOS XもDarwinレベルで見ると、パッケージ管理は
標準がDebian形式でFreeBSDのportsやRedHatのrpmにも
対応はしている。Appleの関知しないところで対応が増えても
一長一短だけど。
>>143
Apple推奨の「パッケージフォルダ形式」であれば、確かに
ドラッグ&ドロップだけでインストールと削除は簡単にできる。
アップデータをダブルクリックしてやれば更新もするし。
似たような感じで操作を単純化する試みはなされていると思う。
問題はデベロッパーの支持かな。Unix流に/etcや/usr/local/に
設定やシンボリックリンクをばら撒くヤツもあるし。OS 9風に
Libraryフォルダに専用フォルダを作るやつも多い。
マルチスタンダードだ(w
MacOS XもDarwinレベルで見ると、パッケージ管理は
標準がDebian形式でFreeBSDのportsやRedHatのrpmにも
対応はしている。Appleの関知しないところで対応が増えても
一長一短だけど。
>>143
Apple推奨の「パッケージフォルダ形式」であれば、確かに
ドラッグ&ドロップだけでインストールと削除は簡単にできる。
アップデータをダブルクリックしてやれば更新もするし。
似たような感じで操作を単純化する試みはなされていると思う。
問題はデベロッパーの支持かな。Unix流に/etcや/usr/local/に
設定やシンボリックリンクをばら撒くヤツもあるし。OS 9風に
Libraryフォルダに専用フォルダを作るやつも多い。
マルチスタンダードだ(w
>>144
うん。単に、収拾つかなくなりそうだから嫌だなあって。
Appleの数少ないリソース同士が競合しあうのはちょっと悲しい。
まあ、そんな事を気にせずに済むほどにマーケットがでかくなればいいんだけど。
>>145
> 標準がDebian形式でFreeBSDのportsやRedHatのrpmにも
無知で申し訳ないんだけど、GUIのパッケージマネージャはあるの？
そして、それは標準インストーラ形式をフォローするの？
ここにも「さまざまな形式をサポートする」事の弊害があるような。
Appleがさまざまなフォーマットを受け入れるのは歓迎するけど、
Macとしての統一性はほとんど損なわれつつあるんでないかね。
エンドユーザから見ても、ややこしくね？
> Apple推奨の「パッケージフォルダ形式」であれば、確かに
あれ、個人的にはかなり良い出来だと思うんだけどな。
設定がパッケージの中に埋もれるのは賛否両論かも知れないけど。
せっかく良い物も、使われなければ何の意味もない。
うん。単に、収拾つかなくなりそうだから嫌だなあって。
Appleの数少ないリソース同士が競合しあうのはちょっと悲しい。
まあ、そんな事を気にせずに済むほどにマーケットがでかくなればいいんだけど。
>>145
> 標準がDebian形式でFreeBSDのportsやRedHatのrpmにも
無知で申し訳ないんだけど、GUIのパッケージマネージャはあるの？
そして、それは標準インストーラ形式をフォローするの？
ここにも「さまざまな形式をサポートする」事の弊害があるような。
Appleがさまざまなフォーマットを受け入れるのは歓迎するけど、
Macとしての統一性はほとんど損なわれつつあるんでないかね。
エンドユーザから見ても、ややこしくね？
> Apple推奨の「パッケージフォルダ形式」であれば、確かに
あれ、個人的にはかなり良い出来だと思うんだけどな。
設定がパッケージの中に埋もれるのは賛否両論かも知れないけど。
せっかく良い物も、使われなければ何の意味もない。
>146
> 設定がパッケージの中に埋もれるのは賛否両論かも知れないけど。
設定をパッケージに埋めたらマルチユーザーが（ｒｙ
> 設定がパッケージの中に埋もれるのは賛否両論かも知れないけど。
設定をパッケージに埋めたらマルチユーザーが（ｒｙ
>>146
リソースは有効に使ってほしいのは確か。
>ここにも「さまざまな形式をサポートする」事の弊害があるような。
ソースやバイナリのパッケージが開けるという話しで
規格乱立という感じじゃないな。指摘の通り、しっかりした
GUIを備えている訳でもなさそう。
主流としては標準インストーラのpkg形式かViseだと思う。
それと1個の実行ファイルのように振舞うパッケージフォルダ式。
ふと思い付いたので、本来のUI話に戻るけど。
ファイルの保存･開くも、パッケージフォルダで指定するように
するというのは、どうかなと思ったり。
データの保存履歴や属性とかのカタログインデックスを
パッケージ内に置いておいて、ユーザーはもっと抽象的な指
定でOS側が分別してデータを出し入れするようにするとか
できないのかな？
リソースは有効に使ってほしいのは確か。
>ここにも「さまざまな形式をサポートする」事の弊害があるような。
ソースやバイナリのパッケージが開けるという話しで
規格乱立という感じじゃないな。指摘の通り、しっかりした
GUIを備えている訳でもなさそう。
主流としては標準インストーラのpkg形式かViseだと思う。
それと1個の実行ファイルのように振舞うパッケージフォルダ式。
ふと思い付いたので、本来のUI話に戻るけど。
ファイルの保存･開くも、パッケージフォルダで指定するように
するというのは、どうかなと思ったり。
データの保存履歴や属性とかのカタログインデックスを
パッケージ内に置いておいて、ユーザーはもっと抽象的な指
定でOS側が分別してデータを出し入れするようにするとか
できないのかな？
アップルから提示されている設定の保存は、NSUserDefaultsを使用する方法のみです。
あと、ほかの場所がないか探してたらこんなの見つけました。
>Your application should never write user-preference data inside the application package.
このあとに余計なことせずにNSUserDefaultsかCFPreferences使え、ボケ！って書いてます。
CFPreferenceは現在NSUserDefaultsがホスト単位での設定をサポートしていないための逃げ口です。
//以下余談
CFPreferencesを使うと
現在のホスト上の現在のユーザー
特定のホスト上のすべてのユーザー
すべてのホスト上の現在のユーザー
すべてのホスト上のすべてのユーザー
という場合わけが出来るようです。
あと、ほかの場所がないか探してたらこんなの見つけました。
>Your application should never write user-preference data inside the application package.
このあとに余計なことせずにNSUserDefaultsかCFPreferences使え、ボケ！って書いてます。
CFPreferenceは現在NSUserDefaultsがホスト単位での設定をサポートしていないための逃げ口です。
//以下余談
CFPreferencesを使うと
現在のホスト上の現在のユーザー
特定のホスト上のすべてのユーザー
すべてのホスト上の現在のユーザー
すべてのホスト上のすべてのユーザー
という場合わけが出来るようです。
あぼーん
あぼーん
あぼーん
あぼーん
155 ：●~*：03/05/02 21:36
他人が見て面白いことを書きましょう。大勢の読者がいることを意識してください。
156 ：●~*：03/05/02 22:11
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨Ⅱ梨梨梨梨梨梨梨梨梨梨梨環‥‥‥‥
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨Ⅱ梨梨梨梨梨梨梨梨梨梨梨梨鍋‥‥‥
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨Ⅱ梨梨梨梨梨梨梨梨梨梨梨梨梨狂‥‥
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨Ⅱ梨梨梨梨姉梨梨梨梨梨梨梨梨梨マ‥
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨環朕姉梨梨梨梨梨梨梨梨梨梨梨梨梨朕‥
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨狂鍋鍋鍋鍋梨梨梨梨梨梨梨梨梨梨梨梨梨狂
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨狂狂狂狂狂狂狂マ狂梨梨梨梨梨梨梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨マ狂狂狂ママママママママ狂梨梨梨梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨ママママママママママママ狂狂梨梨梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨狂ママママママママママママ狂狂狂梨梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨狂狂狂マママママママママママ狂狂鍋梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨マ狂狂狂マママママママママママ狂鍋姉梨姉姉姉梨
梨梨梨梨梨梨梨梨梨梨梨梨梨狂狂狂狂狂鍋姉姉朕環鍋狂マママ狂鍋朕梨梨梨梨姉梨
梨梨梨梨梨梨梨梨梨梨梨狂狂狂狂鍋環姉梨梨姉朕環環鍋狂狂狂狂鍋鍋環朕朕姉梨梨
梨梨梨梨梨梨梨梨梨梨狂狂狂狂朕姉朕環鍋狂狂狂狂狂鍋鍋鍋鍋鍋鍋狂狂マ狂鍋環梨
梨梨梨梨梨梨梨梨梨狂マママ鍋環狂ママママママ狂狂鍋鍋鍋鍋鍋狂狂狂マ狂鍋鍋梨
梨梨梨梨梨梨梨梨狂狂マママ狂狂ママママママ狂鍋鍋狂狂狂狂狂狂鍋鍋姉姉環環姉
梨梨マ梨梨梨梨狂狂狂マママママママ狂狂環環環環鍋狂ママ狂狂狂鍋マ梨梨梨環朕
梨狂梨梨梨梨朕狂狂狂マママママママ姉鍋鍋梨梨朕鍋マママ狂鍋狂鍋鍋環環環環環
梨マ梨梨梨梨姉鍋狂ママママママ鍋鍋鍋マ狂狂鍋鍋狂ママママ鍋狂狂狂鍋鍋狂狂鍋
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨Ⅱ梨梨梨梨梨梨梨梨梨梨梨梨鍋‥‥‥
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨Ⅱ梨梨梨梨梨梨梨梨梨梨梨梨梨狂‥‥
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨Ⅱ梨梨梨梨姉梨梨梨梨梨梨梨梨梨マ‥
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨環朕姉梨梨梨梨梨梨梨梨梨梨梨梨梨朕‥
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨狂鍋鍋鍋鍋梨梨梨梨梨梨梨梨梨梨梨梨梨狂
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨狂狂狂狂狂狂狂マ狂梨梨梨梨梨梨梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨マ狂狂狂ママママママママ狂梨梨梨梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨ママママママママママママ狂狂梨梨梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨狂ママママママママママママ狂狂狂梨梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨狂狂狂マママママママママママ狂狂鍋梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨マ狂狂狂マママママママママママ狂鍋姉梨姉姉姉梨
梨梨梨梨梨梨梨梨梨梨梨梨梨狂狂狂狂狂鍋姉姉朕環鍋狂マママ狂鍋朕梨梨梨梨姉梨
梨梨梨梨梨梨梨梨梨梨梨狂狂狂狂鍋環姉梨梨姉朕環環鍋狂狂狂狂鍋鍋環朕朕姉梨梨
梨梨梨梨梨梨梨梨梨梨狂狂狂狂朕姉朕環鍋狂狂狂狂狂鍋鍋鍋鍋鍋鍋狂狂マ狂鍋環梨
梨梨梨梨梨梨梨梨梨狂マママ鍋環狂ママママママ狂狂鍋鍋鍋鍋鍋狂狂狂マ狂鍋鍋梨
梨梨梨梨梨梨梨梨狂狂マママ狂狂ママママママ狂鍋鍋狂狂狂狂狂狂鍋鍋姉姉環環姉
梨梨マ梨梨梨梨狂狂狂マママママママ狂狂環環環環鍋狂ママ狂狂狂鍋マ梨梨梨環朕
梨狂梨梨梨梨朕狂狂狂マママママママ姉鍋鍋梨梨朕鍋マママ狂鍋狂鍋鍋環環環環環
梨マ梨梨梨梨姉鍋狂ママママママ鍋鍋鍋マ狂狂鍋鍋狂ママママ鍋狂狂狂鍋鍋狂狂鍋
157 ：●~*：03/05/02 22:12
梨鍋梨梨梨梨梨鍋狂マママママママ…ママ狂狂狂ママママママ狂鍋狂マ狂狂狂マ狂
梨梨環梨梨梨梨鍋狂狂狂ママママママママママママママママママ鍋鍋狂ママママ鍋
梨梨麻梨梨梨梨環狂狂狂狂マママママママママママママママママ鍋鍋狂ママママ鍋
梨梨行梨梨梨梨朕鍋狂狂マママママママママママママ鍋狂ママ…マ鍋鍋ママママ狂
梨梨麻梨梨梨梨朕鍋狂狂マママママ……マママママ狂ママ……ママ鍋鍋狂マママ狂
梨梨梨梨梨梨姉鍋鍋狂狂ママママママ…ママママ狂鍋ママ狂狂鍋環朕環鍋狂狂マ鍋
梨梨梨梨梨梨鍋狂狂狂ママママママママママ狂狂狂鍋鍋環狂鍋朕姉朕鍋鍋鍋狂狂鍋
梨梨梨梨梨梨梨梨梨梨マママママママママ狂狂狂ママママ狂狂狂鍋鍋鍋鍋鍋狂狂鍋
梨梨梨梨梨梨梨梨梨梨ママママママママ狂狂狂マ梨梨梨梨狂梨梨梨梨梨梨鍋狂鍋狂
梨梨梨梨梨梨梨梨梨梨梨ママママママママ狂梨梨狂マママ狂狂鍋環朕朕環梨梨環マ
梨梨梨梨梨姉鍋梨梨梨梨梨梨ママママママ梨鍋環環鍋鍋鍋鍋環環朕梨梨環狂梨梨‥
梨梨梨梨梨環環梨梨梨梨梨梨マママママ梨梨狂姉梨環鍋ママ狂狂朕姉朕狂狂梨梨‥
梨梨梨梨梨環朕環梨梨梨梨梨梨梨マママ梨梨狂鍋鍋鍋鍋鍋鍋鍋環朕環鍋狂鍋梨梨‥
梨梨梨梨梨姉環環梨梨梨梨梨梨梨梨梨梨梨マ狂ママ狂狂狂鍋鍋鍋環朕鍋鍋環梨‥‥
梨梨梨梨環梨環環梨梨梨梨梨梨梨梨梨梨梨狂狂マママ狂狂鍋環環環鍋鍋梨梨マ…‥
梨梨梨梨姉梨鍋環梨梨梨梨梨梨梨梨梨梨梨梨梨マママママ狂狂狂狂狂梨梨梨梨……
梨梨梨朕梨梨環環環梨梨梨梨梨梨梨梨梨梨梨梨梨ママママママママ狂鍋梨梨梨梨…
狂姉梨環姉梨環環環梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨姉姉鍋マ…
梨梨姉朕姉梨朕環環梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨鍋…
梨梨姉姉朕姉姉環環鍋環梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨姉梨梨梨梨姉梨梨鍋
梨梨梨梨環梨梨姉環環鍋鍋梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨
梨梨梨梨朕梨姉梨環鍋鍋鍋狂狂梨梨梨梨梨梨姉梨梨梨梨梨梨梨梨梨梨梨梨梨姉梨梨
梨梨環梨梨梨梨鍋狂狂狂ママママママママママママママママママ鍋鍋狂ママママ鍋
梨梨麻梨梨梨梨環狂狂狂狂マママママママママママママママママ鍋鍋狂ママママ鍋
梨梨行梨梨梨梨朕鍋狂狂マママママママママママママ鍋狂ママ…マ鍋鍋ママママ狂
梨梨麻梨梨梨梨朕鍋狂狂マママママ……マママママ狂ママ……ママ鍋鍋狂マママ狂
梨梨梨梨梨梨姉鍋鍋狂狂ママママママ…ママママ狂鍋ママ狂狂鍋環朕環鍋狂狂マ鍋
梨梨梨梨梨梨鍋狂狂狂ママママママママママ狂狂狂鍋鍋環狂鍋朕姉朕鍋鍋鍋狂狂鍋
梨梨梨梨梨梨梨梨梨梨マママママママママ狂狂狂ママママ狂狂狂鍋鍋鍋鍋鍋狂狂鍋
梨梨梨梨梨梨梨梨梨梨ママママママママ狂狂狂マ梨梨梨梨狂梨梨梨梨梨梨鍋狂鍋狂
梨梨梨梨梨梨梨梨梨梨梨ママママママママ狂梨梨狂マママ狂狂鍋環朕朕環梨梨環マ
梨梨梨梨梨姉鍋梨梨梨梨梨梨ママママママ梨鍋環環鍋鍋鍋鍋環環朕梨梨環狂梨梨‥
梨梨梨梨梨環環梨梨梨梨梨梨マママママ梨梨狂姉梨環鍋ママ狂狂朕姉朕狂狂梨梨‥
梨梨梨梨梨環朕環梨梨梨梨梨梨梨マママ梨梨狂鍋鍋鍋鍋鍋鍋鍋環朕環鍋狂鍋梨梨‥
梨梨梨梨梨姉環環梨梨梨梨梨梨梨梨梨梨梨マ狂ママ狂狂狂鍋鍋鍋環朕鍋鍋環梨‥‥
梨梨梨梨環梨環環梨梨梨梨梨梨梨梨梨梨梨狂狂マママ狂狂鍋環環環鍋鍋梨梨マ…‥
梨梨梨梨姉梨鍋環梨梨梨梨梨梨梨梨梨梨梨梨梨マママママ狂狂狂狂狂梨梨梨梨……
梨梨梨朕梨梨環環環梨梨梨梨梨梨梨梨梨梨梨梨梨ママママママママ狂鍋梨梨梨梨…
狂姉梨環姉梨環環環梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨姉姉鍋マ…
梨梨姉朕姉梨朕環環梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨鍋…
梨梨姉姉朕姉姉環環鍋環梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨姉梨梨梨梨姉梨梨鍋
梨梨梨梨環梨梨姉環環鍋鍋梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨
梨梨梨梨朕梨姉梨環鍋鍋鍋狂狂梨梨梨梨梨梨姉梨梨梨梨梨梨梨梨梨梨梨梨梨姉梨梨
158 ：●~*：03/05/02 22:57
フォントを小さくしてやっと見えた。
で、誰の顔？
で、誰の顔？
損し？と思われ。
>>156,157
>>156-157
こうか？
こうか？
>>163 正解みたいです、ｽﾏｿ。
梨がたぶん勘違いしてるのでひとつ。
バッケージってのは、ひとつのフォルダに関連性のあるファイルが詰め込まれているものの総称で、
アプリケーションパッケージはそのひとつ。
フォルダにパッケージフラグが立ってればFinderは内容がどうあれパッケージとして扱う。
確か、rtfdっていう、rtfを文章、画像等に分けて、パッケージ化したフォーマットがあったはず。
だから多分>>148さんが後半で言ってるのは書類パッケージがあれば面白いんではないか、ということだと思う。
バッケージってのは、ひとつのフォルダに関連性のあるファイルが詰め込まれているものの総称で、
アプリケーションパッケージはそのひとつ。
フォルダにパッケージフラグが立ってればFinderは内容がどうあれパッケージとして扱う。
確か、rtfdっていう、rtfを文章、画像等に分けて、パッケージ化したフォーマットがあったはず。
だから多分>>148さんが後半で言ってるのは書類パッケージがあれば面白いんではないか、ということだと思う。
>>165
パッケージ化されてるアプリって、中にバイナリファイルがある訳だ。
パッケージをダブルクリックすると、そいつが起動する仕組みだよね。
例えばね。
書類パッケージの中にデータを加工したアプリをカタログファイルの
ようなものに記述してパッケージ内に置いておく。
書類パッケージをダブルクリックしたら、指定のアプリを起動する。
「最終更新のデータ」「ユーザー◎◎が加工したデータ」「M月D日以降のデータ」とか
（メールソフトの「ルール」に近い感じで）カスタマイズ可能な複数の項目で検索する
ダイアログを出して、ファイルを特定。
確認ダイアログは必要かどうかはともかく、それでファイルを開く。
保存に関しては「別名で保存」「複製を保存」とか、ファイルを別途に新規作成する
場合も、カタログファイルに、検索に必要な項目を予め書き加えておくようにすれば
ユーザーが敢えてファイル名を考える必要もないと思う。
……なんて、妄想してみたのだけどね。
パッケージ化されてるアプリって、中にバイナリファイルがある訳だ。
パッケージをダブルクリックすると、そいつが起動する仕組みだよね。
例えばね。
書類パッケージの中にデータを加工したアプリをカタログファイルの
ようなものに記述してパッケージ内に置いておく。
書類パッケージをダブルクリックしたら、指定のアプリを起動する。
「最終更新のデータ」「ユーザー◎◎が加工したデータ」「M月D日以降のデータ」とか
（メールソフトの「ルール」に近い感じで）カスタマイズ可能な複数の項目で検索する
ダイアログを出して、ファイルを特定。
確認ダイアログは必要かどうかはともかく、それでファイルを開く。
保存に関しては「別名で保存」「複製を保存」とか、ファイルを別途に新規作成する
場合も、カタログファイルに、検索に必要な項目を予め書き加えておくようにすれば
ユーザーが敢えてファイル名を考える必要もないと思う。
……なんて、妄想してみたのだけどね。
>>166
たとえば、クォークで出力する場合に、必要な書類を一つにまとめる。
クォーク、イラストレーター、フォトショップ書類が混在していて、
ダブルクリックでクォーク書類のみ選択される（クォーク書類のみ開く）
ルールを決めたパッケージとか、DTPに特化して便利になりそう。
書類のリンクチェックとかもパスの部分を読んでやってくれるとなお便利。
たとえば、クォークで出力する場合に、必要な書類を一つにまとめる。
クォーク、イラストレーター、フォトショップ書類が混在していて、
ダブルクリックでクォーク書類のみ選択される（クォーク書類のみ開く）
ルールを決めたパッケージとか、DTPに特化して便利になりそう。
書類のリンクチェックとかもパスの部分を読んでやってくれるとなお便利。
>>167
うん。そうそう、便利だと思うんだけどね。
問題は、必ず「どういったルールでパッケージ内を検索して
対象ファイルを特定するか」というダイアログみたいなのが
パッケージ自体をダブルクリック（もしくはアプリにドラッグ＆
ドロップ）した時に必要になってしまうのではないか、なんだよね。
今のように、ファイルをダブルクリックしたら対応してるアプリが
起動する、ってのと比べると見かけ上1段階手間が増える。
「そのファイルがあるフォルダを開いて、目的のファイルを見つける」と
いう作業自体もコミコミなので、実際のところは手間は増えて
ないんだけど。
先にアプリを起動しておいて「ファイル」→「開く」とかやる場合は
手間は同じだけどね。
>書類のリンクチェックとかもパスの部分を読んでやってくれるとなお便利。
この辺は、DTP、Webサイト構築、プログラム開発のライブラリ依存関係
MP3のプレイリスト、ビデオ編集、3D CGのレンダリング等々、チェック機構を
汎用的な形にして、用途に合わせてテンプレをカスタマイズするとか
プラグイン形式にするとか、できたらカナーリ便利だよね。
っつうか、そういうチェック機能つきランチャーとか誰か作っておくれよ。
うん。そうそう、便利だと思うんだけどね。
問題は、必ず「どういったルールでパッケージ内を検索して
対象ファイルを特定するか」というダイアログみたいなのが
パッケージ自体をダブルクリック（もしくはアプリにドラッグ＆
ドロップ）した時に必要になってしまうのではないか、なんだよね。
今のように、ファイルをダブルクリックしたら対応してるアプリが
起動する、ってのと比べると見かけ上1段階手間が増える。
「そのファイルがあるフォルダを開いて、目的のファイルを見つける」と
いう作業自体もコミコミなので、実際のところは手間は増えて
ないんだけど。
先にアプリを起動しておいて「ファイル」→「開く」とかやる場合は
手間は同じだけどね。
>書類のリンクチェックとかもパスの部分を読んでやってくれるとなお便利。
この辺は、DTP、Webサイト構築、プログラム開発のライブラリ依存関係
MP3のプレイリスト、ビデオ編集、3D CGのレンダリング等々、チェック機構を
汎用的な形にして、用途に合わせてテンプレをカスタマイズするとか
プラグイン形式にするとか、できたらカナーリ便利だよね。
っつうか、そういうチェック機能つきランチャーとか誰か作っておくれよ。
>>168
> 問題は、必ず「どういったルールでパッケージ内を検索して
> 対象ファイルを特定するか」というダイアログみたいなのが
> パッケージ自体をダブルクリック（もしくはアプリにドラッグ＆
> ドロップ）した時に必要になってしまうのではないか、なんだよね。
いや、ここで提示したのは最終的に相手に渡す手段としてのパッケージで。
htmlなら、index.htmみたいなのを起動させ、他の書類はそこからリンクしているだけ、
DTPなら、出力書類のみが選択されるってのを想定した。
制作段階ではパッケージしないわけ。
パッケージのメリットは不必要なファイルにユーザーが触れないことだと思う。
> >書類のリンクチェックとかもパスの部分を読んでやってくれるとなお便利。
>
> この辺は、DTP、Webサイト構築、プログラム開発のライブラリ依存関係
> MP3のプレイリスト、ビデオ編集、3D CGのレンダリング等々、チェック機構を
> 汎用的な形にして、用途に合わせてテンプレをカスタマイズするとか
> プラグイン形式にするとか、できたらカナーリ便利だよね。
>
> っつうか、そういうチェック機能つきランチャーとか誰か作っておくれよ。
さすがにそれを網羅したアプリは……
でも、それをOS標準で付けたらすごいかも。
パッケージ化の時にプラグイン形式でチェックできるようにし、付加価値を高める。
> 問題は、必ず「どういったルールでパッケージ内を検索して
> 対象ファイルを特定するか」というダイアログみたいなのが
> パッケージ自体をダブルクリック（もしくはアプリにドラッグ＆
> ドロップ）した時に必要になってしまうのではないか、なんだよね。
いや、ここで提示したのは最終的に相手に渡す手段としてのパッケージで。
htmlなら、index.htmみたいなのを起動させ、他の書類はそこからリンクしているだけ、
DTPなら、出力書類のみが選択されるってのを想定した。
制作段階ではパッケージしないわけ。
パッケージのメリットは不必要なファイルにユーザーが触れないことだと思う。
> >書類のリンクチェックとかもパスの部分を読んでやってくれるとなお便利。
>
> この辺は、DTP、Webサイト構築、プログラム開発のライブラリ依存関係
> MP3のプレイリスト、ビデオ編集、3D CGのレンダリング等々、チェック機構を
> 汎用的な形にして、用途に合わせてテンプレをカスタマイズするとか
> プラグイン形式にするとか、できたらカナーリ便利だよね。
>
> っつうか、そういうチェック機能つきランチャーとか誰か作っておくれよ。
さすがにそれを網羅したアプリは……
でも、それをOS標準で付けたらすごいかも。
パッケージ化の時にプラグイン形式でチェックできるようにし、付加価値を高める。
>>169
ああ、なるほどね。理解しますタ。IEのWebアーカイブ形式とかも
結構、近い感じかな。
話を少しだけ戻すと……
実際、１つの制作物（俺の場合はイラストとかなんだが）フォルダの中に
データが複数あった場合、どのくらい作業をした時点で保存したか
ファイル名と修正日で、だいたい見当がつく？
最初のウチは無問題なんだけど、ファイルが何十個にもなって
子フォルダで分類しても、納期間際の土壇場になってくると
段々ﾜｹﾜｶﾗﾝ状態に……(w
Photoshopのファイルブラウザでプレビューしながら探し回ったり
しているんだけど……俺に整頓能力が欠如しているだけ？(w
>さすがにそれを網羅したアプリは……
>でも、それをOS標準で付けたらすごいかも。
でしょ。MINEタイプを判定したり、本文検索したりできるんだから
その辺までは「あとちょっと」って感じがするけどなあ。
本文要約機能よりは役に立つと思う(w
ああ、なるほどね。理解しますタ。IEのWebアーカイブ形式とかも
結構、近い感じかな。
話を少しだけ戻すと……
実際、１つの制作物（俺の場合はイラストとかなんだが）フォルダの中に
データが複数あった場合、どのくらい作業をした時点で保存したか
ファイル名と修正日で、だいたい見当がつく？
最初のウチは無問題なんだけど、ファイルが何十個にもなって
子フォルダで分類しても、納期間際の土壇場になってくると
段々ﾜｹﾜｶﾗﾝ状態に……(w
Photoshopのファイルブラウザでプレビューしながら探し回ったり
しているんだけど……俺に整頓能力が欠如しているだけ？(w
>さすがにそれを網羅したアプリは……
>でも、それをOS標準で付けたらすごいかも。
でしょ。MINEタイプを判定したり、本文検索したりできるんだから
その辺までは「あとちょっと」って感じがするけどなあ。
本文要約機能よりは役に立つと思う(w
171 ：167 遅レスすまソ。：03/05/19 02:47
>>170
ううむ、それはカタログソフトでなんとかなるようなw
作業用と納品フォルダを分けるとか。
いったん納品フォルダに入れた物でも手直しする時は作業フォルダに写してからね。
作業中に名前が変わってしまった物も、後からリネームツール使って同じ名前で始まる連番にしたほうがいいと思う。
日付け順にリスト表示させると、同じ作品がかたまって、なおかつその中で新しい物が上にくる。
OSが作業中の物はpsd、納品物はtiffやpng、jpegにした場合にフィルタリングしてくれると、助かるとも思うけど。
つうわけで、標準でバックアップツールがあったわけだし、
・「元フォルダ」に作業用フォルダを設定（複数可能）し、
・「バックアップ先フォルダ」に納品用のフォルダを指定する。
・apple event でフォトショップが画像を開いていない（つまり作業終了）時にバックアップ開始。
ただし、OSXでpsdが読めるんだから、保存時はpngなりjpegにも変換してくれる。
そんなツールを標準装備してくれたらいいなあ。
な～んて思っちゃったりなんかして。
ううむ、それはカタログソフトでなんとかなるようなw
作業用と納品フォルダを分けるとか。
いったん納品フォルダに入れた物でも手直しする時は作業フォルダに写してからね。
作業中に名前が変わってしまった物も、後からリネームツール使って同じ名前で始まる連番にしたほうがいいと思う。
日付け順にリスト表示させると、同じ作品がかたまって、なおかつその中で新しい物が上にくる。
OSが作業中の物はpsd、納品物はtiffやpng、jpegにした場合にフィルタリングしてくれると、助かるとも思うけど。
つうわけで、標準でバックアップツールがあったわけだし、
・「元フォルダ」に作業用フォルダを設定（複数可能）し、
・「バックアップ先フォルダ」に納品用のフォルダを指定する。
・apple event でフォトショップが画像を開いていない（つまり作業終了）時にバックアップ開始。
ただし、OSXでpsdが読めるんだから、保存時はpngなりjpegにも変換してくれる。
そんなツールを標準装備してくれたらいいなあ。
な～んて思っちゃったりなんかして。
>>171
オカエリナサイ。
>ううむ、それはカタログソフトでなんとかなるようなw
扱ってるファイルサイズが大きいので、カタログ化するにしても時間がかかるし、
サムネール表示だと差異もわかりづらい。ちょっと前に幾つか導入してみたんだけど
しっくり来るカタログソフトがなかったんだよね……最新のだと具合が良いのがあるかも
しれんけど。
>OSが作業中の物はpsd、納品物はtiffやpng、jpegにした場合にフィルタリングしてくれると、助かるとも思うけど。
禿同。まさにOSの方にアプリごとにフィルタリング条件を登録できるようになっていれば
ｲｲと思う。
実際のところパッケージフォルダでなくて、任意に指定したフォルダでも良いんだしね。
PSDとかだと「ファイル情報」とかあるけど、あれで検索できると大分違うんだけどな。
（あとは、レイヤーの枚数とかね）
オカエリナサイ。
>ううむ、それはカタログソフトでなんとかなるようなw
扱ってるファイルサイズが大きいので、カタログ化するにしても時間がかかるし、
サムネール表示だと差異もわかりづらい。ちょっと前に幾つか導入してみたんだけど
しっくり来るカタログソフトがなかったんだよね……最新のだと具合が良いのがあるかも
しれんけど。
>OSが作業中の物はpsd、納品物はtiffやpng、jpegにした場合にフィルタリングしてくれると、助かるとも思うけど。
禿同。まさにOSの方にアプリごとにフィルタリング条件を登録できるようになっていれば
ｲｲと思う。
実際のところパッケージフォルダでなくて、任意に指定したフォルダでも良いんだしね。
PSDとかだと「ファイル情報」とかあるけど、あれで検索できると大分違うんだけどな。
（あとは、レイヤーの枚数とかね）
━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―
>扱ってるファイルサイズが大きいので、カタログ化するにしても時間がかかるし、
>サムネール表示だと差異もわかりづらい。
つまり、「目視確認」は無理ってことか……OSXのアイコン最大表示への感想希望。
ウインドウ表示に「アイコン」てあるでしょ。それがより、拡張されたもの……
ファイルビューとしては、リスト表示、カラム表示・エクスプローラタイプ最強。
でも、75さんみたいに、ファイル名、ファイルタイプ、容量、修正日に縛られないルール付けもほしい。
ふと思ったけど、「アイコン」「リスト」「カラム」以外の表示方法がオンラインウェアのプラグインで
拡張できるようにならないだろうか。
それこそ、プレビューソフトの代替として。
アイコン表示なのに、その下に任意のファイル情報が表示できる、なんて感じで。
あと、「修正日」「ファイル表示」以外に「レイヤー情報」なんかを認識するプラグイン必須。
それとは別に、現在ファイル保存時に狭いダイアログにフォルダが表示されて、ユーザーは名前だけ決める。
そうじゃなくて、アイコン表示の画面になり、保存する座標を決められたならば、アイコン表示はもっと良い物に。
あとやっぱり、「特定フォルダのPSDを別フォルダにTIFFで抽出してまとめる」てやってくれAPPLE。
たぶん、写真屋のバッチ処理よりネイティブなので早いはず（想像）
>サムネール表示だと差異もわかりづらい。
つまり、「目視確認」は無理ってことか……OSXのアイコン最大表示への感想希望。
ウインドウ表示に「アイコン」てあるでしょ。それがより、拡張されたもの……
ファイルビューとしては、リスト表示、カラム表示・エクスプローラタイプ最強。
でも、75さんみたいに、ファイル名、ファイルタイプ、容量、修正日に縛られないルール付けもほしい。
ふと思ったけど、「アイコン」「リスト」「カラム」以外の表示方法がオンラインウェアのプラグインで
拡張できるようにならないだろうか。
それこそ、プレビューソフトの代替として。
アイコン表示なのに、その下に任意のファイル情報が表示できる、なんて感じで。
あと、「修正日」「ファイル表示」以外に「レイヤー情報」なんかを認識するプラグイン必須。
それとは別に、現在ファイル保存時に狭いダイアログにフォルダが表示されて、ユーザーは名前だけ決める。
そうじゃなくて、アイコン表示の画面になり、保存する座標を決められたならば、アイコン表示はもっと良い物に。
あとやっぱり、「特定フォルダのPSDを別フォルダにTIFFで抽出してまとめる」てやってくれAPPLE。
たぶん、写真屋のバッチ処理よりネイティブなので早いはず（想像）
175 ：梨：03/06/29 13:41
あ。最近考えてた事と被るなあ。
>>165-174
「ファイルからいかに情報を集めるか」
「ファイルにいかに多くの情報を記録するか」
というのは、今後のファイルシステムが検討すべき課題だけど、
実は単にデータフォークとリソースフォークに分ければ済む話だと思う。
情報はXML(MSSQLでもいいけどさ)に保存して対応づけて、
UIがXMLに対応すれば、それらの情報表示も出来る事になるね。
検索はテキスト全文検索があればいいわけだし。
で、それらの情報を包有する「モダンファイル構成」を、
パッケージ形式で提供すれば良い。
ということだよね？
>>165-174
「ファイルからいかに情報を集めるか」
「ファイルにいかに多くの情報を記録するか」
というのは、今後のファイルシステムが検討すべき課題だけど、
実は単にデータフォークとリソースフォークに分ければ済む話だと思う。
情報はXML(MSSQLでもいいけどさ)に保存して対応づけて、
UIがXMLに対応すれば、それらの情報表示も出来る事になるね。
検索はテキスト全文検索があればいいわけだし。
で、それらの情報を包有する「モダンファイル構成」を、
パッケージ形式で提供すれば良い。
ということだよね？
あぼーん
あぼーん
178 ：梨：03/06/29 13:55
>>166
パッケージが独自のバージョン管理レイアを持つ形になるよね。
>>167
いわゆるWebアーカイブの発想よね。って下で書かれているけど。
>>168
現行のUIに呼応させるなら、
最後に使ったファイルとアプリを覚えておいてそれを呼び出す形かな。
>>169
リンクチェックの汎用化は難しいでしょう。
労力のわりに意義のある統一とは思えないなあ。
ファイルのリンク管理の部分だけ情報を二重化する形なら可能かな。
>>170
パッケージが外部アプリのコンバータを利用出来るという前提なら、
コンバートすれば出力出来るものは「キャッシュ」とみなせるよね。
足りないものは都度「コンバート」して、
速度が必要なら「キャッシュ」を使えば、メタな扱いは出来るのでは。
>>171
「作業用」パッケージを「納品」アイコンにドラッグするとかは？
個人的には右クリックが一番いいんだけど。
「キャッシュ」として考えるなら、
フィルタリングでは無く「抽出」のような気もする。
って、>>174に書いてあったね。
なんか、漏れが話せば話すほど、
UIではなくAPIの話になっていくような。。。
パッケージが独自のバージョン管理レイアを持つ形になるよね。
>>167
いわゆるWebアーカイブの発想よね。って下で書かれているけど。
>>168
現行のUIに呼応させるなら、
最後に使ったファイルとアプリを覚えておいてそれを呼び出す形かな。
>>169
リンクチェックの汎用化は難しいでしょう。
労力のわりに意義のある統一とは思えないなあ。
ファイルのリンク管理の部分だけ情報を二重化する形なら可能かな。
>>170
パッケージが外部アプリのコンバータを利用出来るという前提なら、
コンバートすれば出力出来るものは「キャッシュ」とみなせるよね。
足りないものは都度「コンバート」して、
速度が必要なら「キャッシュ」を使えば、メタな扱いは出来るのでは。
>>171
「作業用」パッケージを「納品」アイコンにドラッグするとかは？
個人的には右クリックが一番いいんだけど。
「キャッシュ」として考えるなら、
フィルタリングでは無く「抽出」のような気もする。
って、>>174に書いてあったね。
なんか、漏れが話せば話すほど、
UIではなくAPIの話になっていくような。。。
>>175
>で、それらの情報を包有する「モダンファイル構成」を、
>パッケージ形式で提供すれば良い。
結局そうなるのかな？
パッケージ内で雑多に同時進行するファイルをOS標準の何か（って何だ）がうまく管理し、ユーザーはパッケージのみを大雑把に管理する、と。
「でもそれってもう新しいアプリケーションを開発して１ファイルにしてOKじゃ？」とも思うが、実際はファイル損傷のリスクとか、他のプロジェクトで流用するケース、DTP←→HTMLとかで、抜き出す手間を考えるとパッケージの佳さがあると思う。
Wordに埋め込まれた高解像度ビットマップ画像を抜き出したことがあるが、大変だった。
>>178
>リンクチェックの汎用化は難しいでしょう。
>労力のわりに意義のある統一とは思えないなあ。
とりあえず、「シリアルが必要」「やたら重たい」イラレを立ち上げずにリンクチェックできるソフトはあって、そこそこ重宝している。シンプルにチェックのみできるし。
……思うんだが、アプリケーションと書類の相互依存性を、現在のWINの「関連づけ」、Macの「クリエータ」がサポートしている。
同じように、書類同士の依存関係をOSがサポートしてほしいな。上のアプリが必要無いくらいに。
>ファイルのリンク管理の部分だけ情報を二重化する形なら可能かな。
妄想が入るけど、DTPアプリが共有して使うリソースフォークだったらMacは天下泰平だった……
う～ん、しかしリソースってのはナイスなアイディアかも。
>「キャッシュ」として考えるなら、
>フィルタリングでは無く「抽出」のような気もする。
それで言い直した訳ですわ。相手には必要なデータのみ渡したいね。
>で、それらの情報を包有する「モダンファイル構成」を、
>パッケージ形式で提供すれば良い。
結局そうなるのかな？
パッケージ内で雑多に同時進行するファイルをOS標準の何か（って何だ）がうまく管理し、ユーザーはパッケージのみを大雑把に管理する、と。
「でもそれってもう新しいアプリケーションを開発して１ファイルにしてOKじゃ？」とも思うが、実際はファイル損傷のリスクとか、他のプロジェクトで流用するケース、DTP←→HTMLとかで、抜き出す手間を考えるとパッケージの佳さがあると思う。
Wordに埋め込まれた高解像度ビットマップ画像を抜き出したことがあるが、大変だった。
>>178
>リンクチェックの汎用化は難しいでしょう。
>労力のわりに意義のある統一とは思えないなあ。
とりあえず、「シリアルが必要」「やたら重たい」イラレを立ち上げずにリンクチェックできるソフトはあって、そこそこ重宝している。シンプルにチェックのみできるし。
……思うんだが、アプリケーションと書類の相互依存性を、現在のWINの「関連づけ」、Macの「クリエータ」がサポートしている。
同じように、書類同士の依存関係をOSがサポートしてほしいな。上のアプリが必要無いくらいに。
>ファイルのリンク管理の部分だけ情報を二重化する形なら可能かな。
妄想が入るけど、DTPアプリが共有して使うリソースフォークだったらMacは天下泰平だった……
う～ん、しかしリソースってのはナイスなアイディアかも。
>「キャッシュ」として考えるなら、
>フィルタリングでは無く「抽出」のような気もする。
それで言い直した訳ですわ。相手には必要なデータのみ渡したいね。
180 ：梨：03/07/01 23:24
このｽﾚはコンセンサスまでが早くて気持ちいいな。
>>179
> 書類同士の依存関係をOSがサポートしてほしいな。
仮に二重化するなら、
「どのファイルがどのファイルに依存しているのか」をOSが別途管理。
管理するために、所定のフォーマットから「抜き出す」のは力業で対応。
参照カウンタみたいな概念があれば実は成り立つのかも。
きっとその世界では、すべてのファイルはディレクトリでもあるんだろうね。
相互参照はどうするんだ、とか一瞬思ったけれど。
真面目にやるなら、
「どのファイルの」「どの部分に」「どのような形で」
リンクしているのかをOSが汎用化した上で持たなければならない。
この「汎用化」ってのがいまいちピンとこないんだよな。
クリップボードの内容を別のアプリに切り貼りする事に似ているかも。
「OSの機能を使う」とはいっても、疲れるのは結局アプリという罠。
>>179
> 書類同士の依存関係をOSがサポートしてほしいな。
仮に二重化するなら、
「どのファイルがどのファイルに依存しているのか」をOSが別途管理。
管理するために、所定のフォーマットから「抜き出す」のは力業で対応。
参照カウンタみたいな概念があれば実は成り立つのかも。
きっとその世界では、すべてのファイルはディレクトリでもあるんだろうね。
相互参照はどうするんだ、とか一瞬思ったけれど。
真面目にやるなら、
「どのファイルの」「どの部分に」「どのような形で」
リンクしているのかをOSが汎用化した上で持たなければならない。
この「汎用化」ってのがいまいちピンとこないんだよな。
クリップボードの内容を別のアプリに切り貼りする事に似ているかも。
「OSの機能を使う」とはいっても、疲れるのは結局アプリという罠。
あぼーん
>>180
> 真面目にやるなら、
> 「どのファイルの」「どの部分に」「どのような形で」
> リンクしているのかをOSが汎用化した上で持たなければならない。
>
> この「汎用化」ってのがいまいちピンとこないんだよな。
> クリップボードの内容を別のアプリに切り貼りする事に似ているかも。
> 「OSの機能を使う」とはいっても、疲れるのは結局アプリという罠。
二重化したリンク情報は、OSが、リンクしているファイルの相関図、エリアマップみたいなものをパッケージ内の書類で提供するってのはどうだろう。
これって
> 参照カウンタみたいな概念があれば実は成り立つのかも。
で思ったんだけど。
アプリ側がOS側に申請すると他のアプリでも読み込める形式で、相関図を書く。
通常、リンクした複数ファイルってのは複数に枝分かれするような状態で、必ず親子の関係がある。
（DTPとかのリンクってのはHTMLのスタイルシート、プログラムでの個別のスプリクトみたいなものかな）
なので、かならず頭になる書類は強弱関係で導きだされる。
>この「汎用化」ってのがいまいちピンとこないんだよな。
でも、引用されている書類の形式によって、大体用途が限られていると思うんだよね。
ビットマップを引用して、音楽に変換するような酔狂なことをしない限りは。
パッケージをポンと他人に渡せるし、後で中身を他のアプリが容易に再利用できる橋渡しとして、リンク情報だけでも十分かなあと……。
ちょっとパッケージの話からそれるけど、最低でも今までの常識では「このファイルがこのファイルを欲しがっている」ことを知る方法はあったけど、その逆はなかった。
それがレベルの低い動作でできるようになったらかなりの進歩だと思うなあ。
Finderでゴミ箱に持って行ったり、引用されているファイルをうっかりいじってしまう前に、どういったファイルが引用しているか知らせて警告してくれたり。
そうしたら、僕はなんて親切なUIだろうって思うよ。
「ウザイ」って思う人はいるだろうけど、仕事がからむとまた別。
> 真面目にやるなら、
> 「どのファイルの」「どの部分に」「どのような形で」
> リンクしているのかをOSが汎用化した上で持たなければならない。
>
> この「汎用化」ってのがいまいちピンとこないんだよな。
> クリップボードの内容を別のアプリに切り貼りする事に似ているかも。
> 「OSの機能を使う」とはいっても、疲れるのは結局アプリという罠。
二重化したリンク情報は、OSが、リンクしているファイルの相関図、エリアマップみたいなものをパッケージ内の書類で提供するってのはどうだろう。
これって
> 参照カウンタみたいな概念があれば実は成り立つのかも。
で思ったんだけど。
アプリ側がOS側に申請すると他のアプリでも読み込める形式で、相関図を書く。
通常、リンクした複数ファイルってのは複数に枝分かれするような状態で、必ず親子の関係がある。
（DTPとかのリンクってのはHTMLのスタイルシート、プログラムでの個別のスプリクトみたいなものかな）
なので、かならず頭になる書類は強弱関係で導きだされる。
>この「汎用化」ってのがいまいちピンとこないんだよな。
でも、引用されている書類の形式によって、大体用途が限られていると思うんだよね。
ビットマップを引用して、音楽に変換するような酔狂なことをしない限りは。
パッケージをポンと他人に渡せるし、後で中身を他のアプリが容易に再利用できる橋渡しとして、リンク情報だけでも十分かなあと……。
ちょっとパッケージの話からそれるけど、最低でも今までの常識では「このファイルがこのファイルを欲しがっている」ことを知る方法はあったけど、その逆はなかった。
それがレベルの低い動作でできるようになったらかなりの進歩だと思うなあ。
Finderでゴミ箱に持って行ったり、引用されているファイルをうっかりいじってしまう前に、どういったファイルが引用しているか知らせて警告してくれたり。
そうしたら、僕はなんて親切なUIだろうって思うよ。
「ウザイ」って思う人はいるだろうけど、仕事がからむとまた別。
●梨は、おそいCPUが大好き。
●梨は、低シェアPCが大好き。
●梨は、妄想が大好き。
●梨は、コピペが大好き。
●梨は、なりすましが大好き。
●梨は、9時と13時に書込むのが大好き。
184 ：167：03/07/03 00:02
>>183
Finderで、使用中のファイルを捨てれなかったり、拡張機能などをシステムフォルダに重ねるとしかるべきところへ持って行ってくれる……。
これって親切だと思う。もちろん、拡張機能を好きなところに置くこともできる。この柔軟さ。
僕が182で書いているのは「強制的に捨てられない」ていうんじゃなくて、アップルイベントとして、
「このファイルを必要としているファイルがあるか？」
という問いにMacが 0／1 で答えてくる。というのを考えているんだよ。
物を創る人にとって本当に必要といえるOSであれば、実装して欲しいファイル管理だ。
僕はずっと「OSXでこんなUI、ユーザーのアクションに応える動作をしてくれたらなあ」という意見で一貫している。
おっと、騙りか……
Finderで、使用中のファイルを捨てれなかったり、拡張機能などをシステムフォルダに重ねるとしかるべきところへ持って行ってくれる……。
これって親切だと思う。もちろん、拡張機能を好きなところに置くこともできる。この柔軟さ。
僕が182で書いているのは「強制的に捨てられない」ていうんじゃなくて、アップルイベントとして、
「このファイルを必要としているファイルがあるか？」
という問いにMacが 0／1 で答えてくる。というのを考えているんだよ。
物を創る人にとって本当に必要といえるOSであれば、実装して欲しいファイル管理だ。
僕はずっと「OSXでこんなUI、ユーザーのアクションに応える動作をしてくれたらなあ」という意見で一貫している。
おっと、騙りか……
185 ：梨：03/07/03 15:43
一部省略。ごめんね。
>>184
インストールパッケージの依存管理と同じ概念なのかな？
> 「強制的に捨てられない」ていうんじゃなくて、
> 「このファイルを必要としているファイルがあるか？」
> という問いにMacが 0／1 で答えてくる。
それに対してとれる行動は、
・削除を中止する。（推奨）
・強制的に削除する。
というのでいいのかな？
OSXでは、ロックがかかったディレクトリは開くことが出来ないのね。
中のファイルを見るにはコンソールを使うか検索するしかない。不便だ。
>>184
インストールパッケージの依存管理と同じ概念なのかな？
> 「強制的に捨てられない」ていうんじゃなくて、
> 「このファイルを必要としているファイルがあるか？」
> という問いにMacが 0／1 で答えてくる。
それに対してとれる行動は、
・削除を中止する。（推奨）
・強制的に削除する。
というのでいいのかな？
OSXでは、ロックがかかったディレクトリは開くことが出来ないのね。
中のファイルを見るにはコンソールを使うか検索するしかない。不便だ。
あぼーん
187 ：梨：03/07/03 16:14
>>182
補足じゃなくてこっちにレスすれば良かった。
> 通常、リンクした複数ファイルってのは複数に枝分かれするような状態で、必ず親子の関係がある。
・リンクされないファイルも存在する。
・リンクされているファイル同士が対等に結びついている事は無い。
という事だよね。
それでいて、
・どのような内容でリンクされているかは考慮しない。
・リンク情報は親→子、子→親の両方を参照出来るようにする。
というわけだ。
なんか、自分で書いてて「循環参照はありうる」とか思ったけど、
まあ、それは置いておくとしたら、それなりに意義があるのかも。
ハードリンクの拡張みたいな位置づけになるのかなあ。
補足じゃなくてこっちにレスすれば良かった。
> 通常、リンクした複数ファイルってのは複数に枝分かれするような状態で、必ず親子の関係がある。
・リンクされないファイルも存在する。
・リンクされているファイル同士が対等に結びついている事は無い。
という事だよね。
それでいて、
・どのような内容でリンクされているかは考慮しない。
・リンク情報は親→子、子→親の両方を参照出来るようにする。
というわけだ。
なんか、自分で書いてて「循環参照はありうる」とか思ったけど、
まあ、それは置いておくとしたら、それなりに意義があるのかも。
ハードリンクの拡張みたいな位置づけになるのかなあ。
188 ：167：03/07/04 01:17
>>187
> ハードリンクの拡張みたいな位置づけになるのかなあ。
無知なんでぐぐったけど、そういう感じで。UNIX系のメリットが生かせるのかなぁ。
>>185
> インストールパッケージの依存管理と同じ概念なのかな？
>
> > 「強制的に捨てられない」ていうんじゃなくて、
> > 「このファイルを必要としているファイルがあるか？」
> > という問いにMacが 0／1 で答えてくる。
>
> それに対してとれる行動は、
> ・削除を中止する。（推奨）
> ・強制的に削除する。
> というのでいいのかな？
「保守モード」に入っている時とか、パッケージに指定したフォルダ内（上のハードリンク的リンクマップがそのパッケージ内に埋め込まれるとかして）でのみ、そのダイヤログがでることを希望するね。
で、上の二つの行動を促すボタン以外に、問題のファイルを開くボタンもあってほしいな。
WINとの差別化をするならば。
そして、「捨てる」アクションに対してだけでなく、アプリなりFinder上の操作による問い合わせにも気軽に応えて欲しい。
と、ここで思ったのは、パッケージってリソースに代わる存在なんだろうか。
> OSXでは、ロックがかかったディレクトリは開くことが出来ないのね。
> 中のファイルを見るにはコンソールを使うか検索するしかない。不便だ。
>
無理矢理コンソールを使わせる作戦なんだろう。
> ハードリンクの拡張みたいな位置づけになるのかなあ。
無知なんでぐぐったけど、そういう感じで。UNIX系のメリットが生かせるのかなぁ。
>>185
> インストールパッケージの依存管理と同じ概念なのかな？
>
> > 「強制的に捨てられない」ていうんじゃなくて、
> > 「このファイルを必要としているファイルがあるか？」
> > という問いにMacが 0／1 で答えてくる。
>
> それに対してとれる行動は、
> ・削除を中止する。（推奨）
> ・強制的に削除する。
> というのでいいのかな？
「保守モード」に入っている時とか、パッケージに指定したフォルダ内（上のハードリンク的リンクマップがそのパッケージ内に埋め込まれるとかして）でのみ、そのダイヤログがでることを希望するね。
で、上の二つの行動を促すボタン以外に、問題のファイルを開くボタンもあってほしいな。
WINとの差別化をするならば。
そして、「捨てる」アクションに対してだけでなく、アプリなりFinder上の操作による問い合わせにも気軽に応えて欲しい。
と、ここで思ったのは、パッケージってリソースに代わる存在なんだろうか。
> OSXでは、ロックがかかったディレクトリは開くことが出来ないのね。
> 中のファイルを見るにはコンソールを使うか検索するしかない。不便だ。
>
無理矢理コンソールを使わせる作戦なんだろう。
● ● ● ● ● ● ● ● ● ● ● と
梨 梨 梨 梨 梨 梨 梨 梨 梨 梨 梨 こ
な は は は は は は は は は は は ろ
ん ?A ?A ?A ?A ?A ?A ?A ?A ?A ?A ?A で
で カ ラ 論 ガ 荒 ９ な コ 妄 低 お
だ タ リ 破 イ し 時 り ピ 想 シ そ
ろ ロ ッ さ ド が と す ペ が ェ い
？ グ っ れ ラ 大 １ ま が 大 ア Ｃ
評 て る イ 好 ３ し 大 好 Ｐ Ｐ
論 る の ン き 時 が 好 き Ｃ Ｕ
が の が が ?B に 大 き ?B が が
大 が 大 大 書 好 ?B 大 大
好 大 好 好 込 き 好 好
き 好 き き む ?B き き
?B き ?B ?B の ?B ?B
?B が
大
好
き
?B
┏━━━━━━━━━━━━━┓
┃ ┃
┃ 他お Ｏパ 板 ┃
┃ の願 Ｓソ 違 ┃
┃ マ 住い 板コ い ┃
┃ ッ 民し ?Bン で ┃
┃ ク のま 等一 す ┃
┃ マ 迷す で般 ?B ┃
┃ ナ 惑?B 板 ┃
┃ ｜ で ?B ┃
┃ 哲 す ┃
┃ 学 ?B ┃
┃ ┃
┗━━━━━━━━━━━━━┛
>189-190
激しくスレ違い。
激しくスレ違い。
__∧＿∧_
|（ ＾＾ ）| ＜寝るぽ（＾＾）
|＼⌒⌒⌒＼
＼ |⌒⌒⌒~| 山崎渉
~￣￣￣￣
記念眞紀子
194 ：●~*：03/10/03 00:29
ネタはないがあげてみるか
梨って人自分に酔ってるね.
ｵﾏｴﾓﾅｰ
↑名前忘れてますよ梨さん
198 ：たかちゃん ◆aYYJ4NEyLs ：04/04/02 22:31
なんか>>166-168あたりで語られていることってー
Adobe VersionCueが結構近いかな、とか思ったり。
２ちゃんのやり取りの方がAdobeのリリースより先行してるって
なんか珍しいよねー。
Adobe VersionCueが結構近いかな、とか思ったり。
２ちゃんのやり取りの方がAdobeのリリースより先行してるって
なんか珍しいよねー。
>>198
旧板って結構こういうレベルの高い内容があったりして侮れないよね
旧板って結構こういうレベルの高い内容があったりして侮れないよね
200 ：ガ ◆6XyRRDn11E ：04/07/16 22:52
ここで167とかで書き込んでたんだけど、75さんはコテだったのかな……
そろそろ、拡張的で高度な処理に対する、
新しいインタフェースの「標準」を用意して欲しいなあ。
仕事ならいいけど、趣味で触った最新のフレームワークで最初に作った物が、
自分用にカスタマイズされた拡張フォーム部品です、みたいな寒いのは嫌だ。。
新しいインタフェースの「標準」を用意して欲しいなあ。
仕事ならいいけど、趣味で触った最新のフレームワークで最初に作った物が、
自分用にカスタマイズされた拡張フォーム部品です、みたいな寒いのは嫌だ。。
私には難しい話はわかりません。
OSXだってよくわかんねぇよ～
同じ名前のﾌｫﾙﾀﾞが3つぐらいあるんだもん。
OSXだってよくわかんねぇよ～
同じ名前のﾌｫﾙﾀﾞが3つぐらいあるんだもん。
ライブラリとかシステムのライブラリとかユーザーのライブラリとか・・・
マルチユーザ設計だからねえ。
良い事だとは思うけど、もうちょっとなんとかして欲しい。
/System/bin
/System/lib
/System/hoge
/Users/nasi/bin
/Users/nasi/lib
/Users/nasi/hoge
/Users/konosiro/bin
/Users/konosiro/lib
/Users/konosiro/hoge
みたいなフォルダ構成にしたほうが絶対いいよね。
そろそろそうなるんかな。あっちの世界では。
良い事だとは思うけど、もうちょっとなんとかして欲しい。
/System/bin
/System/lib
/System/hoge
/Users/nasi/bin
/Users/nasi/lib
/Users/nasi/hoge
/Users/konosiro/bin
/Users/konosiro/lib
/Users/konosiro/hoge
みたいなフォルダ構成にしたほうが絶対いいよね。
そろそろそうなるんかな。あっちの世界では。
Apple様製 Library 群と
サードパーティー製 Library 群と
個人用 Libray群 と
ネット起動時用の Libray 群
俺としてはこれってすごく分かりやすいんだが。
インストーラーなしのアプリは全部 ~/Applications に入れる人だし。
バックアップが楽だから。
以前某メーラーを作ってるときは、それ用のFrameworkも ~/Frameworks に入れてた。
使い方にも ~/Frameworks を作ってそこに入れろって書いたし。
管理者でなくても投入可能なのがいいよね。
サードパーティー製 Library 群と
個人用 Libray群 と
ネット起動時用の Libray 群
俺としてはこれってすごく分かりやすいんだが。
インストーラーなしのアプリは全部 ~/Applications に入れる人だし。
バックアップが楽だから。
以前某メーラーを作ってるときは、それ用のFrameworkも ~/Frameworks に入れてた。
使い方にも ~/Frameworks を作ってそこに入れろって書いたし。
管理者でなくても投入可能なのがいいよね。
>>206
いまいち意味が分からんが。
管理権限がある他のユーザーが勝手に(/Applicationsに)アプリを追加するなら、それは管理権限を与えたやつが馬鹿なだけ。
管理権限がない他のユーザーが勝手に自分のスペースにアプリを追加しても別に問題ないんじゃないの？
って、俺と梨はそれほど意見がずれてないような気がするぞ。
梨は単にフォルダの名前にこだわってるだけか？
それともベンダーとサードパーティーのフォルダが別なのが気に食わない？
いまいち意味が分からんが。
管理権限がある他のユーザーが勝手に(/Applicationsに)アプリを追加するなら、それは管理権限を与えたやつが馬鹿なだけ。
管理権限がない他のユーザーが勝手に自分のスペースにアプリを追加しても別に問題ないんじゃないの？
って、俺と梨はそれほど意見がずれてないような気がするぞ。
梨は単にフォルダの名前にこだわってるだけか？
それともベンダーとサードパーティーのフォルダが別なのが気に食わない？
>>207
デフォルトのユーザが管理者権限を常時行使していて、
(/Applicationsに)アプリを追加するのが馬鹿だなあと思っただけ。
漏れもやってるけどさ。
>>205に対して言うならば、Library 群だけじゃなくて、
個人の扱うファイルはすべて別ディレクトリにした方が良いって意見さ。
管理者ならともかく、ユーザがした行動のせいでシステムが不安定になったり、
OSの再インストールが必要になる事自体、大きく間違っていると思うのだが。
管理権限を常時行使していないとまともに使えないというOSのつくりを改善すべき。
デフォルトのユーザが管理者権限を常時行使していて、
(/Applicationsに)アプリを追加するのが馬鹿だなあと思っただけ。
漏れもやってるけどさ。
>>205に対して言うならば、Library 群だけじゃなくて、
個人の扱うファイルはすべて別ディレクトリにした方が良いって意見さ。
管理者ならともかく、ユーザがした行動のせいでシステムが不安定になったり、
OSの再インストールが必要になる事自体、大きく間違っていると思うのだが。
管理権限を常時行使していないとまともに使えないというOSのつくりを改善すべき。
スレタイに沿って理想を述べるなら、
一般ユーザが操作した、システムその他すべての差分データを
「ユーザー」の専用ディレクトリに格納する事にして、
管理者はOSの安定化と、「標準的なユーザ」の専用ディレクトリのメンテをすればいい。
簡単な例で言うと、VPCの「取り消し可能ディスク」機能みたいなもん。
管理者の仕事は、まっさらなOS環境を用意する事と、
みんなが絶対に使うアプリをインストールしたユーザを作っておくこと。
ユーザは、管理者の作った環境を使って独自にPCを使い、
管理者の用意したシステムとの差分をディスクに書き込んでいく。
ローカルユーザは自分でインストールしたハードウェアを制御する権限も持つ。
ユーザのデータに問題があれば、ユーザの環境ごと削除してしまえば、
OS自体は（管理者が想定する程度には）綺麗な状態に戻るってわけ。
で、最後の「ユーザの環境ごと削除する」って動作を簡単にするために、
すべての差分データは一つのディレクトリにまとまっておく必要があるわけさ。
一般ユーザが操作した、システムその他すべての差分データを
「ユーザー」の専用ディレクトリに格納する事にして、
管理者はOSの安定化と、「標準的なユーザ」の専用ディレクトリのメンテをすればいい。
簡単な例で言うと、VPCの「取り消し可能ディスク」機能みたいなもん。
管理者の仕事は、まっさらなOS環境を用意する事と、
みんなが絶対に使うアプリをインストールしたユーザを作っておくこと。
ユーザは、管理者の作った環境を使って独自にPCを使い、
管理者の用意したシステムとの差分をディスクに書き込んでいく。
ローカルユーザは自分でインストールしたハードウェアを制御する権限も持つ。
ユーザのデータに問題があれば、ユーザの環境ごと削除してしまえば、
OS自体は（管理者が想定する程度には）綺麗な状態に戻るってわけ。
で、最後の「ユーザの環境ごと削除する」って動作を簡単にするために、
すべての差分データは一つのディレクトリにまとまっておく必要があるわけさ。
擦れたいに沿っていろいろ考えた結果、いきなり方向転換するぞ（w
>>209は管理者の思う理想ではあるけど、ユーザーにとっての理想ではないと思うんだよね。
ユーザーは管理者なんて言う面倒な存在がない方が楽だもん。
OSやソフトのインストールなんて面倒だもん。
OS なんて得体の知れない物はエーテルにでも載せて全宇宙に配信してどこからでもいつでもOSが使えるようにしてほしいもんだね。
起動すればそこには最新もしくは最適のOSが走ってる。
コンピュータの管理なんかコンピュータがやってくれればいい。
使いたいソフトだけが存在し、使いたいときにだけに存在する。
って考えていくと理想のUIって結局 HAL になっちゃうのかなと思ってくる。
前に出過ぎでもなく、後に下がり過ぎでもない。と俺は思うんだけどね。最後はあれだけど。
と、嫌々ながら実質上管理者になってる実際的会社員の妄想をお送りいたしました。（w
あっ。100年後の標準UIがちぃではないことを祈る。
あれは前に出過ぎの上に後に下がり過ぎだ。（w
>>209は管理者の思う理想ではあるけど、ユーザーにとっての理想ではないと思うんだよね。
ユーザーは管理者なんて言う面倒な存在がない方が楽だもん。
OSやソフトのインストールなんて面倒だもん。
OS なんて得体の知れない物はエーテルにでも載せて全宇宙に配信してどこからでもいつでもOSが使えるようにしてほしいもんだね。
起動すればそこには最新もしくは最適のOSが走ってる。
コンピュータの管理なんかコンピュータがやってくれればいい。
使いたいソフトだけが存在し、使いたいときにだけに存在する。
って考えていくと理想のUIって結局 HAL になっちゃうのかなと思ってくる。
前に出過ぎでもなく、後に下がり過ぎでもない。と俺は思うんだけどね。最後はあれだけど。
と、嫌々ながら実質上管理者になってる実際的会社員の妄想をお送りいたしました。（w
あっ。100年後の標準UIがちぃではないことを祈る。
あれは前に出過ぎの上に後に下がり過ぎだ。（w
>>210
「最適」は人それぞれだし、
理解の無い物ほど他人（人である事に注目）がやってくれる事を期待されるものだ。
もちろん、ある程度自律した管理が標準である方がいいんだけどね。
「管理者」が楽できるから。
ちぃは女型だから許せるんだろうな、と思う。
「最適」は人それぞれだし、
理解の無い物ほど他人（人である事に注目）がやってくれる事を期待されるものだ。
もちろん、ある程度自律した管理が標準である方がいいんだけどね。
「管理者」が楽できるから。
ちぃは女型だから許せるんだろうな、と思う。
212 ：たかちゃん ◆aYYJ4NEyLs ：04/12/01 00:27:31
突然、遅レスー。
homeディレクトリーに「Applications」フォルダを作ると
ユーザー固有のアプリを格納するフォルダになるんよん。
MacOS X Serverとかだと、/Applicationsは一般権限ユーザの
アプリｲﾝｽｺは禁止にして、最初から~/Applicationsを
新規ユーザー登録時に作成するとかできんじゃないのかなー？？
（MacOS Xでも、できそうな感じではあるけどねえ）
「システムその他の差分」ってのは、それこそ「~/Library」に
入ってんじゃないの？ そーゆーことでなく？？
~/Libraryにタブレットドライバを入れてしまったことがあって
他のユーザに切り替えたら、全くタブレットが使えないので壊れたのかと
思った事があるよー(w
homeディレクトリーに「Applications」フォルダを作ると
ユーザー固有のアプリを格納するフォルダになるんよん。
MacOS X Serverとかだと、/Applicationsは一般権限ユーザの
アプリｲﾝｽｺは禁止にして、最初から~/Applicationsを
新規ユーザー登録時に作成するとかできんじゃないのかなー？？
（MacOS Xでも、できそうな感じではあるけどねえ）
「システムその他の差分」ってのは、それこそ「~/Library」に
入ってんじゃないの？ そーゆーことでなく？？
~/Libraryにタブレットドライバを入れてしまったことがあって
他のユーザに切り替えたら、全くタブレットが使えないので壊れたのかと
思った事があるよー(w
ところで、この1年間の間にMacOSのUIってなんか進化しましたか?
おれ、いまだに9er兼8er継続中でXへの移行がまだなのでぜんぜん状況がわかりません
おれ、いまだに9er兼8er継続中でXへの移行がまだなのでぜんぜん状況がわかりません
215 ：●~*：2006/03/13(月) 21:26:07
1年で変わるわけないだろ
意味不明
昨年から今年にかけて劇的に進化しました。
って書いたら信用するのかな？しないよね、ソースないし。
って書いたら信用するのかな？しないよね、ソースないし。
218 ：●~*：2006/08/06(日) 14:15:31
でさ、いつになったら直接思考をコンピュータに接続できるようになるんだ？
219 ：（ﾟ∞ﾟ ） ：2006/09/30(土) 18:24:58
＞ゴミ箱
液晶の右端、が透けていて実際に後ろの汚いデスクが見える。
そこにゴミを指で弾き飛ばす。
とか
マウスが無くなった前提で言ってみるﾃｽﾄ。
何だか、Win95から使っていて私はゴミ箱を意識したことが無い、
所詮形だけのﾓﾉだからか。
多分関連がファイルとフォルダしか無いから実際必要ない機能なのだろう。
Shift + Delで大体消す。 （そして後で慌てる）
正直、絵と名前を関連させても現実との関連は実際薄い気がする。
遅レス上等
液晶の右端、が透けていて実際に後ろの汚いデスクが見える。
そこにゴミを指で弾き飛ばす。
とか
マウスが無くなった前提で言ってみるﾃｽﾄ。
何だか、Win95から使っていて私はゴミ箱を意識したことが無い、
所詮形だけのﾓﾉだからか。
多分関連がファイルとフォルダしか無いから実際必要ない機能なのだろう。
Shift + Delで大体消す。 （そして後で慌てる）
正直、絵と名前を関連させても現実との関連は実際薄い気がする。
遅レス上等
ゴミ箱なぁ
右クリックで削除を常用してるんだが、いつの間にか中身が膨れ上がってなぁ
Macの見たいに見た目が変化すれば良いのに
右クリックで削除を常用してるんだが、いつの間にか中身が膨れ上がってなぁ
Macの見たいに見た目が変化すれば良いのに
ゴミ箱のグラフィックは変化しますがなにか？
ｇｔｈｒｔ
223 ：●~*：2007/10/16(火) 09:27:19
mac最高
224 ：N：2008/02/12(火) 22:35:31
梨が戻ってきているみたいなんであげてみる
ちょうど三連休からこの後に及んでメインマシンのWindowsを2000からXPにしたんだが
LUNAが耐えられないので切って使ってるんだな
正直自分でも何が嫌なのか分からないんだけどね
ちょうど三連休からこの後に及んでメインマシンのWindowsを2000からXPにしたんだが
LUNAが耐えられないので切って使ってるんだな
正直自分でも何が嫌なのか分からないんだけどね
３年もXP使ってるのにLUNAがなんだか分からなかった俺様が通りすがりに独り言。
最初からLUNAなのでXPってそういうものだと思ってたけど
デスクトップにはマイコンピュータとマイドキュメントとよく使うアプリのショートカットがあり、
フォルダ表示はクラシック表示。コントロールパネルのグループ分けなんぞ全く訳分からん。
あとデスクトップピクチャーはOSXのLadyBugにしてる。Windows標準のピクチャーってなんか見づらくね？
LUNAって便利な機能もあるんだろうけどなんか余計なお世話っつーか
使いやすくするつもりで逆に訳分からんくなってる部分も多いと思う。
最初からLUNAなのでXPってそういうものだと思ってたけど
デスクトップにはマイコンピュータとマイドキュメントとよく使うアプリのショートカットがあり、
フォルダ表示はクラシック表示。コントロールパネルのグループ分けなんぞ全く訳分からん。
あとデスクトップピクチャーはOSXのLadyBugにしてる。Windows標準のピクチャーってなんか見づらくね？
LUNAって便利な機能もあるんだろうけどなんか余計なお世話っつーか
使いやすくするつもりで逆に訳分からんくなってる部分も多いと思う。
>>225
このスレを開いた途端、漏れってタイムスリップしたかもって思ったｗｗｗ
このスレを開いた途端、漏れってタイムスリップしたかもって思ったｗｗｗ
なんだかんだいって旧MacOSの画面は迷う要素が少ないという点において優れていたと、全アプリ最大化表示でWindows2000を使う俺は思うのだ
UIなんか無駄に重かったり無意味に画面を占有したりしなければ何でも良いよ
>>228
画面に映るものだけがUIだと思ってる？
画面に映るものだけがUIだと思ってる？
どこをどう読んだらそう言うレスになるのやら
>>228
だったら、シングルユーザモードのコマンドラインインタフェースでいいじゃん
だったら、シングルユーザモードのコマンドラインインタフェースでいいじゃん
BeOSが良かった
>>232
どんなところが？
どんなところが？
>>233
今までで一番インストールが楽なOS
今までで一番インストールが楽なOS
そうか、もうBeOSを知らない世代がいるのか...
>>236
知らないっーか、7500じゃ動かなかったのよ
知らないっーか、7500じゃ動かなかったのよ
>>239
技術的にすごいのはわかるけど、今でもムービー複数同時再生とかしないし、実用的にはあまり変わりない気もする
技術的にすごいのはわかるけど、今でもムービー複数同時再生とかしないし、実用的にはあまり変わりない気もする
>>240
ニコ動やつべで二窓再生とかしない？
ニコ動やつべで二窓再生とかしない？
ニコ厨うぜぇwww
243 ：●~*：2008/07/03(木) 00:45:31
『TV=見ているだけ、電話=話すだけ』だから、1世紀近く経っても使われ続けている。
一方、PCは操作手順が多すぎて、細かいアイコンを探すだけでもストレスが溜まる。
なぜPcは電源を切るのにアイコンを何回もクリックしなければいけないのか、
なぜPcは電話をかけるように目的のソフトを呼び出せないのか、
はっきりって問題だらけのPCが(少なくとも今の形では)これ以上普及するはず無いね。
一方、PCは操作手順が多すぎて、細かいアイコンを探すだけでもストレスが溜まる。
なぜPcは電源を切るのにアイコンを何回もクリックしなければいけないのか、
なぜPcは電話をかけるように目的のソフトを呼び出せないのか、
はっきりって問題だらけのPCが(少なくとも今の形では)これ以上普及するはず無いね。
244 ：●~*：2008/07/03(木) 01:13:04
まあ汎用の機械だから仕方ないよね
最近のPCは電源切らないのが普通みたいな部分もあるし
つーか最近のHDDレコーダーとかPCよりわけわかんねえよ
あれでよく家電屋で売るもんだね
最近のPCは電源切らないのが普通みたいな部分もあるし
つーか最近のHDDレコーダーとかPCよりわけわかんねえよ
あれでよく家電屋で売るもんだね
メニューで選んだあと二分待てば勝手に切れるMacの方が幾分ましかな
ターミナルからsu shutdown -h nowすれば一発かと思ったけどだめか
ターミナルからsu shutdown -h nowすれば一発かと思ったけどだめか
∧∧
. (*ﾟーﾟ)つ shutdown -s -f -t 0
sudo shutdown -h now
その前に
sudo shutdown -h now
って打ってるから（ｗ
sudo shutdown -h now
って打ってるから（ｗ
どういうこと？
ドックにshutdownとrestartのアップルスクリプトを置いてる俺は１クリックで終了するよ。
共有マシンで他にログインユーザーが居るときに
パスワード入力とか一切無しで電源切れるように出来ませんかね
パスワード入力とか一切無しで電源切れるように出来ませんかね
>>252
電源引っこ抜けば？
電源引っこ抜けば？
●~*
●~*
アタイこそが２５６へと～
結局のところ最新 OS X のGUIが最良
最近、Mac使ってないなあ
>>252
もっと穏やかな方法ありませんかねぇ
もっと穏やかな方法ありませんかねぇ
260 ： 忍法帖【Lv=40,xxxPT】(1+0：8) 【20.7m】 電脳プリオン ◆3YKmpu7JR7Ic ：2012/11/04(日) 19:05:18.72 BE:243245546-PLT(12079)
261 ：●~*：2013/01/11(金) 00:37:30.07
で？
262 ：●~*：
★★★チベットの独立は日本の核心的利益である★★★
http://jbbs.livedoor.jp/bbs/read.cgi/study/3729/1226114724/78
￥￥￥￥￥￥￥『万有サロン』書き込み大賞・総額100万円￥￥￥￥￥￥￥￥￥￥￥￥
この掲示板に優秀な書き込みをして、総額100万円の賞金をゲットしよう！(*^^)v
万有サロン
http://jbbs.livedoor.jp/study/3729/
書き込み大賞の詳細
http://jbbs.livedoor.jp/bbs/read.cgi/study/3729/1069922074/78-
書き込み大賞の詳細(資料倉庫内)
http://www2.tba.t-com.ne.jp/a-z/omake/banyu/taisho.htm
また、あらゆる疑問に関する質問を、携帯電話やメールでも受け付けています。
電話番号 080-4437-4187
メール [email protected]
￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥
http://jbbs.livedoor.jp/bbs/read.cgi/study/3729/1226114724/78
￥￥￥￥￥￥￥『万有サロン』書き込み大賞・総額100万円￥￥￥￥￥￥￥￥￥￥￥￥
この掲示板に優秀な書き込みをして、総額100万円の賞金をゲットしよう！(*^^)v
万有サロン
http://jbbs.livedoor.jp/study/3729/
書き込み大賞の詳細
http://jbbs.livedoor.jp/bbs/read.cgi/study/3729/1069922074/78-
書き込み大賞の詳細(資料倉庫内)
http://www2.tba.t-com.ne.jp/a-z/omake/banyu/taisho.htm
また、あらゆる疑問に関する質問を、携帯電話やメールでも受け付けています。
電話番号 080-4437-4187
メール [email protected]
￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥