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

[b-free: 1855] Re: B-Free に Xを載せる (Re: B-Free OSの解説ほん



/* In [b-free: 1835] Re: B-Free に  Xを載せる (Re: B-Free         OSの解説ほん
   Hideaki Suzuki <h1suzuki@bridgew.edu> Wrote: */

   |> イベントの流れをちょっとだけ追ってみました。
   |> プロハンを見るかぎり、どうやら BTRON1 だとイベントは
   |> ウインドウマネージャを一切経由せずに
   |> 直接アクティブプロセスに送られるみたいです。
   |> ウインドウマネージャがイベントを把握できるのは、
   |> プロセスがwget_evt()を使ってイベントを取り出した時だけです。
   |
   |あれ?そうでしたっけ?すべての event は、window manager に送られ、そこで再加工され
   |て、同時に
   |window manager 独自の event も追加され(例えば、INACT)、その後に、
   |前面 window の疑似 active process に回され、疑似 active process は、
   |自分に有効なように送られてきた event を加工・消費し、その結末が、
   |Active window process に到達するという感じではないですか?

うしろのウインドウをクリックしてアクティブウインドウが
切り換わる場合のイベントの流れを追ってみました。

マウスドライバ
     ↓
イベントマネージャ
     ↓
アクティブプロセスのイベントキュー
     ↓
アクティブプロセスがwget_evt()でイベントを取り出す
wget_evt()
{
    get_evt()
    if(マウスのクリック && ポインタの位置が他のウインドウ)
    {
        クリックされたウインドウに EV_SWITCH イベントを送る
	EV_INACT を返す
    }
    :
    : (その他の処理)
    :
}

ようするに、wget_evt() の中でウインドウの切り換えが必要かどうかを
判断して切り換え処理を行なっている、ということです。

   |そういうことで、window の流れの詳しいことは、前に落合さんに送った
   |(様な気のする) BTRON1 の Window Class をみてください。

これはアプリケーション側のイベント処理ですね。

   |# っていうか、まだ持っています? この前、HD が飛んだときに最新版を
   |# 失ってしまったので、もし、お手数でなければ、そして捨てていなければ
   |# こちらに送っていただけないでしょうか? 勝手なことを言ってすみません。
   |# よろしく。m(_._)m

持ってますので、送ります。
# 実はあんまり読んでなかったりします。

   |> とすると、アプリケーションが wget_evt()を使わずに
   |> get_evt()でイベントを取ってしまうと、ウインドウの切り替えが
   |> 一切できなくなってしまいますね。(実際に確かめた訳ではないです)
   |
   |ということで、こいつは、rule 違反っていう奴ですね。

アプリのせいでウインドウが切り換わらない、というのは
システムとして問題のような気がします。

===
  落合秀俊   名古屋大学工学部情報工学科
  h953046b@ice.nuie.nagoya-u.ac.jp