Vidar Hokstad ####@####.####
7 Sep 1999 19:30:03 -0000
On Tue, 7 Sep 1999, Greg Haerr wrote:
> : I'm working on a widget set for Nano-X now (based on some code Alexander
> : Peuchert wrote and was nice enough to send me), and during that work I've
> : found quit a bit of bugs, in particular in the network support...
> The network support has never worked, and will regularly core dump.
Actually, it works just fine for me with the 0.5pre3 release, and a couple
of minor bug fixes.
> Very extensive palette handling is completed in the MicroWindows 0.82
> release. This version also supports the nano-X api. All the color handling code
> is written in the "portable across user-api's" middle device layer, devdraw.c.
> Basically, the color model was enhanced to full RGB support in 0.82, with
> the GR_COLOR expanded from an unsigned short "ansi color number" from 0-15
> to an unsigned long RGB color. The system is compiled with 16 color or
> 256 color palette tables, and then the requested RGB color is distance-cubed
> compared with the palette. Various mechanisms exist for remapping the system
> palette with the nano-X palette, for use with 256 color pictures. My work
> was initially with MicroWindows in this area, and I completed all the work
> for color bitmaps. The system should also work with truecolor hardware,
> but I've never been able to get the framebuffer stuff to work in truecolor.
This sounds like the right way to go... The mess of a color system in X
doesn't exactly contribute to small programs :-)
> : So, is anyone working on modifications, fixes etc. to Nano-X that aren't
> : publicly available yet? I'd love to take a look at any work in
> : progress, and help out if possible. And what is the current official tree,
> : and who would be the right person(s) to send patches to?
> Alex maintains a tree for the network code he started working
> on some months ago.
I've taken a look at that, and I'm debating whether I should try to
complete it, or write something along the same line (I have some ideas
that should be about as flexible, but save quite a few function calls,
as well as use less memory).
> My tree contains many enhancements, including
> color management, cursor management, ELKS port, SVGAlib port, etc.
> See the ChangeLog for details. The Microwindows project also entailed
> quite a few changes to nano-X that will be required when someone
> writes a window manager. (I wrote on for Microwindows, but was waiting
> for others for nano-X.)
I guess it would be about time to try to merge as much as possible
together. It's a nuisance to have two trees (and as I've mentioned I've
got some changes lieing around too).
Have you two discussed any merging of the trees?
> : My bug fixes are mostly against 0.5pre3, but most of them also apply to
> : the Microwindows release (allthough for some reason my widget set and test
> : program won't work at all with the Microwindows version of Nano-X even
> : with the bugfixes). I also have a mostly working GGI driver for 0.5pre3.
> The color model changed, and you can't use simple integers for
> colors anymore. In many cases, the simple integers 0-15 come out quite
> black ;-) The MicroWindows tree has no reported/known bugs.
Aha... I guess that might be part of the problem. But it also locks up in
some cases that work fine with 0.5pre3. But then I use the network code,
so that might be the cause of the problems.
Vidar Hokstad ####@####.####
Director of Technical Development, Screen Media AS