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

[b-free: 1938] Re: BTK



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

   |> このあたり、いまいち理解ができないのですが、
   |> なんとなく伝わるのは
   |> 「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 の 1つの window = B-Free のディスプレイ」
に賛成、ということでしょうか。
この方法だと、X の 1つの window の中に箱庭のごとく
B-Free world が構築されることになるので、
X の window manager は全く関係なくなりますよね。

やすしさんがなぜ X の window manager にこだわっているのか
良く分かりません。
そもそも X の window manager の影響が及ばない window内だけを
使うので、X の window manager を新たに作るのは無意味に思います。

   |> B-Free が十分使えるようになって、開発に余裕が出てきたら
   |> 「X の 1つの window = B-Free のディスプレイ」
   |> もできるように改造するのも良いでしょう。
   |
   |B-Free良くわかってないので質問させてください。
   |Xの XCreateWindow()という関数にあたるものは
   |BTRON1では、wopn_wnd()だと思っていたのですが?

X は Xt をちょこっと使ったことがあるだけなので、
詳しいことはなにも言えません。
おおまかに見ると一緒なのですが、
X の window と BTRON1 のウインドウでは機能的に
異なる部分もあるので、単純に wopn_wnd() の引き数を
修正して XCreateWindow() を呼ぶだけではだめじゃないかと思います。

具体的には、パーツをウインドウに登録したり、
仮身や付箋をウインドウに登録したりする部分です。

   |>    |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しか使わないマネージャー達

もちろん2つあっても良いのですが、
ただでさえ遅れている B-Free の開発ですから、
できるかぎり開発力を集中したほうか良いのではないですか。
どちらを優先するか、と聞かれたら私ならディスプレイプリミティブを
利用するほうを優先しますね。

   |Xは、networkを使うために他のwindow systemよりもoverheadが多いです。
   |そこにAPI wrapperをかぶせてしまうとさらに重くなりますよね。
   |GUIの速度は、いちばんuser接しているところなのでできるだけ軽くしたい
   |と思っています。しかもGUIの処理だけで、CPU timeを消費したくない‥。
   |ただし、これの方法だと、落合さんが何度もいわれているように
   |moduleの構成が壊れます。つまり、XlibいがいのDPができたときに
   |manager達をそっちに移植するのは大変かも知れません。
   |
   |そこで、DP APIを使ったmanager達の方が、いいじゃないかという意見
   |ですよね?速度を取るか、モジュール構成を取るかですね。
   |もちろん DP APIようのwrapperはどちらをつくる場合でもつくります。

速度以外の問題もありますね。
複数の描画の整合性や、描画環境と GC との相互や整合性、
ウインドウ間のドラッグ、といった所は
Xlib を直接触るとなると解決が難しくなるのではないですか?

   |そこで、その辺はマネージャーを造る人が決めたらいいじゃないか
   |という、いい加減な考えなんですが‥‥、どうでしょう?

両方まぜこぜだと、上で指摘した問題の解決が
より難しくなるのでないでしょうか。

   |上に書いたようにmanger製作担当の人にまかせません?
   |
   |◇  Xlibを知っているので直接叩きたい。
   |◇  Xlibなんて知らない。
   |◇  wrapperを通すと遅くなる。
   |◇  wrapperを通しても、たいしてかわらない。
   |◇  XをつかったDPなんて、嫌いなのでDP APIを使ってマネージャーを書いたら
   |    俺がDPを書いてやる。
   |
   |まあ、いろんなシナリオが考えられますね‥。

私の身の振りかたを示しておきましょう。

○ ディスプレイプリミティブを X を使って作り、その他の GUI 関係マネージャは
   ディスプレイプリミティブを利用して作る。
               → 私もやりましょう
○ 各マネージャがそれぞれに Xlib を使って描画する、
               → 陰ながら応援します

です。

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