[GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows

[Paul Kelly]

On Tue, 21 Aug 2007, Michael Barton wrote:

>>
>> Hello Moritz,
>> Works for me starting it both those ways, and also from command-line. I
>> even tried make distclean and compiling from scratch in case there was
>> something I'd manually fixed that kept it working on my system. So I don't
>> know what could be up with yours. Maybe you have an old nviz.exe lying
>> around in your PATH somewhere that is getting picked up when the GUI runs
>> "nviz", instead of Glynn's new nviz.bat?
>>
>> A couple of side-notes though:
>> 1) In general the GUI is terrible at catching and reporting errors from
>> modules it calls in the background and this leads to cryptic error
>> messages or nothing happening all over the place. IMHO it is a really
>> pervasive problem that definitely needs fixed in the next GUI. Hopefully
>> it already is there (ISTR discussions about every call to a GRASS module
>> going through some other function where the error trapping could
>> presumably be added, to avoid code repetition).
>
> Actually, error trapping is pretty good in the GUI now, except for NVIZ (but
> which doesn't run much in the way of GRASS commands anyway). There are traps

Well maybe I was being a bit overly dramatic, but running
  grep "exec " *.tcl | grep -v catch | wc -l
in the gis.m directory still reveals 72 lines where exec is used without a
corresponding catch. Not very scientific and perhaps not important in most
cases - but if a single command (be it a GRASS module or system command)
is not available or not working for some reason it could really make the
difference between somebody tearing their hair out for a day or finding 
the source of a problem quickly.

> around all (or perhaps nearly all) GRASS commands that run through the GUI
> that will kick out any GRASS errors to the terminal or a message box.

Note that I'm not talking here about "expected" errors that come from bad 
user data or some kind of error that's handled by G_fatal_error() or 
whatever inside a GRASS command - I'm thinking more of unexpected errors 
caused perhaps by a library not being installed properly or files being 
corrupted on the user's system. Perhaps it's not a big deal right now and 
perhaps Python will make it much easier to do than Tcl or even do it 
automatically.

[...]

>> 2) When the displayed layers start up in NVIZ the colour of the displayed
>> vector map isn't preserved. I'm guessing this is because it can't be
>> specified on the command-line, but perhaps the code that starts NVIZ using
>> the displayed layers should write a temporary NVIZ state file and then
>> start NVIZ with that file? I've no idea how complicated that would be to
>> do though. E.g. might be better only focussing on it in the new GUI.
>
> This probably complicated, but I really don't know as I don't understand
> these files. Probably Bob or Helena does.

I had a quick look and they're straightforward enough as they correspond 
directly with the widgets in the panels in NVIZ. But could do with much 
better documentation. And not worth working on either seeing we're looking 
to get rid of NVIZ and replace it with a better interface to the gsurf 
library.

>> I would love the functionality of NVIZ (most of which is implemented using
>> the gsurf library AIUI), to be available from the command-line as well as
>> through the Tcl/Tk interface. Would be cool to be able to generate 3-D
>> images with specified observer location and attitude and so on from a
>> shell script (or scripting language of your choice), rather than having to
>> do it with Tcl scripting in NVIZ.
>
> Issuing commands to have an output file created is not a problem. Getting an
> image to *display somewhere* is the problem. NVIZ is a display/visualization
> application which displays images in a TclTk/OpenGL canvas. That is how the
> rest of the GUI works now (i.e., a TclTk canvas, albeit without openGL). To
> display something in a TclTk canvas requires TclTk scripting. A wxPython
> canvas requires wxPython scripting; a Java canvas needs Java scripting, and
> so on. The only reason it appears that you can type a command and have it
> display in GRASS outside of this is that GRASS also has display drivers that
> can send an image to an old-style xterminal (textronic emulation I think).
> In other words, displaying an image in a "GRASS canvas" requires GRASS
> scripting.
>
> You could write code that would let you type in stuff and translate that
> into TclTk script commands needed to display the output in a TclTk canvas.
> We've done with with wxPython, where it's a bit easier to do, but still
> something of a chore (since modern GUI's usually assume that you want to use
> a GUI to display something in their canvases).
>
> In fact it is possible to write NVIZ script code that can do pretty much
> what you want. I don't know how to do it, but you should be able type script
> commands to control the visualization and open NVIZ with this script (Maybe
> you can even cat these into NVIZ in a *nix system--though I don't know if
> this is possible or not).

What I was getting at is that you don't have to use NVIZ and/or Tcl/Tk to 
create 3-D views in GRASS. NVIZ is just a Tcl/Tk interface to the gsurf 
library (lib/ogsf) which is written in C. So my idea was to write some new 
C modules that link against libgrass_ogsf and duplicate the functionality 
of NVIZ but in a much more easily scriptable way. I'll keep quiet about it 
again though unless I actually get time to see how easy it is to do, as I 
really am not too sure how much work it would be.

Paul