[GRASS-dev] new tests on wxgui
michael.barton at asu.edu
Tue May 15 10:56:36 EDT 2007
On 5/15/07 4:30 AM, "Carlos "Guâno" Grohmann" <carlos.grohmann at gmail.com>
> First things first, I am running a Xubuntu 7.04 machine. Wxwidgets
> compile with non-unicode option.
>> This works fine for me. Again, could this be a system issue with running
I'm running an ANSI version of wxPython on my Mac (though thinking about
switching to Unicode for the new fonts display.
With respect to the GRASS element selection control (used for map
selection), I've looked at the code and it does not explicitly sort. It uses
order that comes from a directory listing. On my Mac this is alphabetically
I can add alpha sorting to this list easily if that is OK with everyone else
(i.e., if there is no preference for keeping it in directory order).
I don't know why you are having the other odd little problems you are
getting. Any error messages in the terminal?
>>> The thing about you have to close the command window to refresh the
>>> display goes for other commands, also. For instance, if I use
>>> g.region, and change the region settings, I can't refresh the map
>>> until I hit "Cancel" in g.region window. I should be able to change
>>> the settings, refresh the display to see if that is what I want and
>>> then hit "close" to close the window (instead of "cancel" which is
>>> counter-intuitive). In this particular case (g.region) tha "Aplly" or
>>> "Run" button is usefull, it would aplly the canges, we would see if
>>> it's OK, and then the OK would close the window (and apply the changes
>>> again, but it wouldn't make any harm).
>> To do this, we'd need to change the dialogs back to non-modal. Worth
>> discussing, but possibly problematic for map displays (what happens if you
>> have 3 raster in the list?).
> I don't see a problem here. what's the problem with having three or
> more maps in the list?
If there are 3 identical dialog boxes opened for 3 raster layers, it might
be difficult to know which dialog is affecting which layer. But maybe this
isn't really an issue to worry about...?
>> Remember, the computational region (set with g.region) will not affect the
>> display region or vice versa, unless you explicitly tell GRASS to do so.
> I know that, but I want to _see_ if my computational region is really
> the size I want.
You can't *see* the computational region per se. *BUT* you can set a display
region to the size you want and then set the extents of the computational
region to match what you see. For this, showing the extents in the status
bar should be the most useful information (which is what we have now). Note,
that the display does not affect the resolution of the computational region.
The resolution must be set from g.region.
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
More information about the grass-dev