[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[b-free: 1736] Aki's Window Manager の青写真(長文)



えっと、Window Manager に関する話で盛り上がっているようですが、最初に
「やっかな」という事をいった手前もあって、ここらで、すっごくおおまかな構
成を話そうと思います。

ただし、B-free はいま、Window Manager を求めていない! (^_^;

むしろ、もっと基礎的な部分の話を進めなくてはいけない状態です。

そういうことで、誰か、音頭をとって、ほか(例えば process manager)の話を
進めてくれることを期待します!

# それって、各 manager の leader の仕事ですよね?

anyway...


<状況>
 現時点で、Device Manager の仕様も、Process 間 Message 通信
(Interprocess Message Protocol) もなーんにも決まっていないだけでなく、
GUI に対する要求も個人で、いろいろ意見が違うものと思われる。

<対応>
 そこで、ここで提案する Window Manager は、Display Driver や Key event
その他、window system を構築するのに必要な情報を収集し、適切にまとめ上
げ、process との処理の仲介をするものとするが、ただし、実際の詳細な GUI
などは Window Manager の入れ替えなしに、各個人が完全に自作できるものとす
る。
 尚、本 window manager によって、process は、monitor への表示などを仮想
化された window のもとに行うことができ、他に同時並行で走っている apps を
考慮する必要がなくなるものとする。同時に、必要ならば、window への描画環
境を取り出し、Display driver を直接叩くことで、高速な描画を許したい。

<処理範囲>
 個別の window の状態の管理と、app の window への操作の受け取り、
keyboard/mouse event の handling、再表示や張り込みなどの process への要
求、など。

<形態>
 以上のことより、Window Manager を2つの部分に分けることにする。


                A process
    +---------------------------------+
    |   Window Handling Principles    |
    +---------------------------------+
    |      Law Enforcement Engine     |
    +---------------------------------+
          Display Driver,... ,etc.


 Window Handling Principles (短くして Handling Principles、Hap) は、中
間 code を使った、program であるとする。それを駆動するのは、Law
Enforcement Engine (略して Lee) とする。

# 感じのよくない、略語だなぁ。(苦笑)

 Lee は、atom を使った、function-name binding engine と考えればよい。た
とえば、draw_line という atom が、”もし”も display driver の直線を引く
関数に対応しているとすれば、Hap 中にある draw_line が Lee によって解析さ
れたときに、display driver が叩かれて、線が引かれる。atom 同士の関係は、
より高次元に作ることができ、たとえば、draw_window という atom を
draw_line との関わりの中で定義することができる。

 もし、hardware の機能が利用できれば、直接、draw_window は display
driver の対応する機能に結びつけられるだろうし、そうでなければ、draw_line
  などの複合呼び出しなどによる自作することになる。

 process と window manager の interface を、しかし、統一することは必要
である。そこで、Hap で実装しなければならない atom を定義するものとする。
その中には例えば、resize や close などの window に対する処理がある。

 process からの各種要求は、Lee が process 間通信もしくは、int などを介
して受け取り、その情報を元に、Hap を運用して、適切なより基本的な処理(実
際の描画など)に帰着するものとする。

 process への処理要求も同様に、Lee が driver などから情報を受け取り、
Hap を運用して内部で適切に加工した後、必要な部分のみを、所定の process
に伝達するものとする。


<例>

1.mouse による、window の close 処理。

 Lee は、mouse event を監視し、内部の window の位置情報などと照らし合わ
せ、Hap を運用していく。
 例えば、double click などが適切な場所で起こった場合は、それが atom と
いう次元で認識され、window の close であると判別された段階で、process に
その旨が伝えられ、window が閉じられる。実際に process への通知が起こるの
は、atom 間の呼び合いの中で、例えば close_window という atom が呼ばれた
ため、それに結合する process への通知処理関数が呼ばれるからである。

2.window の移動による再表示要求の発生。

 process から(もしくは、mouse により)、window の移動に関する atom、例
えば move_window が呼び出された場合、move_window は、実際のwindow の描画
処理と同時に、重なっていた部分の再描画もやらなければならないだろう。 そ
れは、move_window が、各 window へ再描画要求を送り、各 window が自分に必
要だと判断して、draw_line などに atom を展開する。それらの処理は、実際に
描画される段階まで、atom の展開、収束などで処理されるものとする。



<さらなる話>

 そういうことで、Lee がどういう文法規則で byte code を処理していくかと
いうのと、実際にどういう semantic を使うか、すなわち、どういう atom を定
義していくかという話が、これからの僕の関心事になります。
 尚、なぜこういう構造が可能かというのは、atom の展開や収束が、結局のと
ころ、巨大な switch statement の様に働くからで、要するに、「window のこ
の位置に pointer があって、こういう event が起きて、そのとき keyboard の
状態はこうで、、、」とかいう、複雑な、条件判断を、atom (word といっても
良い)を介して処理できるからです。

そういうことで、これからも、何か、進展があれば、連絡しようと思いますの
で、よろしく。


-Aki.