[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[b-free: 1971] Re: BTK
やすしです。
From: Ryuichi Naitoh <naitoh_r@soft.hitachi.co.jp>
Subject: [b-free: 1970] Re: BTK
Date: Thu, 30 Jul 1998 17:10:19 +0900 (JST)
>
>
> 隆一です。
>
>
> 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 を、移植したあと、その上で動くものは、すでにXがある環境で
作れるのでは?どうして本末転倒なんでしょうか?開発時間の短縮にもなるのでは?
# ?ばっかり‥‥‥m(__)m
> > > パーツ、パネルのような機能を提供するものを X サーバに被せる必要があり
> > > そうですね。
> >
> > それらが、外殻マネージャー達ですね。parts manager何かは、shared library
> > でも、問題ないと思います。
>
> うーむ、やすしさんの考えているマネージャの構成はどういうものでしょうか?
> どのマネージャをライブラリで構成するのかよくわかりません。
parts managerって、motifみたいなことをやっているのではないのですか?
勉強不足で、まだ理解してません。
> > > アプリケーション -> [パーツ/パネルマネージャ] -> X サーバ
> > >
> > > のような感じでしょうか。ここで、パーツ/パネルマネージャとありますが、
> > > もちろんウィンドウ関係をすべてまかなってしまうこともできると思います。
> >
> > application --> 各 manager API --> manager
> > | |
> > | +------------------+
> > | | | ←個人的にこのアクセスは許したい。
> > +-------------------------+-------------+
> > |display-primitive wrapper| |
> > +-------------------------+ |
> > | Xlib |
> > +---------------------------------------+
> >
> > こんな感じですか?user level applicationは、Xlibを意識せずにいつもどうり?
> > プログラムを書くことができるのが第一条件だと思います。(まあ、Xlibを使い
> > たい人は、使ってもいいですが‥)
>
> アプリケーションが X を意識しないでプログラムできるというのは、私も賛
> 成です。X (というか X が下の層にあること)は、アプリケーションからアク
> セスできないようにしてしまう方がいいんではないでしょうか?
混乱を防ぐ以外に、Xlib の interfaceを閉じてしまって良い事って何ですか?
せっかくあるものをわざわざ塞ぐのが、何故だかわかりません。
> > で、落合さんとの話で問題になったのがmanagerも、display-primitive*だけ*
> > に、accessさせる方がいいのでは?と言う所ですね。
>
> ええ、そうだと思います。
>
>
> > > また、パーツ/パネルマネージャが呼び出す部分(X サーバに相当)を、入れ換
> > > え可能にすることを考えると、X サーバの上にディスプレイプリミティブを被
> > > せることにした方がよさそうです。それすることによって、Blue プロジェク
> > > トでは、X サーバを移植するだけでよくなり、パーツ/パネル等の機能につい
> > > ては、他のサブプロジェクトに負荷を分散することもできるようにもなります。
> >
> > 別のプロジェクトにしてしまうのもいいかも知れません。そして、それぞれの
> > マネージャーを作る人たちが、何を使って書くかということを決めていけば
> > いいのではないでしょうか?
>
> うーむ、そこでディスプレイプリミティブだけを使うか、それとも、それ以外
> のものを使うかという選択があるのだと思います。
> ディスプレイプリミティブ以外のインタフェースを使うならば、その仕様を明
> 文化する必要があると感じています。もし、仕様を明確にせず、ディスプレイ
> プリミティブ以外の機能だけを提供してしまうと、上に載るはずのマネージャ
> が作りようがなくなってしまいます。
各マネージャーを使う application は、manager が、何をしているか気にする
必要はないんですよね?どうして、マネージャーがどうやって下位層と繋がって
いるかが、そんなに重要なのかが、今一つわからないんですけど‥。
#すでに議論にでた、モジュール化などの話し以外にです。
display-primitive APIは、絶対的に必要です。で、すでにあるX libが使えると
混乱が起きるかも知れないのもたしかです。でも、混乱しそうな人は display-
primitive APIだけを使っていれば問題ないのではないですか?
あ、でも、types.hとか、全然違うから、やっぱり使えない方が安全かな?
でも、systemが、それで止る訳じゃないしね‥。
#すごい眠いので、呆てるかも‥。
#起きて読み直したら、自己REしてしまうかも知れない‥‥
#と、思いつつも、出してしまおう‥。
--
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