nanogui: Re: nanoGui development


Previous by date: 3 May 1999 22:03:08 -0000 Re: nanoGui development, Greg Haerr
Next by date: 3 May 1999 22:03:08 -0000 Re: nanoGui development, Greg Haerr
Previous in thread: 3 May 1999 22:03:08 -0000 Re: nanoGui development, Greg Haerr
Next in thread: 3 May 1999 22:03:08 -0000 Re: nanoGui development, Greg Haerr

Subject: RE: nanoGui development
From: Alex Holden ####@####.####
Date: 3 May 1999 22:03:08 -0000
Message-Id: <Pine.LNX.4.04.9905032249570.363-100000@hyperspace>

On Mon, 3 May 1999, Greg Haerr wrote:
> 	Thanks for answering so quickly.  It seems like you've got no
> problem with me moving this stuff forward, since you've got other projects and
> exams.  I've been looking for just this kind of initial project, since I'm into
> "small" systems, guis, compiler/interpreters.

Yep, no problem. I find it interesting making systems which require less
than 64MB Ram and a 1GB hard disk to run optimally too :) I've spent quite
a bit of time developing for small PICs, and it's amazing what you can do
with a few hundred bytes if that's all you have.

> 	I'll get all this stuff working, and change a few things so that
> the project can be compiled as client/server, as well as a non-network version.  I also
> have some ideas on how to better integrate the "screen drivers" (bogl) so that
> different bits-per-pixel etc can be supported, and that the screen driver interface
> is extremely well defined.

Okay, I was talking to someone else who has also ported mini-X to
Linux-2.2 framebuffer, but done it without bogl. He was interested in
merging his work with nano-X, but I haven't been able to contact him
lately as his DNS is dead. If his code is a better way of doing it than
bogl, I might use that instead, but I haven't seen it yet. Certainly a way
of supporting more bit-depth levels, preferrably in the same binary with
autodetection, is needed.

> 	I got into this because I've been watching the ELKS development work,
> and they were wondering whether this work could used for their project.  The answer

That's something I've never played with...

> is absolutely yes, although some direct real-mode linked in frame-buffer support would
> be necessary.  To get ready for that, and the associated possible 16-bit compiles, this
> project should use typedefs for the internal types, like colors, and x,y,w,h stuff.  I would
> like to typedef all that stuff.  All-in-all, this would allow for nanoGui to become quite
> portable.

Yes, quite a lot of it is typedef'd to start with.

> 	On another note, it took me quite a while to figure out the v2.2 framebuffer support,
> since I was running v2.0.  It might be a good idea to include some setup info in your
> FAQ.  With the low-level interface well implemented, it would also be fairly straight-forward
> to include support for vgalib, which would allow older v2.0 linux users to run this.

I never used the framebuffer on a 2.0 kernel... Perhaps a pointer to the
Alex Buell's Framebuffer-HOWTO would be a good idea?

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------


Previous by date: 3 May 1999 22:03:08 -0000 Re: nanoGui development, Greg Haerr
Next by date: 3 May 1999 22:03:08 -0000 Re: nanoGui development, Greg Haerr
Previous in thread: 3 May 1999 22:03:08 -0000 Re: nanoGui development, Greg Haerr
Next in thread: 3 May 1999 22:03:08 -0000 Re: nanoGui development, Greg Haerr


Powered by ezmlm-browse 0.20.