[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