nanogui: Status?
Subject:
RE: Status?
From:
Vidar Hokstad ####@####.####
Date:
7 Sep 1999 19:37:44 -0000
Message-Id: <Pine.LNX.4.10.9909072124330.24579-100000@a.ncg.net>
On Tue, 7 Sep 1999, Greg Haerr wrote:
> : Mozilla is almost ready to be hackable to Nanogui. The Mozilla drawn widgets
> : (eg the Xlib mode) are about to get turned on properly. At that point you
> : don't even need a toolkit as such to get Mozilla up
> :
> I think the best way to go for nano-X would be the approach I took for MicroWindows.
> That is, the nano-X api should be a "completely compatible" api with some standard
> api. Xlib is the one that comes to mind. In this fashion, there's little time spent
> debating api's, instead more time implementing them. This flushes out design
> issues in the basic engine. At the same time, reference implementations of Xlib
> abound, and the only decisions is which portions to implement when. It is surprising
> how much can run on top of even a partially-implemented graphics api.
> This method allows alot of code to be moved over quickly. Certain
> components can then be rewritten if an api "shortcut" is taken, rather than
> writing them from scratch...
I'm not sure I agree with this. X is fairly complex compared to what it
should be possible to run Mozilla on.
The color model is one example. Other things, such as line drawing,
doesn't exactly make it any prettier.
But as soon as the Gfx widgets (widgets drawn with the Mozilla Gfx
classes) are turned on by default only the basic graphics code will have
to be reimplemented to get Mozilla running. Also, parts of the graphics
code needed, such as region handling, are readily available in other open
source libraries, and are fairly generic.
Sure, a Xlib layer would make it easier to port other stuff, but I don't
think we should attempt to use the Xlib API by default.
Regards,
Vidar Hokstad ####@####.####
Director of Technical Development, Screen Media AS
