IMHO, it is probably OK to go with 64bit and drop TclTk for GRASS 7. wxNVIZ is very close to the functionality of TclTk NVIZ and surpasses it in a number of areas.
For GRASS 6.4, TclTk is still needed.
Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
On Sep 24, 2011, at 2:24 PM, grass-user-request@lists.osgeo.org wrote:
Well, TclTk is only needed for the old NVIZ. The old TclTk GUI is gone. TclTk 64bit is another one of those that is a problem - it can be built 64bit, but it needs a newer TclTk that GRASS has problems with.
So, a decision here:
- 64bit-only GRASS: Skip the old NVIZ and make do with the still-in-progress wx nviz, or "3D view" (there was supposedly a lot of work done on this for GSOC?)
- 32+64bit GRASS: so you can have 32bit NVIZ and 64bit rest of GRASS.
Right. It is missing animation. But we're not saying that it's done, rather that a GRASS 7 for Mac OS X 10.7 that lacks TclTk would still be very useable.
Right now, GRASS can't be compiled and run under Lion. If dropping TclTk allows it to work, that is a very good first step.
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Well, I managed to get it working, but only compiling as 32bit. As 64bit I got errors in wximgview, and the bad CPU type when starting GRASS. I pointed the --with-python option of configure to the system one (2.7.2) and it worked.
IMHO, it is probably OK to go with 64bit and drop TclTk for GRASS 7. wxNVIZ is very close to the functionality of TclTk NVIZ and surpasses it in a number of areas.
For GRASS 6.4, TclTk is still needed.
Michael
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
Well, TclTk is only needed for the old NVIZ. The old TclTk GUI is gone. TclTk 64bit is another one of those that is a problem - it can be built 64bit, but it needs a newer TclTk that GRASS has problems with.
So, a decision here:
64bit-only GRASS: Skip the old NVIZ and make do with the still-in-progress wx nviz, or “3D view” (there was supposedly a lot of work done on this for GSOC?)
32+64bit GRASS: so you can have 32bit NVIZ and 64bit rest of GRASS.
–
Prof. Carlos Henrique Grohmann - Geologist D.Sc.
Institute of Geosciences - Univ. of São Paulo, Brazil
I have a new laptop with Lion on the way and want to be able to run and compile GRASS on it.
Michael
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
On Sep 23, 2011, at 9:33 PM, Carlos Grohmann wrote:
Well, I managed to get it working, but only compiling as 32bit. As 64bit I got errors in wximgview, and the bad CPU type when starting GRASS. I pointed the --with-python option of configure to the system one (2.7.2) and it worked.
IMHO, it is probably OK to go with 64bit and drop TclTk for GRASS 7. wxNVIZ is very close to the functionality of TclTk NVIZ and surpasses it in a number of areas.
For GRASS 6.4, TclTk is still needed.
Michael
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
Well, TclTk is only needed for the old NVIZ. The old TclTk GUI is gone. TclTk 64bit is another one of those that is a problem - it can be built 64bit, but it needs a newer TclTk that GRASS has problems with.
So, a decision here:
64bit-only GRASS: Skip the old NVIZ and make do with the still-in-progress wx nviz, or “3D view” (there was supposedly a lot of work done on this for GSOC?)
32+64bit GRASS: so you can have 32bit NVIZ and 64bit rest of GRASS.
–
Prof. Carlos Henrique Grohmann - Geologist D.Sc.
Institute of Geosciences - Univ. of São Paulo, Brazil
Ah, another holdout based on compiled code linked to wx libraries, instead of the current ctypes way. If, as Glynn says, there is a ctypes replacement, use it instead and compile 64bits and don't worry about the wximgview error.
Glynn, if wxpyimgview is fully functional (or d.mon works the same), is there a a reason to keep wximgview around? Maybe at least disable its compilation?
On Sep 24, 2011, at 8:46 AM, Glynn Clements wrote:
Carlos Grohmann wrote:
Well, I managed to get it working, but only compiling as 32bit. As 64bit I
got errors in wximgview
That's only a problem if you need wximgview. The same functionality is
available via wxpyimgview. Or maybe d.mon has made this redundant?
That's only a problem if you need wximgview. The same
functionality is available via wxpyimgview. Or maybe d.mon has
made this redundant?
not until the top toolbar and bottom status bar can be disabled and
accessed via a right-click menu.
In the mean time (and even after) it does no harm to keep a couple
backup plans in place, even if one or two of them don't build in
certain conditions. At other times the tables may be reversed.
Ah, another holdout based on compiled code linked to wx libraries,
instead of the current ctypes way. If, as Glynn says, there is a ctypes
replacement, use it instead and compile 64bits and don't worry about the
wximgview error.
wximgview is just C++ and wxWidgets (like 7.0's xganim), no Python
involved. wxpyimgview is a Python/wxPython version.
Glynn, if wxpyimgview is fully functional (or d.mon works the same), is
there a a reason to keep wximgview around? Maybe at least disable its
compilation?
The C++ version may be faster; it may also be useful if using wxPython
is problematic for whatever reason. It can be disabled by building
--without-wxwidgets (which is the default).