[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