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

[b-free: 1854] Re: BTK



/* In [b-free: 1840] Re: BTK
   Yasushi Shoji <yashi@yashi.com> Wrote: */

   |> > あと、BTK の存在価値がいまいち分かりません。
   |> > BTRON の「パーツ」を X で作る、ということですよね。
   |> > それよりは、「ディスプレイプリミティブ」の機能と API を
   |> > X で実現して、パーツや(BTRONの)ウインドウマネージャの描画は
   |> > ディスプレイプリミティブの API で作るのはどうでしょうか。
   |> > そうすれば、パーツやウインドウマネージャの描画部分は
   |> > そっくりそのまま B-Free に持ってこれますし、
   |> > 内藤さんが言うように X Server を B-Free に移植すれば
   |> > ディスプレイプリミティブもそのまま持ってこれます。
   |> 
   |> えっと、Parts Manager の描画で、Display Primitive の Wrapperを通すというのは、効率の面
   |> で不利だと思われます。
   |> 直接、Xlib を叩いた方がいいのではないかと。
   |> BTRON の Window Manager でも同様に、 Wrapper を通す
   |> 必然性はないものと思います。
   |
   |Blue Projectで、作るものはすべてXlibを直接叩く予定です。
   |その方がakiさんも書かれているように速度の面で良いと思われるからです。

たしかにそうですね。
ですが、そうすると BTK や BWM が X 依存になってしまうので
将来 B-Free が X server を使わずに自前で描画をするようになると
パーツマネージャやウインドウマネージャは新たに作り直しに
なってしまいます。
ここも、BTRON 本来のモジュール関係に合わせたほうが良いかと思います。
速度の面でもそんなに違わないと思うのですが。

   |で、提供するものとして、BTRON仕様に沿ったAPIを提供します。
   |
   |                    +-----------------+---------------+
   |user level app      |BTRON application| Xlib Ready App|
   |--------------      +---------+-------+---------------+
   |manager level       |   BDP   |  BTK  |               |
   |つまり外核?        +---------+-------+               |
   |                    |               Xlib              |
   |                    +---------------------------------+
   |
   |こんな感じでしょうか?
   |BWMは、Xlib Ready Appとなります。

図から見ると、BWM は BTRON のアプリケーションから使わないことに
なっているのですが、これはどういうことでしょうか。
いまいち BWM の位置付けが分かりません。

もしかしたら、BTRON のウインドウの表示に X の window を
そのまま使って、X と BTRON の表示のしかたの違いは
X の window manager を使ってできるだけ無くそう、ということでしょうか。

BTRON のウインドウマネージャと X の window manager は
守備範囲が異なります(例えば、ウインドウの変形・移動は
アプリケーション側で処理をします)。
ですので、BTRON っぽいけれど別のものになってしまいそうです。

   |これ以外にも、パネル、メニューマネージャーも必要ですね。

このあたりも X 上に直接作るのでしょうか。

   |BTRON仕様では、外廓へのAPIもsystem callとして扱ってるようですが
   |Xlibなどは、その名前からもわかるようにlibraryです。
   |そしてその上に乗せるBTK、BDPもやはりlibraryになってしまいます。

これは問題ないと思いますよ。

   |> ところで、wopn_wnd() かなんかで、window の制作を行うとき、外寸ではなく、
   |> 作業領域の大きさと外形の右上を与えた方が、良いのではないかという話が
   |> ありました。主な理由は、enableware に関することです。
   |> どの様に思いますか?>みんな。
   |
   |X + WMのかんきょうでも、clientが望んだ作業領域をWMは無視できます。
   |その結果、clientは作業領域を要求した後に確認しなければなりません。
   |
   |(昨日はそのことすっかり忘れてました ^^;)  > akiさん
   |
   |で、WMを作っているのが自分達なので「必ず要求された領域を与える」
   |と言うこともできますが‥、それはちょっとまずい気がするので‥、
   |clientは、必ず確認するという仕様にしたいと思います。となると、
   |外寸を与えようが、内寸を与えようが、一度確認のための情報交換が
   |起ります。Xでは、WMがapplicationをmapする前にサイズを変える(要求
   |されたサイズではない大きさに)と、ConfigureNotifyというイベントが
   |起こり、applicationに変更されたことを知らせます。プロハンでも探
   |してみたのですが、探しきれませんでした。(というか、流れを把握し
   |てない‥<じぶん)

私も window を作るときに作業領域を指定できたら良いのに、と
思うのですが、変えるとなると BTRON の仕様を変えることになりますよね。
アプリケーションの互換性のこともあり、あんまり仕様の変更を
しないほうが無難ではないかと思うのですが。

%

私はいまだに Blue Project を理解していません。
ここで基本的な部分の質問をさせてください。

○Blue Project は何ですか?
○Blue Project が実現すると、どんな良いことがありますか? ←これが一番重要
○Blue Project と B-Free の関係は?
○Blue Project は B-Free の GUI ができるまでの継ぎなのでしょうか、
  それとも B-Free でずっと使っていくものなのでしょうか。

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