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

[b-free: 1970] Re: BTK





隆一です。


From: Yasushi Shoji <yashi@yashi.com>
Subject: [b-free: 1957] Re: BTK
Date: Wed, 29 Jul 1998 13:12:56 -0400

> やすしです。
> 
> From: Ryuichi Naitoh <naitoh_r@soft.hitachi.co.jp>
> Subject: [b-free: 1956] Re: BTK
> Date: Wed, 29 Jul 1998 18:12:37 +0900 (JST)
> 
> > 
> > 隆一です。
> > ...[snip]...
> > 
> > > すいません、書き方悪ぐちゃぐちゃでした‥。
> > > 
> > > iconifyは、window managerが行うことなので、applicationが使っているlibraryが
> > > Xlibであってもなくても、アイコン化はできない(しない)はずです。
> > > 
> > > で、スクロールバーの件は、B-FreeOS仕様のGUIは、色々なマネージャーたちが
> > > parts, window panelなどを提供してますが、X=GUIとしてしまうとBTRONの
> > > スクロールバーが含まれていない、と言うことです。
> > 
> > うーむ、ということはアプリケーションが Xlib (に相当する機能) 
> > を使って X サーバに直接アクセスすることは難しいということですか?
> 
> 難しくは、全然無いのですが、そのapplicationはBTRON仕様とかb-free仕様とは呼べないですね。個人的には、1bでコンパイルできるsourceに#includeくらいを付け足しただけでXがある環境でもコンパイルできるといいな〜と思っています。
> 
> X + Xlib + display-primitive wrapper + 各manager = GUIみたいな感じですかね。

問題を 2 つに分けた方がいいんじゃないでしょうか?

1) BTRON OS 上の GUI
2) X の上で動く BTRON エミュレーション環境

この 2 つを同時に議論するとわけがわからなくなってしまいます。

私のコメントは、あくまで「1) BTRON OS 上の GUI」に限定した話でした。
「2) X の上で動く BTRON エミュレーション環境」については、全然考えてい
ません。

「1) BTRON OS 上の GUI」を構築するときに、「2) X の上で動く BTRON エミュ
レーション環境」については考えなくてもいいのではないでしょうか?
「2) X の上で動く BTRON エミュレーション環境」をできることを目的に、
「1) BTRON OS 上の GUI」の構造を作るのは本末転倒のように思います。



> > パーツ、パネルのような機能を提供するものを X サーバに被せる必要があり
> > そうですね。
> 
> それらが、外殻マネージャー達ですね。parts manager何かは、shared library
> でも、問題ないと思います。

うーむ、やすしさんの考えているマネージャの構成はどういうものでしょうか?
どのマネージャをライブラリで構成するのかよくわかりません。


> >    アプリケーション -> [パーツ/パネルマネージャ] -> X サーバ
> > 
> > のような感じでしょうか。ここで、パーツ/パネルマネージャとありますが、
> > もちろんウィンドウ関係をすべてまかなってしまうこともできると思います。
> 
> application  --> 各 manager API --> manager
>       |                              |
>       |           +------------------+
>       |           |                  | ←個人的にこのアクセスは許したい。
>  +-------------------------+-------------+
>  |display-primitive wrapper|             |
>  +-------------------------+             |
>  |                Xlib                   |
>  +---------------------------------------+
> 
> こんな感じですか?user level applicationは、Xlibを意識せずにいつもどうり?
> プログラムを書くことができるのが第一条件だと思います。(まあ、Xlibを使い
> たい人は、使ってもいいですが‥)

アプリケーションが X を意識しないでプログラムできるというのは、私も賛
成です。X (というか X が下の層にあること)は、アプリケーションからアク
セスできないようにしてしまう方がいいんではないでしょうか?


> で、落合さんとの話で問題になったのがmanagerも、display-primitive*だけ*
> に、accessさせる方がいいのでは?と言う所ですね。

ええ、そうだと思います。


> > また、パーツ/パネルマネージャが呼び出す部分(X サーバに相当)を、入れ換
> > え可能にすることを考えると、X サーバの上にディスプレイプリミティブを被
> > せることにした方がよさそうです。それすることによって、Blue プロジェク
> > トでは、X サーバを移植するだけでよくなり、パーツ/パネル等の機能につい
> > ては、他のサブプロジェクトに負荷を分散することもできるようにもなります。
> 
> 別のプロジェクトにしてしまうのもいいかも知れません。そして、それぞれの
> マネージャーを作る人たちが、何を使って書くかということを決めていけば
> いいのではないでしょうか?

うーむ、そこでディスプレイプリミティブだけを使うか、それとも、それ以外
のものを使うかという選択があるのだと思います。
ディスプレイプリミティブ以外のインタフェースを使うならば、その仕様を明
文化する必要があると感じています。もし、仕様を明確にせず、ディスプレイ
プリミティブ以外の機能だけを提供してしまうと、上に載るはずのマネージャ
が作りようがなくなってしまいます。



p----------------------------------------------------------------------q
| FROM R.Night                                                         |
| E-mail:                                                              |
|         rnaitoh@st.rim.or.jp                                         |
| Key fingerprint = 89 EB 77 95 40 C0 3C CC  37 A1 A7 FA 1C 66 FF D0   |
b----------------------------------------------------------------------d