覚え書き

見てもいいけど... 内容は消えるか 移動するか どちらかになります。

MGLにおけるコンポーネントとは何か

mglsvr の処理

作りたいものは、MGL API をそっくり動かせる 矩形領域ということになるだろう。

mglsvr では、その矩形領域は、フォーカスされたとき キー入力イベントを受け取ることが できるようになってる。これは、コンポーネントでも同じで良い。

大昔のGUI なんかは、フォーカスされたものだけが、実行されるような構造だったり するけども、 mglsvr では、フォーカスされずとも さらには、画面から見えなくとも動ける ... というより 別プロセスだから、動けるようにしないとまずかったわけだ。
画面から見えなくとも動けるというのは、どういうことかと言うと、 offscreen を持っていて、見えなくなるということは、offscreen に切り替わる という構造をしているわけだ。

フォーカスされてなくとも動けるというのは、どういうことかというと 誰も勝手にその画面を触れない .. ということである。
どうしても画面をさわりたかったら、イベントを送って offscreen にしてもらう。 画面上になにかが出ているかも知れないが、それは残像であって、実像ではない。

mglsvr コンポーネントをサポートするということは、この構造は壊さない ということになる。

cmgl でかわること

上のようなルールだけをベースにすれば良いかというと たぶんマズイ。 cmgl で どういう風に変えていくべきだろうか？

• コンポーネントは、親子 関係があって、親に子を張り付けるような ことができないといけない。
  親にフォーカスが行くたびに、子を offscreen にすることは可能だが、 それでは オーバヘッドが大きすぎる。
  これは、まあ下の画面は考慮しなくて良いという宣言をして張り付けるようなことを 考えれば、対処できそうだ。

• フォーカス切替え(F10) での処理はどうなるんだろうか。
  木構造になるから、イベントを受け取ることができるもの (= get_key() しているか、key_select で 0 をチェックしているもの) に対して、木を探索していく。
  ただし、widget とか内部構造を持っていたりして、内部でも切替えていかないと いけないだろうから、 フォーカスを切替えてねイベントを出して、実際にフォーカスを離すのは、 その コンポーネントが自分で離す ... という構造にすることにしよう。

• ダイアログやメニューを出すには
  勝手にやってねというわけにはいかないだろう。そのコンポーネントより 大きなものを出したいケースがあるからだ。
  コンポーネントを作って、ルートとか親のコンポーネントにくっつける。 そうすると作ったコンポーネントは実行待ちになる。 それが実行されるときは、下にある 領域を触れる状態にして、さらに そこをセーブして、実行する画面を表示して .. 処理を開始する... たぶんそんな手順になるだろう。

• コンポーネントを移動するには、
  イベントを送って コンポーネントを見えない状態にしてもらう。 ( そのコンポーネントがセーブしていたものを元に戻す )
  そして、場所を変更して、見える状態にしてねイベントを送る。
  これを受け取ったら、上と同じように表示すれば良い。
  ただし上と違うのは、上がなくなって、offscreen でなくとも良い コンポーネントが出てくるということ。
  これは、移動したあとチェックして イベントを送る。

• んー。widget のためのイベントモデルっているんだっけ？
  アプリケーション本体に widget を張り付けるんなら、それは コンポーネントである必要があって、その結果勝手に動く。
  widget になにかを張り付けるのなら、それは widget のルールに従うべき 話だから、気にしなくとも良い。
  
• IM はどうしよう。
  フレームワークは、コンポーネントで、イベントを対象コンポーネントに 送ってもらう。
  いくつか気にかけない点があるかも知れないけど、基本はそれでいいのかな？

たとえば、network から イベントが送られてきたら、それはすみやかに 処理されるべきである。mglsvr でもサポートしていた。

mgterm などでは、そうやって受け取ったものは、画面に出力する。 mglsvr では、VISIBLE,UNVISIBLE の状態をもっていて、UNVISIBLE のときは、 memscreen に切り替わっていて、そこに書くことになる。 また、VISIBLE でフォーカスされてない状態でも、画面はいつでも使える 状態であった。だから、いつ画面を変更しても良い。
その代わり、だれも画面は勝手にさわらない .. そういう設計だったわけである。
こうした理由は、mglsvr では 複数プロセスが parallel で 動いていた。こういう状態が普通だから通常勝手に画面は、触れない。

そういう処理はサポートすべきだろう。ということで、VISIBLE,UNVISBLE という 状態があり、VISIBLE でも フォーカスされた状態があることになった。

それだけで良いかというと ... そうではない。

コンポーネントでも 別プロセスの mgl プログラムを張り付けられるわけだが、 それ以外のものは(実行可能でもその瞬間は)止まっている。
張り付けた mgl プログラムを 止めてでも、画面をさわる..といった方針が 妥当だろう。

これで、VISIBLE の状態が増えた、画面を触って元に戻せばよい状態と 触ってはダメな状態である。これは、フォーカスされている状態と関係ない。
これは、画面を LOCK している状態とそうでない状態ということにする。 画面を LOCK している状態にできるものは、LOCK を外すというメソッドを提供 する必要がある。ちなみに、ここで言うメソッドとは、LOCK を外せというイベントを 受け取ることができるという意味である。このイベントは、特別で溜っていた イベントがあったとしても、それらを追い越すという処理が必要かも知れない。

さて、コンポーネントは普通オーバラップする。親のコンポーネントの中に 子どものコンポーネントを張り付ける ... そういったことはできないといけない。

処理を考える前に、画面に見えるものの状態はどうなっているべき かを整理してみる。

• 1) VISIBLE で フォーカスされており、イベント待ちのもの。
• 2) VISIBLE で LOCK されており、イベント待ちのもの。
• 3) VISIBLE で イベント待ちのもの
• 4) VISIBLE だった残骸。(UNVISIBLE だが、画面上の領域をもっている)
  捕捉) ルートのコンポーネントには、すべての画面を渡すので、バックグラウンドという 概念はない。

そして、1) 2) は、オーバラップできない。3) の上には 1) もしくは 2) が オーバラップできるが、画面をセーブするという条件が付く。

また、オーバラップされている 3) は、イベントが来てもすぐに実行してはならない。 という条件がある。

さて、こういう条件では、コンポーネントを張り付けたら最後、 張り付けたコンポーネントをどかさない限り 動かせない状態になってしまう。

それでかまわないケースもある。ダイアログとか popup メニューとか である。

それはひとまず置いておいて... 張り付けたときに、その部分は親子で調整する という宣言をしてもらえば、良いのかも知れない。