nanogui: Status?
Subject:
RE: Status?
From:
Greg Haerr ####@####.####
Date:
7 Sep 1999 18:13:57 -0000
Message-Id: <01BEF929.BF260D70.greg@censoft.com>
: The code that nanogui is based on was for an EGA system, which kind of limited
: the colour issue.
Not quite. The nanogui color model is based on the RGB system,
running on palettized hardware. On truecolor systems, the color could be passed
thru. Currently, all color management is done on top of the hardware, with a single
driver-level setpalette() call to map RGB entries.
It does need proper colour stuff adding. Nobody is doing
: it right now. Similarly for size reasons server side pixmaps werent in
: the original (and it would be good to keep them optional)
Color bitmaps (windows) are implemented. Yes, someone does
need to implement color pixmaps (X). This should be easy.
: 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...
Greg
