nanogui: Thread: Re: What needs doing on Nano-X: harsh comments

On Saturday, May 15, 1999 6:34 AM, Alex Holden ####@####.#### wrote:
> The source to David's world atlas viewer is now at:
> http://linuxhacker.org/pub/nanogui/nano-X/
> http://linuxhacker.org/pub/nanogui/nano-X/
> ftp://linuxhacker.org/pub/nanogui/nano-X/
> ftp://linuxhacker.org/pub/nanogui/nano-X/
> 
> Unfortunately, it appears that the dreaded bit-rot has set into Nano-X
> rather badly,

	Geez, bit-rot?  Let's see, I've been working contributing like
hell to this project and now it's rotting?  When I started working on
this project, two weeks and 75 hours ago, v0.1 didn't run any mini-x
programs.  The entire purpose of all my work has been to get nanoX running,
systematically going thru the entire api, and implementing all sorts of 
things that were incorrectly changed in the conversion from mini-X.

The fact is, nanoX v0.1 *is* mini-x with much of the working mini-x 
driver stuff torn out, ported to linux.  The addition of the bogl libraries
was an admiral addition, but mini-x requires still alot more from the driver level.

In the mean time, I thought I caught nanoGui's stated mission, that what
we were after was a small graphics windowing system that could be used
for a *variety* of uses, not just running on linux.

Because of this, I thought that something really useful that could be added
would be a device-driver layer that would allow nanoX to run on truly different
systems (like ELKS, where sizeof(int) == 2, for instance).  So, I came up with
the idea that the low level graphics driver implementation could drive the 
upper-level thru "inherited" typedefs, thereby achieving full portability on 16, 
32 and other bit systems by merely recompiling.  (We don't yet aspire to binary
compatibility, as many programs will be all linked together anyway...)

So I did it.



 and a lot of things want cleaning up. In particular, David
> mentioned that the server's header file is included in the main header
> file, which it shouldn't be. Removing the inclusion revealed that the main
> header file has a million and one dependencies on the server header, when
> it shouldn't have any. Also various variables and type definitions have
> had their names shortened, for example GR_SCREEN_INFO has become
> SCREENINFO and GR_FONT_INFO has become FONTINFO, and both have been moved
> into the server's header file. 

Because this is DEVELOPMENT IN PROCESS, I have purposely changed
typedef names for structures that have been moved to the lower level, where
the sizeof(int) etc may be different, and changed them in the source files above, 
which forced me to look at every instance where these structures were used and why.
(I have since looked at every single line of source for mini-x, nanoX and understand *all*
of it).  This forces me to be aware of how the structure is used, which allows me to
keep the nanoX engine running BUGFREE, which, is a decent goal and beats
alot of printf debugging when in graphics mode...

A single "typedef SCREENINFO GR_SCREEN_INFO;" is all that's needed
to completely solve all this, and that was to be coming, except now
it appears that what we need is to be "mini-x compatible."  Which is 
probably a good thing since there's absolutely no demo programs
for mini-x or nanoX other than what I've seen in this distribution, and I've put
75 hours at least into just getting them to work.

I'm really glad you found some more mini-x programs that we can run.  I'm happy
to get them running.  I didn't realize we need to get them running without
any modifications to them, even at v0.4.  

Really, the structure definition should be
> in the main header file, and only a declaration of an instance of the
> structure should be in the server header file. Also, various things which
> were typedef'd previously aren't any more.

	Give me one day and I'll fix it up so you like it.  This makes
it harder during development to see what's changed and thus control bugs, though.


 Also, I don't like the obsolete
> 8*3 file name limitations caused by the DOS port. Really, they should be
> full, descriptive names with 8 unique characters at the start of the name
> (or use seperate directories, eg. instead of mou_dos.c and mou_gpm.c we
> could have mouse/dos.c and mouse/gpm.c).

	I thought the idea of doing a quick real-mode port of nanoX to
a 16-bit compiler served the community well.  There are many folks on the ELKS
list that would like to see this project run on ELKS.  I found it quicker
to write all the 16-bit code on DOS, which also runs in real mode.  Do we
really care about filenames or are we trying to build a graphics engine that
runs on multiple platforms?  I pick the multiple platforms.  BTW, I hate
8.3 filenames also.  

 Also, I think it would be a good
> idea to put all of the configurable things in a config.h header file
> instead of the Makefile. I also think it would be a good idea to put the
> client library in a seperate directory to the server code. I'd also like
> to integrate David's more advanced client/server code once he sends it to
> me. A lot of things could do with commenting better too.

	All these are probably good ideas.  I've been concentrating
on getting nanoX RUNNING with all features, which all of us will require, eventually.


> 
> I won't have the time to do much (if any) work on Nano-X until after
> Monday, but I should be able to spare a day or two after then if nobody
> else volunteers to do the big tidy-up.

	I'll "tidy" up the code.  It just so happens I put in another
20 hours this weekend which implemented all the SetCursor pointer changes,
and brought in Polygon draw, fill and Area read/writing and bitmaps. NanoX now implements
*all* of the features used by the mini-x demos.   I'll make sure they're tidy too.

> 
> Looking further ahead, Reintegrating the latest Bogl code, writing a
> SVGALIB driver, documenting the various APIs, porting GDK, porting or
> creating a smaller widget set for embedded applications, writing (or
> porting from W) a terminal emulator, and creating a window manager all
> need doing too. It would be nice if people would volunteer for specific
> jobs. I volunteer to do the documentation (since I seem to be a bit
> strange for a hacker in that I actually like writing documentation). Ben,
> could you possibly do the reintegration of your code? I'd like to do a
> window manager, but haven't decided 100% yet.

	Dave's original contribution of mini-x is a very large one.  NanoX
isn't today anything more than mini-x with a portable driver api.  In order to
do many of the things that this list is talking about, in a portable fashion,
rather than just re-writing X, there's still considerable driver architecture
design and discussion that is needed.  Especially since its only v0.4, and 
things are changing daily, at least at my house.  They're changing because
nanoX hasn't ever run the mini-x feature set, and the code is about 95% mini-x!

I wanted to expand on the mini-x feature set, by adding layers that more
people to use/contribute to/from, and also add fancier color and image support.
Hopefully all that can happen.


Sorry about the tone of this email, Alex, but my efforts haven't been called bit-rot
in quite a while, and I'm just not used to it.

> 
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

On Mon, 17 May 1999, Greg Haerr wrote:
> 	Geez, bit-rot?  Let's see, I've been working contributing like
> hell to this project and now it's rotting?  When I started working on

I'm sorry that you seem to have taken my comments as a personal insult; I
didn't mean it that way at all. I would define bit-rot as good code which
has become broken because it hasn't been updated when things change around
it. There seem to be several areas in Nano-X which have been affected by
this because you've been working so fast at implementing new things.

> this project, two weeks and 75 hours ago, v0.1 didn't run any mini-x
> programs.  The entire purpose of all my work has been to get nanoX running,

I knew that when I released it, I was just too busy to do anything about
it. I have some more time to spare now, so I'll be taking a more active
role (including carefully examining and testing patches before I include
them).

> In the mean time, I thought I caught nanoGui's stated mission, that what
> we were after was a small graphics windowing system that could be used
> for a *variety* of uses, not just running on linux.

Actually, I wasn't bothered about that at all myself. Where did I state
that? I think it would be great if it could be ported to non-Linux
platforms, as long as it doesn't suffer in general as a result.

> A single "typedef SCREENINFO GR_SCREEN_INFO;" is all that's needed
> to completely solve all this, and that was to be coming, except now

The point was that I don't see any reason to move away from mini-x's
naming convention of prefixing names with the layer that they belong to.

> I'm really glad you found some more mini-x programs that we can run.  I'm happy
> to get them running.  I didn't realize we need to get them running without
> any modifications to them, even at v0.4.  

I never said that we did.

> 	Give me one day and I'll fix it up so you like it.  This makes
> it harder during development to see what's changed and thus control bugs, though.

I don't see why. You mean you prefer to write code in a different style to
what is already there so that you can see that it is new?

> 	I thought the idea of doing a quick real-mode port of nanoX to
> a 16-bit compiler served the community well.  There are many folks on the ELKS
> list that would like to see this project run on ELKS.  I found it quicker
> to write all the 16-bit code on DOS, which also runs in real mode.  Do we
> really care about filenames or are we trying to build a graphics engine that
> runs on multiple platforms?  I pick the multiple platforms.  BTW, I hate
> 8.3 filenames also.  

I only said that I didn't like the fact that the filenames aren't very
descriptive, not that I thought doing a 16 bit port was bad. It's very
easily fixed (either by writing descriptive names which have at least 8
unique characters on the front, or by splitting things into directories
like I mentioned earlier, which is probably a good idea anyway).

> Sorry about the tone of this email, Alex, but my efforts haven't been called bit-rot
> in quite a while, and I'm just not used to it.

I think you just misunderstood what I meant by it.

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