[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[b-free: 1916] Re: BTK
From: Hidetosi Ochiai <h953046b@ice.nuie.nagoya-u.ac.jp>
Subject: [b-free: 1907] Re: BTK
Date: Thu, 23 Jul 1998 17:33:10 +0900
> 落合です。おそくなってすみません。
>
> /* In [b-free: 1859] Re: BTK
> Yasushi Shoji <yashi@yashi.com> Wrote: */
>
> |まずは勘違いの修正から(^^;
> |
> |×display primitiveとは、単にwindow内に線や図形を書く物だけだと思っていた。
> |○どうやら、格マネージャーの下地になっているらしい。
>
> 私とやすしさんの意見が合わなかったところはそこです。
> 画面に描画をする(ビデオドライバとお話しをする)のは
> ディスプレイプリミティブだけで、他のマネージャは
> ディスプレイプリミティブを利用して描画する、というのは
> BTRON1 でほとんど前提になっていますね。
いやいや、失礼しました‥(^^;
> もちろん、それぞれのマネージャが独自に描画するようにしても
> API さえ合っていればそれでも良いのですが、
> マネージャを作る上で苦労するだけのような気がします。
>
> |Xlibをwrapし、display primitive APIを提供するlibraryがあり。
> |そのlibraryを使うlibrary達がさらに存在する。で、このlibrary達が
> |BTRON規格で言うマネージャーにあたる。
> |
> |さて、ここで問題なのは、マネージャーとなったlibraryをコールするだけで
> |Xの上でwindowを動かす事ができるのだろうか?
> |自分では、「やったこと無いからわかりません。」としか言えない(^^;
> |
> |それとも、マネージャー達はdaemonのようにそれぞれ独立したプロセス
> |なのだろうか?と言うことになれば、(BTRONの)window managerが
> |それぞれのプロセスにイベントを与えるという機能も納得が行く。
> |で、そのprocessとのinterfaceとして、さらにlibraryがあれば
> |一番(個人的には)納得が行くのですが‥。どうなっているのですか?
> |
> |上記のようならばBTRONで言うところのwindow managerは
> |libraryとして、X で言うところのwindow managerは
> |1プロセスとしてそのlibraryを使ってapplicationと接する
> |となるでしょうか?
> |つまりBWM + libwm.so(仮称) = BTRON window manager?
>
> このあたり、いまいち理解ができないのですが、
> なんとなく伝わるのは
> 「X の window = BTRON のウインドウ」
> にしようとしているのではないか、ということです。
> それはあまり得策ではない、と私は思います。
>
> 私の推奨する方法は、
> 「X の 1つの window = B-Free のディスプレイ」
> とすることです。
> X の1つの window を1つのディスプレイと見立てて
> その中に BTRON アプリケーションのウインドウやメッセージパネルなどを
> 表示する方法です。
>
> Windows 用の X Server では、
> 「Windows の1つの window の中で複数の
> X の window を表示する」物と
> 「X の window = Windows の window」の2種類があります。
> このうちの前者のようにしよう、ということです。
これは前者の方で良いのでは?さらの状態でXだけがはしっている環境が
ある場合、すべてのwindowの親になるのはRootwindowですから。
それををのままWindowsに持ってくると、他のwindows applicationと
いっしょにはみれなくなりますが(root windowが、一つのwindowとなって
しまうため)、Xの上では、Rootwindow以下(上?)にwindow達が、いますから。
それとも落合さんがいいたいのは、それすらせずにということかな?
> X のアプリケーションと B-Free を並べて同時に操作したい時には
> あまり使い良いとは言えませんが、これでも十分目的を果たすと思います。
>
> B-Free が十分使えるようになって、開発に余裕が出てきたら
> 「X の 1つの window = B-Free のディスプレイ」
> もできるように改造するのも良いでしょう。
B-Free良くわかってないので質問させてください。
Xの XCreateWindow()という関数にあたるものは
BTRON1では、wopn_wnd()だと思っていたのですが?
> |> ○Blue Project は何ですか?
> |
> |基本コンセプトは、XをB-FreeOSの一部として使えるように移植することです。
>
> 「X がどの環境でも使いたいので、B-Free に移植する」
> と
> 「B-Free の GUI 部分の開発の手間を省くために X を部品として使う」
> のどちらでしょうか。
後者ですね。
前者ならX protocol変換I/Fだけで、十分なはずです。
> |B-FreeOSの核の部分が完成するまでは、BTRON仕様のuser interfaceを
> |現在すでにXが動いているプラットフォーム上で開発します。
> |その副産物として、applicatin levelのprogramerが開発を開始できる
> |ようにもなる。
>
> そこはあまり期待しませんけどね。
> ファイルシステムや仮身・実身が使えないですし、
> 1B や B-right 上で作れば良いことですから。
1BやB-rightがあるのにB-Freeを作っている理由は?(^^;
> |> ○Blue Project が実現すると、どんな良いことがありますか? ←これが一番重要
> |
> |B-FreeOS上にXを移植することによってB-FreeOSの開発時間短縮ができます。
>
> やはり、開発の手間を減らすのがいちばん重要ですよね。
そうですね。早くB-Freeだけで色々できるところをみたいですね。
> |> ○Blue Project と B-Free の関係は?
> |
> |B-FreeOSの上位核(周辺核の一部?)の実装をX baseで行います。
>
> 私としては、X に直接依存するのはディスプレイプリミティブだけに
> したほうが良いと思うのですが。
二つあるというのはどうでしょうか?
Xlibを直接叩くマネージャー達
DP APIしか使わないマネージャー達
Xは、networkを使うために他のwindow systemよりもoverheadが多いです。
そこにAPI wrapperをかぶせてしまうとさらに重くなりますよね。
GUIの速度は、いちばんuser接しているところなのでできるだけ軽くしたい
と思っています。しかもGUIの処理だけで、CPU timeを消費したくない‥。
ただし、これの方法だと、落合さんが何度もいわれているように
moduleの構成が壊れます。つまり、XlibいがいのDPができたときに
manager達をそっちに移植するのは大変かも知れません。
そこで、DP APIを使ったmanager達の方が、いいじゃないかという意見
ですよね?速度を取るか、モジュール構成を取るかですね。
もちろん DP APIようのwrapperはどちらをつくる場合でもつくります。
そこで、その辺はマネージャーを造る人が決めたらいいじゃないか
という、いい加減な考えなんですが‥‥、どうでしょう?
> |> ○Blue Project は B-Free の GUI ができるまでの継ぎなのでしょうか、
> |> それとも B-Free でずっと使っていくものなのでしょうか。
> |
> |これはMLでも議論になったのですが、「どちらでも良いのでは?」
> |と言うことだったと思います。
> |
> |だれかが、「Xは嫌いだ、もっと早い描画が必要だ」などと、思った時点で
> |作り替えればいいだけだと思います。
>
> X への依存度をできるかぎり減らさないと、作り直しが
> 大変になってしまうので、ディスプレイプリミティブだけに
> とどめておいたほうが無難じゃないか、と思います。
上に書いたようにmanger製作担当の人にまかせません?
◇ Xlibを知っているので直接叩きたい。
◇ Xlibなんて知らない。
◇ wrapperを通すと遅くなる。
◇ wrapperを通しても、たいしてかわらない。
◇ XをつかったDPなんて、嫌いなのでDP APIを使ってマネージャーを書いたら
俺がDPを書いてやる。
まあ、いろんなシナリオが考えられますね‥。
--
Yasushi Shoji | my pgp public key is
yashi@yashi.com | http://yashi.com/public_key.txt
yashi@kafka.salem.mass.edu | powered by linux and open source software