5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

理想的なUI【ユーザインタフェース】を考える

1 ::02/09/29 13:23
単刀直入に、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/


148 :75:03/05/02 16:18
>>146
リソースは有効に使ってほしいのは確か。

>ここにも「さまざまな形式をサポートする」事の弊害があるような。
ソースやバイナリのパッケージが開けるという話しで
規格乱立という感じじゃないな。指摘の通り、しっかりした
GUIを備えている訳でもなさそう。

主流としては標準インストーラのpkg形式かViseだと思う。
それと1個の実行ファイルのように振舞うパッケージフォルダ式。

ふと思い付いたので、本来のUI話に戻るけど。
ファイルの保存・開くも、パッケージフォルダで指定するように
するというのは、どうかなと思ったり。

データの保存履歴や属性とかのカタログインデックスを
パッケージ内に置いておいて、ユーザーはもっと抽象的な指
定でOS側が分別してデータを出し入れするようにするとか
できないのかな?

149 ::03/05/02 16:29
>>148
だから、パッケージに埋めたらマルチユーザが(ry

設定ファイルは所定のフォルダに入れないとだめかなーと。


150 :●~*:03/05/02 17:22
アップルから提示されている設定の保存は、NSUserDefaultsを使用する方法のみです。

あと、ほかの場所がないか探してたらこんなの見つけました。

>Your application should never write user-preference data inside the application package.

このあとに余計なことせずにNSUserDefaultsかCFPreferences使え、ボケ!って書いてます。
CFPreferenceは現在NSUserDefaultsがホスト単位での設定をサポートしていないための逃げ口です。

//以下余談
CFPreferencesを使うと
現在のホスト上の現在のユーザー
特定のホスト上のすべてのユーザー
すべてのホスト上の現在のユーザー
すべてのホスト上のすべてのユーザー
という場合わけが出来るようです。


151 :あぼーん:あぼーん
あぼーん

152 :あぼーん:あぼーん
あぼーん

153 :あぼーん:あぼーん
あぼーん

154 :あぼーん:あぼーん
あぼーん

155 :●~*:03/05/02 21:36
他人が見て面白いことを書きましょう。大勢の読者がいることを意識してください。
 

156 :●~*:03/05/02 22:11
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨U梨梨梨梨梨梨梨梨梨梨梨環‥‥‥‥
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨U梨梨梨梨梨梨梨梨梨梨梨梨鍋‥‥‥
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨U梨梨梨梨梨梨梨梨梨梨梨梨梨狂‥‥
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨U梨梨梨梨姉梨梨梨梨梨梨梨梨梨マ‥
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨環朕姉梨梨梨梨梨梨梨梨梨梨梨梨梨朕‥
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨狂鍋鍋鍋鍋梨梨梨梨梨梨梨梨梨梨梨梨梨狂
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨狂狂狂狂狂狂狂マ狂梨梨梨梨梨梨梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨マ狂狂狂ママママママママ狂梨梨梨梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨ママママママママママママ狂狂梨梨梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨狂ママママママママママママ狂狂狂梨梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨狂狂狂マママママママママママ狂狂鍋梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨マ狂狂狂マママママママママママ狂鍋姉梨姉姉姉梨
梨梨梨梨梨梨梨梨梨梨梨梨梨狂狂狂狂狂鍋姉姉朕環鍋狂マママ狂鍋朕梨梨梨梨姉梨
梨梨梨梨梨梨梨梨梨梨梨狂狂狂狂鍋環姉梨梨姉朕環環鍋狂狂狂狂鍋鍋環朕朕姉梨梨
梨梨梨梨梨梨梨梨梨梨狂狂狂狂朕姉朕環鍋狂狂狂狂狂鍋鍋鍋鍋鍋鍋狂狂マ狂鍋環梨
梨梨梨梨梨梨梨梨梨狂マママ鍋環狂ママママママ狂狂鍋鍋鍋鍋鍋狂狂狂マ狂鍋鍋梨
梨梨梨梨梨梨梨梨狂狂マママ狂狂ママママママ狂鍋鍋狂狂狂狂狂狂鍋鍋姉姉環環姉
梨梨マ梨梨梨梨狂狂狂マママママママ狂狂環環環環鍋狂ママ狂狂狂鍋マ梨梨梨環朕
梨狂梨梨梨梨朕狂狂狂マママママママ姉鍋鍋梨梨朕鍋マママ狂鍋狂鍋鍋環環環環環
梨マ梨梨梨梨姉鍋狂ママママママ鍋鍋鍋マ狂狂鍋鍋狂ママママ鍋狂狂狂鍋鍋狂狂鍋


157 :●~*:03/05/02 22:12
梨鍋梨梨梨梨梨鍋狂マママママママ…ママ狂狂狂ママママママ狂鍋狂マ狂狂狂マ狂
梨梨環梨梨梨梨鍋狂狂狂ママママママママママママママママママ鍋鍋狂ママママ鍋
梨梨麻梨梨梨梨環狂狂狂狂マママママママママママママママママ鍋鍋狂ママママ鍋
梨梨行梨梨梨梨朕鍋狂狂マママママママママママママ鍋狂ママ…マ鍋鍋ママママ狂
梨梨麻梨梨梨梨朕鍋狂狂マママママ……マママママ狂ママ……ママ鍋鍋狂マママ狂
梨梨梨梨梨梨姉鍋鍋狂狂ママママママ…ママママ狂鍋ママ狂狂鍋環朕環鍋狂狂マ鍋
梨梨梨梨梨梨鍋狂狂狂ママママママママママ狂狂狂鍋鍋環狂鍋朕姉朕鍋鍋鍋狂狂鍋
梨梨梨梨梨梨梨梨梨梨マママママママママ狂狂狂ママママ狂狂狂鍋鍋鍋鍋鍋狂狂鍋
梨梨梨梨梨梨梨梨梨梨ママママママママ狂狂狂マ梨梨梨梨狂梨梨梨梨梨梨鍋狂鍋狂
梨梨梨梨梨梨梨梨梨梨梨ママママママママ狂梨梨狂マママ狂狂鍋環朕朕環梨梨環マ
梨梨梨梨梨姉鍋梨梨梨梨梨梨ママママママ梨鍋環環鍋鍋鍋鍋環環朕梨梨環狂梨梨‥
梨梨梨梨梨環環梨梨梨梨梨梨マママママ梨梨狂姉梨環鍋ママ狂狂朕姉朕狂狂梨梨‥
梨梨梨梨梨環朕環梨梨梨梨梨梨梨マママ梨梨狂鍋鍋鍋鍋鍋鍋鍋環朕環鍋狂鍋梨梨‥
梨梨梨梨梨姉環環梨梨梨梨梨梨梨梨梨梨梨マ狂ママ狂狂狂鍋鍋鍋環朕鍋鍋環梨‥‥
梨梨梨梨環梨環環梨梨梨梨梨梨梨梨梨梨梨狂狂マママ狂狂鍋環環環鍋鍋梨梨マ…‥
梨梨梨梨姉梨鍋環梨梨梨梨梨梨梨梨梨梨梨梨梨マママママ狂狂狂狂狂梨梨梨梨……
梨梨梨朕梨梨環環環梨梨梨梨梨梨梨梨梨梨梨梨梨ママママママママ狂鍋梨梨梨梨…
狂姉梨環姉梨環環環梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨姉姉鍋マ…
梨梨姉朕姉梨朕環環梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨鍋…
梨梨姉姉朕姉姉環環鍋環梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨姉梨梨梨梨姉梨梨鍋
梨梨梨梨環梨梨姉環環鍋鍋梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨
梨梨梨梨朕梨姉梨環鍋鍋鍋狂狂梨梨梨梨梨梨姉梨梨梨梨梨梨梨梨梨梨梨梨梨姉梨梨


158 :●~*:03/05/02 22:57
あらら、旧板のレス止まってしまったじゃないのw
>>157
みんな気が小さいんだから、荒らしと間違われるよ

159 :●~*:03/05/02 23:15
フォントを小さくしてやっと見えた。
で、誰の顔?

160 :●~*:03/05/02 23:17
こうするとかちゅーしゃではちゃんとみられるかな?
>>156
>>157
力作だけどキモーかなぁ…

161 :●~*:03/05/02 23:18
損し?と思われ。

162 :●~*:03/05/02 23:29
>>156,157

163 :●~*:03/05/02 23:30
>>156-157
こうか?

164 :●~*:03/05/02 23:37
>>163 正解みたいです、スマソ。

165 :●~*:03/05/06 08:53
梨がたぶん勘違いしてるのでひとつ。

バッケージってのは、ひとつのフォルダに関連性のあるファイルが詰め込まれているものの総称で、
アプリケーションパッケージはそのひとつ。
フォルダにパッケージフラグが立ってればFinderは内容がどうあれパッケージとして扱う。
確か、rtfdっていう、rtfを文章、画像等に分けて、パッケージ化したフォーマットがあったはず。

だから多分>>148さんが後半で言ってるのは書類パッケージがあれば面白いんではないか、ということだと思う。


166 :75:03/05/06 12:53
>>165
パッケージ化されてるアプリって、中にバイナリファイルがある訳だ。
パッケージをダブルクリックすると、そいつが起動する仕組みだよね。

例えばね。
書類パッケージの中にデータを加工したアプリをカタログファイルの
ようなものに記述してパッケージ内に置いておく。

書類パッケージをダブルクリックしたら、指定のアプリを起動する。

「最終更新のデータ」「ユーザー◎◎が加工したデータ」「M月D日以降のデータ」とか
(メールソフトの「ルール」に近い感じで)カスタマイズ可能な複数の項目で検索する
ダイアログを出して、ファイルを特定。

確認ダイアログは必要かどうかはともかく、それでファイルを開く。

保存に関しては「別名で保存」「複製を保存」とか、ファイルを別途に新規作成する
場合も、カタログファイルに、検索に必要な項目を予め書き加えておくようにすれば
ユーザーが敢えてファイル名を考える必要もないと思う。

……なんて、妄想してみたのだけどね。

167 :●~*:03/05/12 01:29
>>166
たとえば、クォークで出力する場合に、必要な書類を一つにまとめる。
クォーク、イラストレーター、フォトショップ書類が混在していて、
ダブルクリックでクォーク書類のみ選択される(クォーク書類のみ開く)
ルールを決めたパッケージとか、DTPに特化して便利になりそう。
書類のリンクチェックとかもパスの部分を読んでやってくれるとなお便利。

168 :75:03/05/12 10:12
>>167
うん。そうそう、便利だと思うんだけどね。

問題は、必ず「どういったルールでパッケージ内を検索して
対象ファイルを特定するか」というダイアログみたいなのが
パッケージ自体をダブルクリック(もしくはアプリにドラッグ&
ドロップ)した時に必要になってしまうのではないか、なんだよね。

今のように、ファイルをダブルクリックしたら対応してるアプリが
起動する、ってのと比べると見かけ上1段階手間が増える。
「そのファイルがあるフォルダを開いて、目的のファイルを見つける」と
いう作業自体もコミコミなので、実際のところは手間は増えて
ないんだけど。

先にアプリを起動しておいて「ファイル」→「開く」とかやる場合は
手間は同じだけどね。

>書類のリンクチェックとかもパスの部分を読んでやってくれるとなお便利。

この辺は、DTP、Webサイト構築、プログラム開発のライブラリ依存関係
MP3のプレイリスト、ビデオ編集、3D CGのレンダリング等々、チェック機構を
汎用的な形にして、用途に合わせてテンプレをカスタマイズするとか
プラグイン形式にするとか、できたらカナーリ便利だよね。

っつうか、そういうチェック機能つきランチャーとか誰か作っておくれよ。


169 :167:03/05/13 03:35
>>168

> 問題は、必ず「どういったルールでパッケージ内を検索して
> 対象ファイルを特定するか」というダイアログみたいなのが
> パッケージ自体をダブルクリック(もしくはアプリにドラッグ&
> ドロップ)した時に必要になってしまうのではないか、なんだよね。

いや、ここで提示したのは最終的に相手に渡す手段としてのパッケージで。
htmlなら、index.htmみたいなのを起動させ、他の書類はそこからリンクしているだけ、
DTPなら、出力書類のみが選択されるってのを想定した。
制作段階ではパッケージしないわけ。
パッケージのメリットは不必要なファイルにユーザーが触れないことだと思う。

> >書類のリンクチェックとかもパスの部分を読んでやってくれるとなお便利。
>
> この辺は、DTP、Webサイト構築、プログラム開発のライブラリ依存関係
> MP3のプレイリスト、ビデオ編集、3D CGのレンダリング等々、チェック機構を
> 汎用的な形にして、用途に合わせてテンプレをカスタマイズするとか
> プラグイン形式にするとか、できたらカナーリ便利だよね。
>
> っつうか、そういうチェック機能つきランチャーとか誰か作っておくれよ。

さすがにそれを網羅したアプリは……
でも、それをOS標準で付けたらすごいかも。
パッケージ化の時にプラグイン形式でチェックできるようにし、付加価値を高める。

170 :75:03/05/13 09:56
>>169
ああ、なるほどね。理解しますタ。IEのWebアーカイブ形式とかも
結構、近い感じかな。

話を少しだけ戻すと……
実際、1つの制作物(俺の場合はイラストとかなんだが)フォルダの中に
データが複数あった場合、どのくらい作業をした時点で保存したか
ファイル名と修正日で、だいたい見当がつく?

最初のウチは無問題なんだけど、ファイルが何十個にもなって
子フォルダで分類しても、納期間際の土壇場になってくると
段々ワケワカラン状態に……(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にも変換してくれる。
そんなツールを標準装備してくれたらいいなあ。
な〜んて思っちゃったりなんかして。

172 :75:03/05/20 01:24
>>171
オカエリナサイ。

>ううむ、それはカタログソフトでなんとかなるようなw
扱ってるファイルサイズが大きいので、カタログ化するにしても時間がかかるし、
サムネール表示だと差異もわかりづらい。ちょっと前に幾つか導入してみたんだけど
しっくり来るカタログソフトがなかったんだよね……最新のだと具合が良いのがあるかも
しれんけど。

>OSが作業中の物はpsd、納品物はtiffやpng、jpegにした場合にフィルタリングしてくれると、助かるとも思うけど。
禿同。まさにOSの方にアプリごとにフィルタリング条件を登録できるようになっていれば
イイと思う。
実際のところパッケージフォルダでなくて、任意に指定したフォルダでも良いんだしね。

PSDとかだと「ファイル情報」とかあるけど、あれで検索できると大分違うんだけどな。
(あとは、レイヤーの枚数とかね)

173 :山崎渉:03/05/22 01:54
━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━―

174 :167:03/05/25 02:50
>扱ってるファイルサイズが大きいので、カタログ化するにしても時間がかかるし、
>サムネール表示だと差異もわかりづらい。
つまり、「目視確認」は無理ってことか……OSXのアイコン最大表示への感想希望。

ウインドウ表示に「アイコン」てあるでしょ。それがより、拡張されたもの……
ファイルビューとしては、リスト表示、カラム表示・エクスプローラタイプ最強。
でも、75さんみたいに、ファイル名、ファイルタイプ、容量、修正日に縛られないルール付けもほしい。

ふと思ったけど、「アイコン」「リスト」「カラム」以外の表示方法がオンラインウェアのプラグインで
拡張できるようにならないだろうか。
それこそ、プレビューソフトの代替として。
アイコン表示なのに、その下に任意のファイル情報が表示できる、なんて感じで。
あと、「修正日」「ファイル表示」以外に「レイヤー情報」なんかを認識するプラグイン必須。
それとは別に、現在ファイル保存時に狭いダイアログにフォルダが表示されて、ユーザーは名前だけ決める。
そうじゃなくて、アイコン表示の画面になり、保存する座標を決められたならば、アイコン表示はもっと良い物に。

あとやっぱり、「特定フォルダのPSDを別フォルダにTIFFで抽出してまとめる」てやってくれAPPLE。
たぶん、写真屋のバッチ処理よりネイティブなので早いはず(想像)

175 ::03/06/29 13:41
あ。最近考えてた事と被るなあ。

>>165-174
「ファイルからいかに情報を集めるか」
「ファイルにいかに多くの情報を記録するか」
というのは、今後のファイルシステムが検討すべき課題だけど、
実は単にデータフォークとリソースフォークに分ければ済む話だと思う。

情報はXML(MSSQLでもいいけどさ)に保存して対応づけて、
UIがXMLに対応すれば、それらの情報表示も出来る事になるね。
検索はテキスト全文検索があればいいわけだし。

で、それらの情報を包有する「モダンファイル構成」を、
パッケージ形式で提供すれば良い。

ということだよね?


176 :あぼーん:あぼーん
あぼーん

177 :あぼーん:あぼーん
あぼーん

178 ::03/06/29 13:55
>>166
パッケージが独自のバージョン管理レイアを持つ形になるよね。

>>167
いわゆるWebアーカイブの発想よね。って下で書かれているけど。

>>168
現行のUIに呼応させるなら、
最後に使ったファイルとアプリを覚えておいてそれを呼び出す形かな。

>>169
リンクチェックの汎用化は難しいでしょう。
労力のわりに意義のある統一とは思えないなあ。
ファイルのリンク管理の部分だけ情報を二重化する形なら可能かな。

>>170
パッケージが外部アプリのコンバータを利用出来るという前提なら、
コンバートすれば出力出来るものは「キャッシュ」とみなせるよね。
足りないものは都度「コンバート」して、
速度が必要なら「キャッシュ」を使えば、メタな扱いは出来るのでは。

>>171
「作業用」パッケージを「納品」アイコンにドラッグするとかは?
個人的には右クリックが一番いいんだけど。
「キャッシュ」として考えるなら、
フィルタリングでは無く「抽出」のような気もする。
って、>>174に書いてあったね。

なんか、漏れが話せば話すほど、
UIではなくAPIの話になっていくような。。。


179 :167:03/07/01 01:34
>>175
>で、それらの情報を包有する「モダンファイル構成」を、
>パッケージ形式で提供すれば良い。

結局そうなるのかな?
パッケージ内で雑多に同時進行するファイルをOS標準の何か(って何だ)がうまく管理し、ユーザーはパッケージのみを大雑把に管理する、と。

「でもそれってもう新しいアプリケーションを開発して1ファイルにしてOKじゃ?」とも思うが、実際はファイル損傷のリスクとか、他のプロジェクトで流用するケース、DTP←→HTMLとかで、抜き出す手間を考えるとパッケージの佳さがあると思う。
Wordに埋め込まれた高解像度ビットマップ画像を抜き出したことがあるが、大変だった。

>>178
>リンクチェックの汎用化は難しいでしょう。
>労力のわりに意義のある統一とは思えないなあ。

とりあえず、「シリアルが必要」「やたら重たい」イラレを立ち上げずにリンクチェックできるソフトはあって、そこそこ重宝している。シンプルにチェックのみできるし。
……思うんだが、アプリケーションと書類の相互依存性を、現在のWINの「関連づけ」、Macの「クリエータ」がサポートしている。
同じように、書類同士の依存関係をOSがサポートしてほしいな。上のアプリが必要無いくらいに。

>ファイルのリンク管理の部分だけ情報を二重化する形なら可能かな。
妄想が入るけど、DTPアプリが共有して使うリソースフォークだったらMacは天下泰平だった……
う〜ん、しかしリソースってのはナイスなアイディアかも。

>「キャッシュ」として考えるなら、
>フィルタリングでは無く「抽出」のような気もする。
それで言い直した訳ですわ。相手には必要なデータのみ渡したいね。

180 ::03/07/01 23:24
このスレはコンセンサスまでが早くて気持ちいいな。

>>179
> 書類同士の依存関係をOSがサポートしてほしいな。

仮に二重化するなら、
「どのファイルがどのファイルに依存しているのか」をOSが別途管理。
管理するために、所定のフォーマットから「抜き出す」のは力業で対応。

参照カウンタみたいな概念があれば実は成り立つのかも。
きっとその世界では、すべてのファイルはディレクトリでもあるんだろうね。
相互参照はどうするんだ、とか一瞬思ったけれど。

真面目にやるなら、
「どのファイルの」「どの部分に」「どのような形で」
リンクしているのかをOSが汎用化した上で持たなければならない。

この「汎用化」ってのがいまいちピンとこないんだよな。
クリップボードの内容を別のアプリに切り貼りする事に似ているかも。
「OSの機能を使う」とはいっても、疲れるのは結局アプリという罠。


181 :あぼーん:あぼーん
あぼーん

182 :167:03/07/02 00:41
>>180
> 真面目にやるなら、
> 「どのファイルの」「どの部分に」「どのような形で」
> リンクしているのかをOSが汎用化した上で持たなければならない。
>
> この「汎用化」ってのがいまいちピンとこないんだよな。
> クリップボードの内容を別のアプリに切り貼りする事に似ているかも。
> 「OSの機能を使う」とはいっても、疲れるのは結局アプリという罠。

二重化したリンク情報は、OSが、リンクしているファイルの相関図、エリアマップみたいなものをパッケージ内の書類で提供するってのはどうだろう。
これって
> 参照カウンタみたいな概念があれば実は成り立つのかも。
で思ったんだけど。

アプリ側がOS側に申請すると他のアプリでも読み込める形式で、相関図を書く。
通常、リンクした複数ファイルってのは複数に枝分かれするような状態で、必ず親子の関係がある。
(DTPとかのリンクってのはHTMLのスタイルシート、プログラムでの個別のスプリクトみたいなものかな)
なので、かならず頭になる書類は強弱関係で導きだされる。

>この「汎用化」ってのがいまいちピンとこないんだよな。
でも、引用されている書類の形式によって、大体用途が限られていると思うんだよね。
ビットマップを引用して、音楽に変換するような酔狂なことをしない限りは。
パッケージをポンと他人に渡せるし、後で中身を他のアプリが容易に再利用できる橋渡しとして、リンク情報だけでも十分かなあと……。

ちょっとパッケージの話からそれるけど、最低でも今までの常識では「このファイルがこのファイルを欲しがっている」ことを知る方法はあったけど、その逆はなかった。
それがレベルの低い動作でできるようになったらかなりの進歩だと思うなあ。
Finderでゴミ箱に持って行ったり、引用されているファイルをうっかりいじってしまう前に、どういったファイルが引用しているか知らせて警告してくれたり。
そうしたら、僕はなんて親切なUIだろうって思うよ。
「ウザイ」って思う人はいるだろうけど、仕事がからむとまた別。

183 :●~*:03/07/02 07:32

●梨は、おそいCPUが大好き。
●梨は、低シェアPCが大好き。
●梨は、妄想が大好き。
●梨は、コピペが大好き。
●梨は、なりすましが大好き。
●梨は、9時と13時に書込むのが大好き。


184 :167:03/07/03 00:02
>>183
Finderで、使用中のファイルを捨てれなかったり、拡張機能などをシステムフォルダに重ねるとしかるべきところへ持って行ってくれる……。
これって親切だと思う。もちろん、拡張機能を好きなところに置くこともできる。この柔軟さ。

僕が182で書いているのは「強制的に捨てられない」ていうんじゃなくて、アップルイベントとして、
「このファイルを必要としているファイルがあるか?」
という問いにMacが 0/1 で答えてくる。というのを考えているんだよ。
物を創る人にとって本当に必要といえるOSであれば、実装して欲しいファイル管理だ。

僕はずっと「OSXでこんなUI、ユーザーのアクションに応える動作をしてくれたらなあ」という意見で一貫している。

おっと、騙りか……

185 ::03/07/03 15:43
一部省略。ごめんね。

>>184
インストールパッケージの依存管理と同じ概念なのかな?

> 「強制的に捨てられない」ていうんじゃなくて、
> 「このファイルを必要としているファイルがあるか?」
> という問いにMacが 0/1 で答えてくる。

それに対してとれる行動は、
・削除を中止する。(推奨)
・強制的に削除する。
というのでいいのかな?

OSXでは、ロックがかかったディレクトリは開くことが出来ないのね。
中のファイルを見るにはコンソールを使うか検索するしかない。不便だ。


186 :あぼーん:あぼーん
あぼーん

187 ::03/07/03 16:14
>>182
補足じゃなくてこっちにレスすれば良かった。

> 通常、リンクした複数ファイルってのは複数に枝分かれするような状態で、必ず親子の関係がある。
・リンクされないファイルも存在する。
・リンクされているファイル同士が対等に結びついている事は無い。
という事だよね。

それでいて、
・どのような内容でリンクされているかは考慮しない。
・リンク情報は親→子、子→親の両方を参照出来るようにする。
というわけだ。

なんか、自分で書いてて「循環参照はありうる」とか思ったけど、
まあ、それは置いておくとしたら、それなりに意義があるのかも。
ハードリンクの拡張みたいな位置づけになるのかなあ。


188 :167:03/07/04 01:17
>>187
> ハードリンクの拡張みたいな位置づけになるのかなあ。

無知なんでぐぐったけど、そういう感じで。UNIX系のメリットが生かせるのかなぁ。

>>185
> インストールパッケージの依存管理と同じ概念なのかな?
>
> > 「強制的に捨てられない」ていうんじゃなくて、
> > 「このファイルを必要としているファイルがあるか?」
> > という問いにMacが 0/1 で答えてくる。
>
> それに対してとれる行動は、
> ・削除を中止する。(推奨)
> ・強制的に削除する。
> というのでいいのかな?

「保守モード」に入っている時とか、パッケージに指定したフォルダ内(上のハードリンク的リンクマップがそのパッケージ内に埋め込まれるとかして)でのみ、そのダイヤログがでることを希望するね。
で、上の二つの行動を促すボタン以外に、問題のファイルを開くボタンもあってほしいな。
WINとの差別化をするならば。
そして、「捨てる」アクションに対してだけでなく、アプリなりFinder上の操作による問い合わせにも気軽に応えて欲しい。

と、ここで思ったのは、パッケージってリソースに代わる存在なんだろうか。

> OSXでは、ロックがかかったディレクトリは開くことが出来ないのね。
> 中のファイルを見るにはコンソールを使うか検索するしかない。不便だ。
>
無理矢理コンソールを使わせる作戦なんだろう。

189 :●~*:03/07/04 07:02

     ● ● ● ● ● ● ● ● ● ● ● と
     梨 梨 梨 梨 梨 梨 梨 梨 梨 梨 梨 こ
  な  は は は は は は は は は は は ろ
  ん  A A A A A A A A A A A で
  で  カ ラ 論 ガ 荒 9 な コ 妄 低 お  
  だ  タ リ 破 イ し 時 り ピ 想 シ そ  
  ろ  ロ ッ さ ド が と す ペ が ェ い  
  ?  グ っ れ ラ 大 1 ま が 大 ア C  
     評 て る イ 好 3 し 大 好 P P  
     論 る の ン き 時 が 好 き C U  
     が の が が B に 大 き B が が  
     大 が 大 大   書 好 B   大 大  
     好 大 好 好   込 き     好 好  
     き 好 き き   む B     き き  
     B き B B   の       B B  
       B       が            
               大            
               好            
               き            
               B            
                   

190 :●~*:03/07/04 07:06

          ┏━━━━━━━━━━━━━┓
          ┃             ┃
          ┃    他お Oパ 板  ┃
          ┃    の願 Sソ 違  ┃
          ┃  マ 住い 板コ い  ┃
          ┃  ッ 民し Bン で  ┃
          ┃  ク のま 等一 す  ┃
          ┃  マ 迷す で般 B  ┃
          ┃  ナ 惑B  板    ┃
          ┃  | で   B    ┃
          ┃  哲 す        ┃
          ┃  学 B        ┃
          ┃             ┃
          ┗━━━━━━━━━━━━━┛


191 :167:03/07/04 15:56
>189-190

激しくスレ違い。

192 :山崎 渉:03/07/15 11:24

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

193 :●~*:03/07/20 13:58
記念眞紀子

194 :●~*:03/10/03 00:29
ネタはないがあげてみるか

195 :●~*:03/10/03 02:59
梨って人自分に酔ってるね.

196 :●~*:03/10/05 10:58
オマエモナー

197 :●~*:03/10/08 19:36
↑名前忘れてますよ梨さん

97 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)