On Nov 22, 2011, at 10:09 PM, <[email protected]> wrote:
> ate: Tue, 22 Nov 2011 05:00:06 -0800 (PST) > From: Hamish <[email protected]> > Subject: Re: [GRASS-dev] 6.4.2rc3 this week, then 6.4.2 by the > holidays? > To: Markus Neteler <[email protected]>, Martin Landa > <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=us-ascii > > Markus Neteler: >> Or backport at least wxNVIZ from GRASS 6.5 and still >> disable it from the default compilation? > > is it buggy, or just lacking the latest and greatest features? > Both. And a lot of stuff for which there are interface elements does not work. This is all fixed in the current GRASS 7 version. I'm not sure which is the best way to go, leave it out with a 'get GRASS 7' message. Or backport it. It is really nice, but it involves a lot of new code. One issue that has cropped up is that there are problems reading non-ascii strings (for non-western languages I think). There are tools to do this in Python and implemented in utils.Decode/Encode modules, but they need to be implemented across very many (perhaps several hundred) places that read input using str(). See <http://trac.osgeo.org/grass/ticket/1488> for more details and discussion with Glynn. Many (though not nearly all) of the places that need to be fixed are in the wxNVIZ code. This is probably pretty easy to do, just tedious. This produces obscure errors. I hit it running v.in.dxf, but someone recently reported a similar error doing something else. There is also an issue that has come across the dev list recently with respect to g_fatal_error (not sure if I spelled it right). Again, this mainly involves the new wxnviz and wxdigitizer code. AFAICT, there is no agreed on solution to this yet. Michael_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
