アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
グループ化されないウインドウ達 (スコア:2)
仮想デスクトップはウインドウのグループ化に他なりません。
しかし個々のアプリケーションが独立してるためグループ化しようとしても1グループ1アプリケーションになってしまいます。
それでも昔は1つのアプリケーションが多くのウインドウを出していましたの
Re:グループ化されないウインドウ達 (スコア:2, すばらしい洞察)
なんか、Xの仮想机のほうが優勢な雰囲気ですが、
その割に、窓間の連携に一日の長がある(五十歩百歩かも知れませんが)のは
DragDropをOSで標準装備(だよね)したWinのほうかなというか…
まあWinとXの相対的な比較はともかく、
絶対的な話として、窓モノはどれもこれも「協調動作」が下手だってのは同意。
>逆に小さなツールが協調して動くようになれば1つの作業を行うアプリケーション同士をグループ化するようになるのではないでしょうか。
Pipeになるのか、あるいはObject間の自在な参照関係になるのか、
まあ色々方式が考えられる気がしますが、
なんにせよ「窓」同士が、見た目(デスクトップ含む)だけじゃなく論理的機能的にも「繋がって」欲しい
と思うことは多いですね。
＃そういやスラド本家でPipes In GUI's(リンク生きてるかどうか怪しいです) [slashdot.org]っていう話が有ったことが有るらしいね。
＃＃こういう「プログラムのアーキテクチャ」みたいな話って、スラドJではなかなか出てこないね？
ちなみにご存知UnixPipeと同じモデルにすると、複数の窓の「寿命」を一致させることを強要されちゃうわけで、
それは窓アプリとしては不快きわまるんで、勘弁願いたいです。
使用「中」に一部の窓だけ交換したいじゃないですか。でも伝統的にshとかで操作できるUnixPipeだと
使用「中」にPipeの中の1つのプロセスだけを(ユーザが命じて)交換すること、は出来ないですよね。
あれはダサい。
一番いいのは、それこそSmalltalkみたいに、Object間が自在に連携できるし、連携を動的に幾らでも変更できる
(という可能性が提供されてて、しかも連携の実装は容易である) という形かな。
ただ、考えれば考えるほど、プロセス間の壁って、 GUIにとっては邪魔だよなーと思ってしまったりしますね。
Smalltalk的な柔軟な振る舞いは、プロセスベースのシステムだと、高いコストを払わないと出来ないっしょ。
現代主流の、アプリごとに孤立した窓っていう(不便な)モデルは、ちょうどプロセスの壁が視覚化されたものなんだよね。
これじゃ、たとえば「DragDropは、単にObjectをアッチからコッチに移管するだけの処理です」と言われても、
その「単に」の部分のコスト(処理コストや、コーディングコスト)は、高いままです。
＃SqueakじゃマウスポインタすらObjectでありWidgetである、のだと聞いて驚いたのでG7
＃つまりObjectやWidgetが「アプリ」「プロセス」に従属してないのね。素晴らしい！
----
さて閑話休題。
本題(?)の、そういう窓を「表示する場」を分ける必要が有るか？ですが、俺はあまり必然を感じていません。
現状でもあまり感じていませんが、「連携」が改善されれば尚更不要になるだろうな、と思っています。
というのは、窓同士の繋がりなんて、それこそ動的に幾らでも弄り倒せるようになるだろうから、です。
例えば、「この一群の窓たちよ、最小化してくれや」とか「こっちのグループは、最前列に出てくれや」とか
という命令の仕方が可能になるはずなので。
そして、それを切り替える命令を投げる部分も、きっとユーザが「簡単に」カスタマイズ可能になるだろうから。
何人かの人(俺もですが)が「Alt-Tabでいいじゃん」と言っていますが、
そのAlt-Tabの延長のような操作性を、もっと多様(つまりユーザのお好み次第)な場面で
活用できるようになるはず、なんです。
窓の並び具合を自力で制御する窓グループ、なんてのも作れるでしょうね。
そうすれば、最早、「並べておく」必要すら無いわけで。
「おまえら、前に教えたとおりに、自分らを再配置しろや」と命じれば、それでいいんです。
＃これくらい出来なきゃ「オブジェクト指向」じゃない、と思っているのでG7
＃つまり、オブジェクト指向を「本当に」活用して設計すれば、デスクトップは飛躍的に快適になるだろうな、と…
----
つーか、逆にいえば、
「デスクトップ」が何枚存在しているか？っていう問題自体も、
ユーザが簡単に弄れるようになるんじゃないかな。
窓に窓を埋め込む機能さえ有れば(原理的には単純なWidgetの親子関係の操作です)、
フルスクリーンの窓を「デスクトップ」と命名して(^^;、
それを複数用意して、当然1枚以外は裏に回って非表示にして、
それらに他のアプリ(?)の窓を埋め込めば済むんです。
あー。というわけで、俺的には、
仮想デスクトップ問題はバッドノウハウに過ぎない、という結論になっちゃいました。
デスクトップとアプリと窓とWidgetの関係が、(現状主流の環境において)どういう不便な構成になってしまっているか、ってのを
「回避」
するための方便なんだろうね、仮想デスクトップって。
上述したように、結局は、Unix伝来のProcessモデルと、
GUI窓モデル(Objectっぽいものが沢山表示されるモデル)は、
あんまり相性が良いわけじゃない、ってことなんでしょうね。
Re:グループ化されないウインドウ達 (スコア:0)
Word,Excel間の連携のようなものを全てのオブジェクトで行うことができる。
Word使用中にExcel部分をOOoに変えたり、文章を書く部分だけemacsにすげかえたりできる。
そしてWord内グラフ消したらGCかかってOOoが消える、と。
更にinterfaceが守られている限り、リモートメソッドでも区別しないわけで
リアルタイム協調作業なん
Re:グループ化されないウインドウ達 (スコア:1)
なんじゃそれ？とか一瞬思いましたが、
これって、メソッド(っていうのかな…とにかく委譲先)を
動的に差し替えたことに相当するわけですね。なるほど。
>文章を書く部分だけemacsにすげかえたりできる。
既存のGUI環境でも、エディタを好きなモノに云々ってのは有りますし、
そういやGNOME用のviエディタWidgetって話も以前スラドに上がっていましたが、
今の所はプロセスの壁が有るんで、少々煩雑かなと。
GNOMEはCPU(てか、メモリ？)パワーを馬鹿食いすると聞いていますが、
ある意味で同じように柔軟なGUIな世界であるSqueakは
モバイルなチャチなマシンでも最低限動くわけで、
もしかして効率は段違いなんじゃないか？と想像しています。
>そしてWord内グラフ消したらGCかかってOOoが消える、と。
GCはどうしたものか微妙です。
永続データを、おいそれと「参照が消えたら」消してもいいかどうか、とか。
ちなみに既存Filesystem上でのGCといえば、ハードリンクですよね。(語弊が有るけど)
単純な参照係数法ですが、あれで困らないのは、
ファイルからファイルへの参照は無いモノと決め付けているからです。
ファイルを参照するモノがファイルの中には無い(ファイル名を管理する側にだけ有る)。
簡単でイイんだけど、そのぶん表現力が少ないなぁと。
で、ファイル内に「他のファイルへの参照」という概念を持ち込んだら、
これってそれこそB-TRONの世界ですよね。
あと、同じノリで、プロセス内に「他のプロセスへの参照」も持たせたいなあ。
>更にinterfaceが守られている限り、リモートメソッドでも区別しないわけで
>リアルタイム協調作業なんかが可能になるわけですね。
可能というより、「楽」になりますね。
協調モノは、現状でも色々なソフトが有るようですが、
それらはそれこそアプリを作る側がヒーコラ苦労してるはずであって。
まあフレームワークを組んじまえばOKともいえますが、
どうせ皆が使うフレームワークなら、OSが提供してくれたっていいじゃないか、ってのは言えてます。
＃使い易い(=OSに装備とか)ようになっていないから、皆があまり使わないんだよね。
>問題はそのチェインをGUIでいかにして作り、制御するかですね。
>interfaceのレジストリ作って可視化操作するのかな？
レジストリってWinのあれですか？
あれも、プロセスの壁に対する、苦肉の解決策ですよね。ちょっとハズしてますが。
レジストリみたいなものが作られてしまった背景には、結局、
壁なぞ無くして全体を見渡せる手段が欲しいっていう欲求とか、
クラスやオブジェクトを一意に特定したいっていう欲求とか、が
存在することを示していると思います。
つまりあれこそ、プロセスな世界の中に擬似的にOOな世界(しょぼいですが)を作るための抜け道なんだろうなと。
で、だったら最初からOS全体をそのように作れよな、という感じで。
とりあえずの見本はSqueakとかでよいんじゃないでしょかね。
あれの卑近な見た目を、有名OS風にすることは可能でしょうから、
そうすれば参入障壁も少ないでしょう:-)
Re:グループ化されないウインドウ達 (スコア:1)
OpenDoc(だっけか)とかOLEとかを初めて耳にしたときの違和感、を思い出しました。
つまり、なんで「ドキュメント」だけじゃなく任意のObjectを、連携可能にしなかったんだろう？っていう話です。
ま、奴らの魂胆(藁)は見えてるわけですけどね。
MVCでいうM、それも「ドキュメント」なんていう大物
(典型的には、1つのデータファイル丸ごとってとこでしょう)だけを
埋め込みの対象として選んだってのは、それだけ、
細かい粒度のオブジェクトを相互乗り入れするオーバーヘッドに耐えられないと踏んだからであって、
なんでオーバーヘッドが有るかってーと、やっぱりプロセス(データファイルをロードしてる)が単位であるから、
ということなんだろうなあと。
実につまらない世界です。
＃フローティングツールバーが、隣のプロセスまで移動できたらお洒落なのにな、と、いつも思っているのでG7
Widgetを並べてGUIを構築する、というレベルにおいては
OOPは(つまりVBのような形で)きちんと結実したわけですが、
そこから先が一向に進んでいませんな。
そのせいで、Squeakみたいな原理主義との間の「距離」が空きすぎてしまっている。
中間ってものが無い。両極端しかない。
かくしてmatz氏がSqueakにそっぽを向くわけです(藁
＃Document-ViewもMVCと呼ぶにしてはイカサマくさいし、
＃ついでに言えばWebアプリのアレもMVCではない。
＃なんかここ数十年(藁)、似非MVCが我が物顔で主流派になっちゃってるのを、見るに忍びないのでG7
>問題はそのチェインをGUIでいかにして作り、制御するかですね。
ま、単にオブジェクトが存在して、互いに接続できれば、それでいいわけで。