アカウント名:
パスワード:
○(何かの役に立つだろうから)入れ子関係を、生成後に変更することができるようにする。 (これでSqueakに手が届く…か？)
これ↑はちょっと自信がないんですが、
○多段の入れ子もアリ ○親も子も、専用化はしない。枠でも中身でも好きに表示しろ。 (これは制約を設けないだけだから、処理や構造はべつに複雑にならないはず)
(略)
○いわゆるデスクトップ自体も、単に「ルートの窓」として定義(?)する。
これってモロに今の X Window System なのではないですか？ 例えば、X でのスクロールバーとかメニューとかボタンっ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
ソフト固有の脆弱性というよりも (スコア:2, すばらしい洞察)
既存概念とかそういったものからくる脆弱性ですね。
そもそも脆弱性と言っていいものかも難しいと思いますが…。
少なくともソフトウェア固有の問題ではないとおもいます。
GUIがまだ足らない。 (スコア:0)
金持ってる所のUIデザイナーが出してくれるマシなアイデアに期待します。
Mac OS X のシート (スコア:1)
Mac OS X から導入された「シート」は、最適ではないでしょうか?
ウィンドウのタイトルバー付近から垂幕のごとくダイアログが降りてくるというインターフェースです
Re:Mac OS X のシート (スコア:1)
「ウィンドウとダイアログがくっついている」ってのは
凄く大事なポイントっぽいですね。
最近思うんだけどさ、いまどきのGUIの「問題」の幾つかは、
○ウインドウを入れ子にする
ことによって、
解決しちまうんじゃなかろうか？
ウインドウとダイアログの関係もそう。
デスクトップじゃなく1つのウインドウの「中」に
ダイアログが出て、出てる間は下の(対応する)ウインドウのフォーカスを奪う、
という風にしておけば、それでいいわけで。
Windowsには(だったかな)MDIっていう入れ子窓みたいなのがあるが、
あれって
Re:Mac OS X のシート (スコア:1)
これ↑はちょっと自信がないんですが、
(略)
これってモロに今の X Window System なのではないですか？ 例えば、X でのスクロールバーとかメニューとかボタンっ
Re:Mac OS X のシート (スコア:1)
ええ。APIレベルではそうなんです。
Windowsでもそうですね。全部WindowHandleという概念で統一されてる。
が、ユーザ(UI)レベルから見れば、
各Widgetは各Widgetとして特殊化されてて
それらの共通性はむしろ隠蔽されてます。
WindowHandleみたいな概念はただの Widget実装の道具として
(つまりプログラマによって)使われてるだけ。
その自由度をユーザレベルにも開放(?)したいんです。
具体的には例えば、
「○多段の入れ子もアリ」
ってのが実際に実装されてるのって、あまり見かけません。
Windowsだと、よく知らないけどMFCの教科書とかにはMDIが必ず出てくるんで、
たぶんMFCがMDIという非多段窓をプッシュしてるんだろうと思います。
で、ゲンジツを見ると、そのアプリを作ったライブラリがMFCであろうがなかろうが、
MDIを採用してるアプリって、凄く多い。
(みんな洗脳されてるんだろなあ)
そしてXとかでも、MDIっぽいUIはしばしば見かけますが、
幾らでも入れ子をしよう！っていう発想で作られたUIは
あまり見かけません。
(こちらもみんな洗脳されてるんだろなあ)
これが俺としては残念なんです。
そんなわけで、俺が(ここで)言いたいWindowとは
APIレベルの話じゃなく、
世間でFormとかDialogとか呼ばれてる、いわゆる「窓」(ん？)です。
あれを、「○多段の入れ子もアリ」とかにしたいんです。
ちなみにDashboardネタを見てるうち [srad.jp]に思ったことだったりもします。
つまりDashboardとは、
Desktopという窓に、 Dashboardという窓(透明)を、
オーバーラップさせたものだ、と捉えればOKなんです。
(俺の理解が間違ってなければね：以下同文)
DashboardがVisibleかどうかはF12で切り替わる、と。
そして前述の通り、Dashboard窓にWidget(X用語じゃなくDashboard用語のほうの)窓を置ける、と。
で、
DashboardとかWidgetとかいう「特別な」ものをOSメーカが用意するよりも、
上記のように単純で(ユーザの手により)応用可能な仕組みが用意されてるほうが
いいんじゃないかなーと思ったんです。
例えばこの例だと、WidgetをDashboard(という名の窓)かDesktopか、
どっちに属しているか？をユーザがささっと変更できれば、便利なわけだし。
だいいちDashboardみたいなもの「を」ユーザが簡単に自作できるほうが、便利なわけだし。
だって、上記のようにすれば、単に「透明窓を用意する」「それをF12で出させる」だけで
できあがっちゃうんだもん…
＃そして、パクリだと訴えられませんようにと祈るわけです(わら
あと垂幕云々もそうですし。
というか今まで「ダイアログ」を独立した別窓[*]で出すというUIを採用してたのが間違っていたわけで。
[*]独立といっても、上記の定義(？)より、真に独立した窓はRootであるDesktopしかありません。
ここでいう独立とは結局、そのダイアログを出すキッカケになった窓(か、その更に元となった「アプリ」の窓)に
従属していない、ということです。
>以降の方が面白そうです。
ああ。ファイルとかアイコンとかオブジェクトとかの話は
前半の「窓」の話だけの話よりも、さらに広い話をしてますから。
オブジェクトの中にオブジェクト(たとえばディレクトリにファイル)を置くのは、すなわち
それ(のデフォルトビュー)のWidgetに入れ子関係を持たせるのと、等価だと見なしたい。
個人的には、MVCよりも、Mに「デフォルトビュー」が必ず１つついてるという方式のほうが、
判りやすいんじゃなかろうか？と思っています。
ほっといてもとりあえずデフォルトのビューは提供される、という世界です。
>既にどこかの砂場でやられてそうな気がしますけど。
そりゃそうでしょうね。
こんな単純なアイデアが既出じゃないとしたら、
俺は人類の未来に絶望せんとなりません(^^;