nanogui: Thread: Status?

On Tue, 7 Sep 1999, Vidar Hokstad wrote:
> 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).

Can you post more details?

> Have you two discussed any merging of the trees?

Yes, I was going to merge Greg's changes into the CVS tree, but I only got
part way before work got on top of me again. I would have preferred to
have done it incrementally (lots of small understandable patches instead
of "Here's my code. It has so many changes in it since I last sent you
a patch that you may as well throw away your own tree and use mine
instead"), but I still think it's worth merging greg's tree into mine
(with the new build system, and the seperate Bogl library) rather than the
other way around.

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

On Tue, 7 Sep 1999, Vidar Hokstad wrote:
> On Tue, 7 Sep 1999, Greg Haerr wrote:
> > 	I think the best way to go for nano-X would be the approach I took
> > for MicroWindows.
> I'm not sure I agree with this. X is fairly complex compared to what it
> should be possible to run Mozilla on.

I agree. X is a very large, complex API. I think we should just extend the
Nano-X API as much as is needed, and avoid the more complex parts of X.

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

On Tuesday, September 07, 1999 2:03 PM, Alex Holden ####@####.#### wrote:
: On Tue, 7 Sep 1999, Vidar Hokstad wrote:
: > On Tue, 7 Sep 1999, Greg Haerr wrote:
: > > 	I think the best way to go for nano-X would be the approach I took
: > > for MicroWindows.
: > I'm not sure I agree with this. X is fairly complex compared to what it
: > should be possible to run Mozilla on.
: 
: I agree. X is a very large, complex API. I think we should just extend the
: Nano-X API as much as is needed, and avoid the more complex parts of X.
: 
	
	I think you all may not get my point.  First, I suggest Xlib, not X.
Xlib is the much smaller subset of X that deals with really low level drawing.
Secondly, remember that nano-X is basically lifted wholly from mini-X.  It's
inventor used almost exactly the same function names and arguments as Xlib
when creating the API.  So it already is almost there.  Except that he changed
the names to GrYYY rather than XYYY.  If the names were Xlib compatible,
a large number of low-level X programs would port with very few changes.
The point is that the nano-X api is *already* Xlib compliant, but noone
realizes it, and that further slows development.  I'm not suggesting that
the API has to remain Xlib compatible, but when you've already got 90% of
your API compliant, why not?

Greg

On Tue, 7 Sep 1999, Greg Haerr wrote:
> 	I think you all may not get my point.  First, I suggest Xlib, not X.
> Xlib is the much smaller subset of X that deals with really low level drawing.

I know. I was talking about Xlib too. We did consider changing the
function names to closer match X, but it might confuse people into
thinking that Nano-X is supposed to be a faithful clone of X, which it
isn't. There are a lot of things which can be done (and are done) more
simply than how X does it.

> The point is that the nano-X api is *already* Xlib compliant, but noone
> realizes it, and that further slows development.  I'm not suggesting that
> the API has to remain Xlib compatible, but when you've already got 90% of
> your API compliant, why not?

It isn't anywhere near that close, plus the behaviour is somewhat
different and is likely to become more so as we progress.

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