nanogui: Thread: Another major nano-X release

: What's wrong with the pre release system? You think I should make
: everything should work perfectly before releasing a prerelease? If I did
: that, they may as well be stable versions, and the time between releasing
: them would get very long.

There's only been three people who have written any code for this project, since
you released it as nano-X version 0.1.  I have made all the four major submissions, 
one approximately each week.  Vidar has contributed a ggi driver.  And you have
decided that you didn't like my directory structure, changed it, and then started
a prerelease system because the work you're working on didn't quite work before
you wanted to release it.

In the mean time, I've been programming quite heavily.  I believe at this stage
that the releases should absolutely stable, and there shouldn't be a long time
between them, either.  Actually, I believe in your project and have been working
very, very hard to get this thing off the ground.

It doesn't appear that everyone agrees on what it takes to get a new graphical system
off the ground, when people want to work on both high-level api's and low-level
driver implementation.  My approach is that both should be able to happen, and
that's why I've worked so hard to get this project to a level where that can happen.  In
my mind, that means we need a driver interface that fully supports one high level
api, and a reference driver set that completely implements everything.  In addition,
I think that multiple platforms are a must to get nano-X the juice it needs to get
more attention.  Additional things like blitting are nice, but not required.

In any case, my version 0.5 release almost accomplished these goals.  My
next release, details following, accomplish the following additional objectives:
The entire high-level api is implemented.  The entire nano-X system can run on
multiple platforms, with native hardware drivers for VGA, MS/PC mouse, and PC keyboard.
Completely working low-level drivers are implemented for screen, keyboard, and mouse
for linux 2.x, linux 1.x, elks, and dos.  A new nano-X font format, 16 bits wide,
allows fonts independent of the driver implementation to be used, as well
as specific driver fonts.  Converters for bdf and PC ROM fonts are written.
This allows folks to take nano-X and run it on any linux system, not just new ones,
as well as run it on other operating systems or palmtops, etc.

Following is the feature set for my version 0.6:
Version 0.6 - 23nd May 1999 - ####@####.####
	* Updated bugs from new mini-x distribution
	* Wrote int33 mouse driver for dos
	* Wrote a portable vga 4 plane driver for dos, elks
	* Updated dos driver to support XOR,AND,OR draw modes
	* Wrote routines for ELKS port, compiled with bcc
		uses new serial mouse driver, vga 4 plane driver and bios kbd
	* Added check for FRAMEBUFFER environment variable for /dev/fbX open
	* Added clipped text output routines, using bitmaps
	* Added GetCharBits device driver entry point, removed DrawText
	* Added new nano-X font format, wrote conversion programs to
		convert bdf fonts and PC ROM bios fonts.  There is no longer
		any dependency on the BOGL font structure.  Any number
		of fonts are supported.  Fonts use min 16 bits/scanline.
		Convbdf and convrom.exe are included.
	* Created rom 8x16, 8x16 fonts.
	* Entire nano-X can run on only drawpixel and readpixel if required
		(I hope people realize the importance of this)
	* Documented scr_bogl.c (bogl), and scr_bios.c (bios) drivers.
	* Ported world program to 16 bit systems
	* Added pc, microsoft and logitech direct serial driver mouse support
	* Wrote SVGAlib screen driver, will now run on *any* linux system,
		not just v2.x framebuffer systems.  scr_svga.c.
	* Nano-X is now completely self contained, if desired, in that
		there are hw drivers for screen, mouse, and keyboard
		that don't require other software to be running

The code is completely debugged.  It all works.  The makefile allows you
to build nano-X with the vgalib driver for linux 1.x machines.  Or to use the direct
serial mouse driver instead of gpm.  All the drivers have been tested, on different operating
systems as well.  The UNIX makefile allows an ELKS port to be compiled, as well.

Unfortunately, this code isn't integrated with the pre-release system that Alex has
just generated.  He indicated that if I can't wait for the pre-release stuff to work, I should
work off the last major release, which was my 0.5, or 0.5pre1.

The only thing that I've not been able to integrate is the new combined framebuffer
driver, as my system won't run in anything but 4-planes planer or 8-bit packed pixel mode.

I would like to see this released as a major release.  It will be my last major submission,
as my objectives are completed.  I am going to be working on a Win32 api
running on top of the nano driver level.  The first version is near ready now.

Greg

On Mon, 24 May 1999, Greg Haerr wrote:
> decided that you didn't like my directory structure, changed it, and then started
> a prerelease system because the work you're working on didn't quite work before
> you wanted to release it.

I don't know why you don't see the value of having two development tracks,
stable and development. It allows more than one programmer to work on a
project at the same time. The fact that your code and mine is so far apart
from each other is largely because we've both been working on seperate
trees, with no periodical synchronisation between them.

> that the releases should absolutely stable, and there shouldn't be a long time
> between them, either.  Actually, I believe in your project and have been working

I don't think it's really practical to only release stable releases, _and_
release them quite often, unless very little changes between them.

> I would like to see this released as a major release.  It will be my last major submission,

I'll put it up as a nano-X-0.4-greg patch so that people can get it if
they want it, and continue manually integrating it into the main tree as I
work towards the full 0.5 release.

BTW, in future I'd like to start making proper use of CVS to avoid these
multiple developer problems.

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

: I don't know why you don't see the value of having two development tracks,
: stable and development. It allows more than one programmer to work on a
: project at the same time. The fact that your code and mine is so far apart
: from each other is largely because we've both been working on seperate
: trees, with no periodical synchronisation between them.

	I was just trying to move your project forward, Alex.  Now that
you're rapidly moving the project forward, this won't be an issue.

: 
: I'll put it up as a nano-X-0.4-greg patch so that people can get it if
: they want it, and continue manually integrating it into the main tree as I
: work towards the full 0.5 release.

	It's not a patch.


: 
: BTW, in future I'd like to start making proper use of CVS to avoid these
: multiple developer problems.

	Probably good idea.  I write a lot of code, though,
and this has allowed me to move the project miles forward quickly.
Since it appears our interests are diverging, this will be my last major submission.

Greg

On Mon, 24 May 1999, Greg Haerr wrote:
> 	I was just trying to move your project forward, Alex.  Now that
> you're rapidly moving the project forward, this won't be an issue.

Great, thanks.

> : I'll put it up as a nano-X-0.4-greg patch so that people can get it if
> : they want it, and continue manually integrating it into the main tree as I
> : work towards the full 0.5 release.
> 	It's not a patch.

I'll put up a tarball too, but patches are better not only because they're
smaller but because you can read through them and see what's changed.

> : BTW, in future I'd like to start making proper use of CVS to avoid these
> : multiple developer problems.
> 	Probably good idea.  I write a lot of code, though,
> and this has allowed me to move the project miles forward quickly.

Yes, CVS can be a bit of a pain to use, but it's certainly useful when
several people are trying to work on the same code at once.

> Since it appears our interests are diverging, this will be my last major submission.

That's okay. I look forward to seeing your NanoWindows project :)

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