nanogui: Thread: Cleaning up the source trees

Hi everyone :)

I'm finally reading mail again, and catching up on NanoGUI...

First of all: We need to get the source tree issue sorted out.
I sit here now with Nano-X-0.5pre3, Nano-X-0.61gh, and Microwindows 0.83

Before you ask, 0.61gh is AFAIK just an older version of what became
Microwindows, (Greg, correct me if I'm wrong, please :) and I'll be
using it only because it might be easier to reconcile parts of that
with Nano-X.0.5pre3 and go from there.

I'll be comparing them file by file, line by line, and start creating
patches. 

This is what I'll look for:
   - I'll fix the bugs I've found.
   - I'll look into some minor feature enhancements, with patches against
      both NanoX and MicroWindows.
   - In the case of small differences between the two, I'll suggest patches
      to one or the other, or both, to reconcile the differences
   - I'll suggest some reorganization of files to bring the trees close.
   - I'll attempt to document the remaining changes, so that we can discuss
      how we want to proceed with any big changes.

What I'd like, though, is that anyone else out there with extra time on
their hands look over the versions mentioned above, and start suggesting
improvements, and even better: post patches.

I'll start sending my patches by Alex and Greg soon, hopefully later today,
and smaller patches may be Cc:'d to the list. Hopefully we can resolve
this soon now - it's holding back development.

Regards,
Vidar Hokstad
Screen Media

On 28 Sep 1999, Vidar Hokstad wrote:
> First of all: We need to get the source tree issue sorted out.

I agree.

> I'll be comparing them file by file, line by line, and start creating
> patches. 

It would probably be easier to use the CVS repository instead... BTW, I'm
going to be disabling anonymous CVS access until I work out a secure way
to do it. Until then, I'll have a (probably nightly) automated snapshot,
and anyone who starts to work on the code can contribute patches to
somebody who already has access, and when they've proven they know what
they're doing, I'll give them write access. Whenever we get close to a
milestone in development, we can just fork a "code freeze" branch, tidy
that up, and release it as a stable version. If necessary, we can maintain
multiple branches for developing specific experimental features and
merge them with the main development branch when they stabilise.
This method has the advantage that developers never need to have to wait
around for a new release to get a feature or bug fix another developer has
just written, as well as having the additional advantages of version
control. It's also better for people who just want to contribute an 
occasional fix or new feature, that they can just check the tree out, make
the change and check it back in.

LinuxHacker is stored in a secure server room and backed up nightly to
DAT. If it needs it, I can upgrade it to a faster machine, but since it's
already managed to survive the SlashDot effect with a load average of
about 0.1, I don't think it'll need it unless we really start to hammer it
with continual checkins and checkouts (unlikely). It's currently connected
via a not very highly loaded 2Mb line (ISTR it's currently at less than
10% of capacity). Although I don't currently have enough time to work on
coding NanoGUI, I don't have a problem administering the CVS, mailing
list, web page, FTP site, etc.

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

On Tue, 28 Sep 1999 20:10:55 +0100 (GMT) you wrote:
>On 28 Sep 1999, Vidar Hokstad wrote: 
>> First of all: We need to get the source tree issue sorted out. 
> 
>I agree. 
> 
>> I'll be comparing them file by file, line by line, and start creating 
>> patches.  
> 
>It would probably be easier to use the CVS repository instead...

Maybe, but the problem here is that the trees split well before 0.5pre3,
and it's difficult enough merging at that point. Besides the work you
have done on overhauling the network code, has much else been added
since 0.5pre3? If it is only small changes, or localized in a few
places (like the network stuff), then using a CVS snapshot shouldn't
be a problem.

Vidar.

On 29 Sep 1999, Vidar Hokstad wrote:
> Maybe, but the problem here is that the trees split well before 0.5pre3,
> and it's difficult enough merging at that point. Besides the work you
> have done on overhauling the network code, has much else been added
> since 0.5pre3? If it is only small changes, or localized in a few
> places (like the network stuff), then using a CVS snapshot shouldn't
> be a problem.

I'm not really bothered how you go about the merging as long as the
results end up in the CVS tree. Greg changed all of the files to be 8.3
so that he can build it on DOS, but I think the directory tree I came up
with achieves that using more understandable names (eg. 
server/screen/bogl.c instead of server/drivers/scr_bogl.c). The build
system is more advanced than the one inherited from mini-X which Greg's
tree still has, though it should probably eventually be changed to use
automake, autoconf, libtool, and possibly gettext anyway. I split off
bogl, so instead of having a modified version of bogl included with the
Nano-X tree, it can simply use the standard, unmodified bogl library
(available elsewhere on LinuxHacker). Theoretically, all of the colour
depths that bogl supports should work, but I had some trouble persuading
my NetWinder to use anything other than 256 colours, and neither my old PC
graphics card, or the newer one I bought to replace it (and was supposed
to work with the atyfb driver but didn't) work in framebuffer mode at all.
There were some more minor changes as well, but it should be pretty
obvious what to do with them when you encounter them.

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

----- Original Message -----
From: Alex Holden ####@####.####
To: Vidar Hokstad ####@####.####
Cc: ####@####.####
Sent: Wednesday, September 29, 1999 8:11 AM
Subject: Re: Cleaning up the source trees


> Greg changed all of the files to be 8.3
> so that he can build it on DOS, but I think the directory tree I came up
> with achieves that using more understandable names (eg.
> server/screen/bogl.c instead of server/drivers/scr_bogl.c).

If there is a valid need for 8.3, then why not support it?

> I split off
> bogl, so instead of having a modified version of bogl included with the
> Nano-X tree, it can simply use the standard, unmodified bogl library
> (available elsewhere on LinuxHacker).

I like that idea.  However... aren't we going to have to modify bogl
eventually anyway?

Regards,
Brad

: I'm not really bothered how you go about the merging as long as the
: results end up in the CVS tree. Greg changed all of the files to be 8.3
: so that he can build it on DOS,

	Still worthwhile, IMHO, for realmode testing on bare hardware


 but I think the directory tree I came up
: with achieves that using more understandable names (eg. 
: server/screen/bogl.c instead of server/drivers/scr_bogl.c). The build
: system is more advanced than the one inherited from mini-X which Greg's
: tree still has, though it should probably eventually be changed to use
: automake, autoconf, libtool, and possibly gettext anyway.

	I revamped the make system after you changed it, as well
to allow multiple compilers on different environments like Linux and ELKS.
Requiring too many tools like automake etc can be a problem for folks
who want a small system to remain small and port easily to other systems,
something I think should remain a design goal.



 I split off
: bogl, so instead of having a modified version of bogl included with the
: Nano-X tree, it can simply use the standard, unmodified bogl library
: (available elsewhere on LinuxHacker). 

	I started with the idea of unmodified bogl, and pushed it for
awhile.  Unfortunately, with my redesigns for performance and other
reasons, the clipping code needed to be moved up out of the driver,
along with dropping all text draw and cursor support.  So we shouldn't
really be using unmodified bogl libraries unless you like slow speed.
In addition, there's some bugs in the text draw yline height stuff.  I think
Ben's done a good job with bogl, but our architecture is becoming different
than his problem was solving.  In addition, the VC switch code in nanoX
is all in the upper level, I've moved it to the driver level where it belongs.


Theoretically, all of the colour
: depths that bogl supports should work, but I had some trouble persuading
: my NetWinder to use anything other than 256 colours, and neither my old PC
: graphics card, or the newer one I bought to replace it (and was supposed
: to work with the atyfb driver but didn't) work in framebuffer mode at all.

	Yes, I can't get 24/32 bit color to work either.... :-(((
However, the nano-X pre3 doesn't support anything other than 16 color
anyway so that bogl code is essentially completely untested.



: There were some more minor changes as well, but it should be pretty
: obvious what to do with them when you encounter them.
:
	It would be nice if you could list them so that we can
figure out which tree to use.  I still think mwin 0.83 is the best starting
point, it's got loads of bugfixes, and many enhancements.  All it needs
is a few of your network fixes,possibly, and we're on our way...

Greg

On Wed, 29 Sep 1999, Bradley D. LaRonde wrote:
> > I think the directory tree I came up with achieves that using more
> > understandable names 
> If there is a valid need for 8.3, then why not support it?

I did support it, but using more understandable names...

> I like that idea.  However... aren't we going to have to modify bogl
> eventually anyway?

I don't know, I prefer the idea of improving bogl, but keeping it as a
seperate library rather than having to back-port the changes whenever Ben
improves the base Bogl library.

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

On Wed, 29 Sep 1999, Greg Haerr wrote:
> 	I revamped the make system after you changed it, as well
> to allow multiple compilers on different environments like Linux and ELKS.
> Requiring too many tools like automake etc can be a problem for folks
> who want a small system to remain small and port easily to other systems,
> something I think should remain a design goal.

For most of it, you only need bash (which works on DOS too, BTW) to build
something, M4, autoconf, et al are only needed to make changes to the
build system. It appears complex at first, but is a pretty powerful system
once you get used to it.

> 	It would be nice if you could list them so that we can
> figure out which tree to use.  I still think mwin 0.83 is the best starting
> point, it's got loads of bugfixes, and many enhancements.  All it needs
> is a few of your network fixes,possibly, and we're on our way...

I haven't got a problem with doing it either way. I think Vidar and the
other Screenmedia programmers will be doing most of the work, so it's up
to them.

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

----- Original Message -----
From: Alex Holden ####@####.####
To: Bradley D. LaRonde ####@####.####
Cc: ####@####.####
Sent: Wednesday, September 29, 1999 1:39 PM
Subject: Re: Cleaning up the source trees


> On Wed, 29 Sep 1999, Bradley D. LaRonde wrote:
> > > I think the directory tree I came up with achieves that using more
> > > understandable names
> > If there is a valid need for 8.3, then why not support it?
>
> I did support it, but using more understandable names...

Oh, OK, I misunderstood.  Sorry.  Thank you for clearing that up.


> > I like that idea.  However... aren't we going to have to modify bogl
> > eventually anyway?
>
> I don't know, I prefer the idea of improving bogl, but keeping it as a
> seperate library rather than having to back-port the changes whenever Ben
> improves the base Bogl library.

I prefer it also, but is it feasable?  The other thing is, how likely is it
that Ben will progress Bogl faster than Nano-X and/or Microwindows will
progress Bogl?  His comments on his web page lead me to believe that Bogl is
a pretty low priority for him, at least currently.


Regards,
Brad

Alex Holden ####@####.#### writes:

> > I like that idea.  However... aren't we going to have to modify bogl
> > eventually anyway?
> 
> I don't know, I prefer the idea of improving bogl, but keeping it as a
> seperate library rather than having to back-port the changes whenever Ben
> improves the base Bogl library.

BOGL is not going to be improved by me in the near future.  I have too
many other obligations, including classes, paid projects, and now a
couple chapters for a book.  I am more likely to pick up improvements
that NanoGUI makes than provide a newer version that needs to be
ported to NanoGUI.

Just my $.02.