[GRASS5] Darwin Pre1 NVIZ

[Eric G. Miller]

On Wed, Jun 06, 2001 at 04:15:50AM +0100, Glynn Clements wrote:
> Note that Mesa includes both libGLw.a (widgets-sgi) and
> libMesaGLw[M].a (widgets-mesa). The README for widgets-mesa says:
> 
>   * Provide a GLwDrawingArea widget which is 100%ly compatible with
>   SGI's widget.  Applications should port over with (almost) no
>   changes to the source code.
> 
> It's the "almost" which concerned me.
> 
> However, the original SGI version only has a libGLw.a. The Mesa
> version used to be this way, but it was changed (by me) to put the
> Motif version into a separate library (otherwise you had to link
> against libXm even if you only used the non-Motif widget).
> 
> XFree86 4.0.* again includes both Motif and non-Motif versions in its
> version of libGLw.a. However, even if you add a libGLwM.a symlink,
> configure won't detect it because, in that version,
> GLwCreateMDrawingArea() is a macro which expands to either
> GLwCreateM1DrawingArea() or GLwCreateM2DrawingArea() depending upon
> whether XmVERSION is 1 or 2.

Hmm, well I didn't know that much about the widgets.  I only hacked the
configure script to try to find the libraries and includes...

> Anyway, all of this is moot unless g3d finds its way back into the
> source tree.
> 
> So, should I get rid of the GLw checks altogether? Or is g3d's absence
> likely to be only temporary?

I think we should at least comment out the "widgets" parts in
configure.in with a little note.  On a related matter, there are a
couple places where the "g3dcell" shows up (like g.remove output).  It
might be a good idea to find those and disable them for the time being,
so user's don't get confused ideas about missing some functionality.

It's a bummer that the 3d stuff isn't working better, but there seems to
be an uncorrected discrepency about what exactly x,y, and z mean versus
regular 2d rasters (I understand y and x are reversed, or some such).
Also, there's only a bare minimum of modules to use g3d files
(r3.showdspf was never intended for end users, for instance).  Since, no
one wanted to dig into the g3d library code, the problem remains
unresolved.  I've looked at it, but never fully grok'ed it's cache
handling code.  It also has a totally different method for encoding data
compared to the two main methods (+backward compatibility) used in libgis 
for 2d rasters.

As a kind of side note to this all, I think the use of a file descriptor
as the "handle" for rasters limits some forward capabilities.  There
shouldn't be any module that actually tries to directly read/write a
raster file.  But, using a file descriptor makes it impossible to do
things like "catalogs" or segmented raster files -- things that would be
very useful to have.  Maybe, it'd be possible to substitute some kind of
integer id for the file descriptor, then the library could transparently
handle such things.  Anyway...

-- 
Eric G. Miller <egm2 at jps.net>