[GRASS-dev] new tests on wxgui

GRASS GIS GRASS GIS developer
1

Hello all. I just did some tests with the new wxgui. here are some impressions.

Apply button - Why? when you ask for a new map (say raster), you get a
window for d.rast, where you choose the map, the you have three
options: "Cancel" "Apply" and "OK". The "Apply" does nothing. It will
put the map name on GIS Manager, but that's all. You can't keep d.rast
window open and draw the map on the display, you can't do nothing
until you hit the "OK" button. So way keep this "Apply" button?
"Cancel" and "OK" are all we need. (This "Apply" thing is way too much
MSWindows IMO).

I also couldn't change the raster map, with "Apply" or with "OK". I
have to add a new one.

In the Pop-down list where we can choose the map, the names should be
in alphabetical order.

The "zoom to selected map" is not working, in my case, it just used
the last zoom. In fact I get this error in a LatLong location:

GRASS 6.3.cvs (amsul_wgs84):~ > Traceback (most recent call last):
  File "/usr/local/grass-6.3.cvs/etc/wx/gui_modules/mapdisp.py", line
770, in ZoomToMap
    self.Map.region['n'] = float(extent[1])
ValueError: invalid literal for float(): 40N

- just for the record, it used the last zoom in a UTM location too.

I think that all the Zoom button should be together in Display
Manager, but the Query button is in the middle, that can be confusing.
IMO, should be: Pointer-Pan-Zoom In-Zoom Out-Previous Zoom-Zoom
Options--Query.

Maybe the "Overlay" icon in display manager would be better if the
grid was above the raster, and not below it? that gives a better idea
of what that icon does.

I didn't find an option to say that I don't want vector areas to be
filled. I did found where to change the colors, but not the "no fill"
option.

I think that the d.vect window should be large enough to show all the
options (maybe except "output"), and "options" could very well be in
"main", instead of a separated tab, the same goes for d.rast.

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).

That's all for now.

cheers

Carlos

--
+-----------------------------------------------------------+
              Carlos Henrique Grohmann - Guano
  Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke

2

Carlos wrote:

I think that all the Zoom button should be together in Display
Manager, but the Query button is in the middle, that can be confusing.
IMO, should be: Pointer-Pan-Zoom In-Zoom Out-Previous Zoom-Zoom
Options--Query.

Nice order; I agree.

tabs

Another wish for module GUI tabs: (at least for tcl/tk)
Allow spaces in the tab names. Right now we have to use_underscores.
Proably just some quoting somewhere. Better control over tab order would
be nice too. Right now (tcl) the first flag given determines the first
tab name, which is annoying if you want all flags in secondary tab. Also
Options is hardcoded as the default tab, which makes it hard to work with
if you don't want that tab to come first.

see wish #238
  http://wald.intevation.org/tracker/index.php?func=detail&aid=238

Hamish

3

On Mon, 14 May 2007, Hamish wrote:

Another wish for module GUI tabs: (at least for tcl/tk)
Allow spaces in the tab names. Right now we have to use_underscores.
Proably just some quoting somewhere. Better control over tab order would
be nice too. Right now (tcl) the first flag given determines the first
tab name, which is annoying if you want all flags in secondary tab. Also
Options is hardcoded as the default tab, which makes it hard to work with
if you don't want that tab to come first.

see wish #238
http://wald.intevation.org/tracker/index.php?func=detail&aid=238

IIRC from partly digging into this a while ago, the place to look for changing it is G_tcltk() in lib/gis/parser.c. ISTR also the the Python GUI uses G_usage_xml() for generating option dialogs (also in parser.c), so maybe the issue doesn't apply there?

Paul

4

I agree. This in the C-code parser that creates the xml file (and TclTk
file) that the GUI's use to build their dialogs.

Michael

On 5/13/07 5:00 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Carlos wrote:

I think that all the Zoom button should be together in Display
Manager, but the Query button is in the middle, that can be confusing.
IMO, should be: Pointer-Pan-Zoom In-Zoom Out-Previous Zoom-Zoom
Options--Query.

Nice order; I agree.

tabs

Another wish for module GUI tabs: (at least for tcl/tk)
Allow spaces in the tab names. Right now we have to use_underscores.
Proably just some quoting somewhere. Better control over tab order would
be nice too. Right now (tcl) the first flag given determines the first
tab name, which is annoying if you want all flags in secondary tab. Also
Options is hardcoded as the default tab, which makes it hard to work with
if you don't want that tab to come first.

see wish #238
  Wald: Exiting with error

Hamish

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

5

So far, this is the logic behind the order of tabs in menuform.py:

First, generate a list of sections from the xml description. AFAICS,
the xml is generated (parser.c) in the order the arguments are
declared and added to the list in the main() function of the command.

Required arguments are put in the Main tab, regardless of their initial section.

Arguments that do not declare a section are put in the Options tab.

Command and Manual tabs are added. The latter is omitted if there is
no HTML file for the command.

Within each tab, flags are first, then the rest of arguments in the
order they appear in the parser-generated XML, which is the order in
which they are declared in the main() function of the command.

So it is up to each command to declare its own arrangement. I can't
see any immediate heuristics that could override that. Any ideas?

The underscore vs. space can of course be dealt with.

Daniel.

On 5/13/07, Michael Barton <michael.barton@asu.edu> wrote:

I agree. This in the C-code parser that creates the xml file (and TclTk
file) that the GUI's use to build their dialogs.

Michael

On 5/13/07 5:00 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

> Carlos wrote:
>>
>> I think that all the Zoom button should be together in Display
>> Manager, but the Query button is in the middle, that can be confusing.
>> IMO, should be: Pointer-Pan-Zoom In-Zoom Out-Previous Zoom-Zoom
>> Options--Query.
>
> Nice order; I agree.
>
>> tabs
>
> Another wish for module GUI tabs: (at least for tcl/tk)
> Allow spaces in the tab names. Right now we have to use_underscores.
> Proably just some quoting somewhere. Better control over tab order would
> be nice too. Right now (tcl) the first flag given determines the first
> tab name, which is annoying if you want all flags in secondary tab. Also
> Options is hardcoded as the default tab, which makes it hard to work with
> if you don't want that tab to come first.
>
> see wish #238
> http://wald.intevation.org/tracker/index.php?func=detail&aid=238
>
> Hamish
>

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
-- Daniel Calvelo Aros

6

I also agree about the tool order. The reason for the somewhat odd order at
the moment is that some of the tools operate as radio buttons (i.e., one
button selected, other buttons unselected, stays selected until something
else pushed), and others operate as simple click buttons (click and
something happens).

In a toolbar, the radiobuttons needs to be placed adjacent to one another to
operate so that clicking one will unselect any other. So all radiobuttons
are physically grouped, and separate from other buttons. There is probably
another way to do this, but I don't know what it is at the moment.

Michael

On 5/13/07 5:00 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Carlos wrote:

I think that all the Zoom button should be together in Display
Manager, but the Query button is in the middle, that can be confusing.
IMO, should be: Pointer-Pan-Zoom In-Zoom Out-Previous Zoom-Zoom
Options--Query.

Nice order; I agree.

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

7

On 5/13/07 3:57 AM, "Carlos "Guâno" Grohmann" <carlos.grohmann@gmail.com>
wrote:

Hello all. I just did some tests with the new wxgui. here are some
impressions.

Apply button - Why? when you ask for a new map (say raster), you get a
window for d.rast, where you choose the map, the you have three
options: "Cancel" "Apply" and "OK". The "Apply" does nothing. It will
put the map name on GIS Manager, but that's all. You can't keep d.rast
window open and draw the map on the display, you can't do nothing
until you hit the "OK" button. So way keep this "Apply" button?
"Cancel" and "OK" are all we need. (This "Apply" thing is way too much
MSWindows IMO).

Apply did work until we made the options dialog modal. I guess we should get
rid of this button now (but see below).

I also couldn't change the raster map, with "Apply" or with "OK". I
have to add a new one.

Did you double click the layer to get a new dialog? I have no trouble with
this.

In the Pop-down list where we can choose the map, the names should be
in alphabetical order.

It *is* in alphabetical order on my system. What kind or order is it on in
your system?

The "zoom to selected map" is not working, in my case, it just used
the last zoom.

This works fine for me. Again, could this be a system issue with running
wxPython?

In fact I get this error in a LatLong location:

I haven't tried this yet in a latlon location, but will do so shortly.

GRASS 6.3.cvs (amsul_wgs84):~ > Traceback (most recent call last):
  File "/usr/local/grass-6.3.cvs/etc/wx/gui_modules/mapdisp.py", line
770, in ZoomToMap
    self.Map.region['n'] = float(extent[1])
ValueError: invalid literal for float(): 40N

This looks like a g.region issue that I had to deal with in TclTk. The
output of g.region -gp is different if you are in a latlon region and a
non-latlon region.

- just for the record, it used the last zoom in a UTM location too.

No problem for me with spearfish.

I think that all the Zoom button should be together in Display
Manager, but the Query button is in the middle, that can be confusing.
IMO, should be: Pointer-Pan-Zoom In-Zoom Out-Previous Zoom-Zoom
Options--Query.

Already answered this to Hamish. I agree with you, but there are pragmatic
reasons to put it where it is at the moment that we need to resolve.

Maybe the "Overlay" icon in display manager would be better if the
grid was above the raster, and not below it? that gives a better idea
of what that icon does.

I didn't find an option to say that I don't want vector areas to be
filled. I did found where to change the colors, but not the "no fill"
option.

We need a transparent (none) option here--like in the dialog for d.barscale.
Daniel?

I think that the d.vect window should be large enough to show all the
options (maybe except "output"), and "options" could very well be in
"main", instead of a separated tab, the same goes for d.rast.

Daniel answered this one.

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?).

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.

Thanks for the input

Michael

That's all for now.

cheers

Carlos

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

8

Michael Barton wrote:

> I didn't find an option to say that I don't want vector areas to be
> filled. I did found where to change the colors, but not the "no
> fill" option.

We need a transparent (none) option here--like in the dialog for
d.barscale.

Sending it "d.vect fcolor=none" should work.

the only difference with d.barscale is that the label for d.barscale's
color option explicitly states that "none" works.

The Tcl GUI for ->gisprompt=GISPROMPT_COLOR doesn't have a "none" button,
it probably should.

"d.rast.num grid_color=none" is slightly different, there we do:
        opt2->options = D_COLOR_LIST ",none";
        opt2->key_desc = "color";
        opt2->description = _("Color for drawing grid, or \"none\"");

(that gives you a pulldown list and won't take RRR:GGG:BBB)

Hamish

9

First things first, I am running a Xubuntu 7.04 machine. Wxwidgets
compile with non-unicode option.

> I also couldn't change the raster map, with "Apply" or with "OK". I
> have to add a new one.

Did you double click the layer to get a new dialog? I have no trouble with
this.

Yes.

>
> In the Pop-down list where we can choose the map, the names should be
> in alphabetical order.

It *is* in alphabetical order on my system. What kind or order is it on in
your system?

see screenshot attached

>
> The "zoom to selected map" is not working, in my case, it just used
> the last zoom.

This works fine for me. Again, could this be a system issue with running
wxPython?

maybe

>
> 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?

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.

Thanks for the input

no problem.

--
+-----------------------------------------------------------+
              Carlos Henrique Grohmann - Guano
  Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke

(attachments)

wxgui1.jpg

10

On 15/05/07 13:30, Carlos "Guâno" Grohmann wrote:

> 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).

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.

How about a an option allowing you to display the computational region as a box in the map display (cf QGIS) ?

Moritz

11

Because the options dialog is autogenerated and fairly sophisticated for
wxgrass, it would be helpful if all commands that take "none" for a color
had an identical interface description.

Michael

On 5/15/07 12:50 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Michael Barton wrote:

I didn't find an option to say that I don't want vector areas to be
filled. I did found where to change the colors, but not the "no
fill" option.

We need a transparent (none) option here--like in the dialog for
d.barscale.

Sending it "d.vect fcolor=none" should work.

the only difference with d.barscale is that the label for d.barscale's
color option explicitly states that "none" works.

The Tcl GUI for ->gisprompt=GISPROMPT_COLOR doesn't have a "none" button,
it probably should.

"d.rast.num grid_color=none" is slightly different, there we do:
        opt2->options = D_COLOR_LIST ",none";
        opt2->key_desc = "color";
        opt2->description = _("Color for drawing grid, or \"none\"");

(that gives you a pulldown list and won't take RRR:GGG:BBB)

Hamish

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

12

On 5/15/07 4:30 AM, "Carlos "Guâno" Grohmann" <carlos.grohmann@gmail.com>
wrote:

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
wxPython?

maybe

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
sorted.

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

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

13

Interesting idea. Though this would only be helpful for cases where the
computational region is smaller than the display region.

Michael

On 5/15/07 5:07 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On 15/05/07 13:30, Carlos "Guâno" Grohmann wrote:

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).

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.

How about a an option allowing you to display the computational region
as a box in the map display (cf QGIS) ?

Moritz

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

14

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.

I know that. the thing is that the region adjusted according to the
display doesn't have exact boundaries, as one defined by g.region. (i
mean the coordinates values will not be round, and so the resolution
also won't be) And sometimes (maybe moste of the times) I want to run
my analysis on region with exact boundaries. That's why I found very
handy to be able to use g.region window and see how things are going
in the display at the same time.
I am doing some analysis with morphometric parameters and different
resolutions, so it is very nice to just hit a button and change the
resolution, for instance, and still having that command window there,
so I can change it again later, and see the results. Of course that
_I_ do most of that using the command line, but we must also think
about the new users, much coming from the click-click world of
windows.

Carlos

--
+-----------------------------------------------------------+
              Carlos Henrique Grohmann - Guano
  Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke

15

On 5/13/07 3:57 AM, "Carlos "Guâno" Grohmann" <carlos.grohmann@gmail.com>
wrote:

In the Pop-down list where we can choose the map, the names should be
in alphabetical order.

I've added sort to this so that it will sort on all platforms.

I think that all the Zoom button should be together in Display
Manager, but the Query button is in the middle, that can be confusing.
IMO, should be: Pointer-Pan-Zoom In-Zoom Out-Previous Zoom-Zoom
Options--Query.

I rearranged the buttons somewhat so that all the query functions are
grouped, but all the radiobuttons are still together.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

16

On 5/15/07 8:34 AM, "Carlos "Guâno" Grohmann" <carlos.grohmann@gmail.com>
wrote:

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.

I know that. the thing is that the region adjusted according to the
display doesn't have exact boundaries, as one defined by g.region. (i
mean the coordinates values will not be round, and so the resolution
also won't be) And sometimes (maybe moste of the times) I want to run
my analysis on region with exact boundaries. That's why I found very
handy to be able to use g.region window and see how things are going
in the display at the same time.

Carlos,

I don't quite understand you. What is the g.region window? There isn't one
in the GUI. But you *can* set the region in g.region and then have the
display match the g.region extents.

I am doing some analysis with morphometric parameters and different
resolutions, so it is very nice to just hit a button and change the
resolution, for instance, and still having that command window there,
so I can change it again later, and see the results. Of course that
_I_ do most of that using the command line, but we must also think
about the new users, much coming from the click-click world of
windows.

I'm not quite sure what you are referring to. Are you talking about the xmon
display and d.zoom?

Michael

Carlos

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

17

I don't quite understand you. What is the g.region window? There isn't one
in the GUI. But you *can* set the region in g.region and then have the
display match the g.region extents.

When I said "g.region window" I was saying "g.region dialog window",
the one you got when you click on Config->region->change region
settings.

I'm not quite sure what you are referring to. Are you talking about the xmon
display and d.zoom?

Michael

I am talking about adjusting the region settings in a more interactive
way. If I set the region from the extents of the display, usually I
get non-round values for limits and resolution (like n=7346298,3217
instead of n=7346298). So I want to adjust these values. What I said
is that _ I _ usually do that in command line, but thinking about
users coming from other softwares, that may be a little "scared" of
the terminal window, these guys may prefer to use the GUI to do that.

So let's imagine something likethis, working only with the GUI: I am
working, and set region according to the display, but the values are
not round so I want to adjust them. I open the dialog of g.region,
write the limits I want, hit OK/Apply, close the window, and redraw
the map with the zoom according to the region I just set up. Oh! Damm!
I made a mistake, the north boundary should be a little bit north..
Let's go agian, open the dialog etc etc..

So what I said was that if I didn't have to close the g.region dialog
to redraw the map, it would save some time if I had to change
anything, as I often do.

Carlos

--
+-----------------------------------------------------------+
              Carlos Henrique Grohmann - Guano
  Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke

18

OK. I think I understand you.

It seems to me that if the dialogs were made non-modal again, that you
should be able to do this. That is, you wouldn't have to close the g.region
dialog to do anything else (like redraw the map to match the region
extents). You could keep changing the values in the extents until you got
something you wanted.

Does that sound correct?

Michael

On 5/15/07 11:35 AM, "Carlos "Guâno" Grohmann" <carlos.grohmann@gmail.com>
wrote:

I don't quite understand you. What is the g.region window? There isn't one
in the GUI. But you *can* set the region in g.region and then have the
display match the g.region extents.

When I said "g.region window" I was saying "g.region dialog window",
the one you got when you click on Config->region->change region
settings.

I'm not quite sure what you are referring to. Are you talking about the xmon
display and d.zoom?

Michael

I am talking about adjusting the region settings in a more interactive
way. If I set the region from the extents of the display, usually I
get non-round values for limits and resolution (like n=7346298,3217
instead of n=7346298). So I want to adjust these values. What I said
is that _ I _ usually do that in command line, but thinking about
users coming from other softwares, that may be a little "scared" of
the terminal window, these guys may prefer to use the GUI to do that.

So let's imagine something likethis, working only with the GUI: I am
working, and set region according to the display, but the values are
not round so I want to adjust them. I open the dialog of g.region,
write the limits I want, hit OK/Apply, close the window, and redraw
the map with the zoom according to the region I just set up. Oh! Damm!
I made a mistake, the north boundary should be a little bit north..
Let's go agian, open the dialog etc etc..

So what I said was that if I didn't have to close the g.region dialog
to redraw the map, it would save some time if I had to change
anything, as I often do.

Carlos

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

19

Michael Barton wrote:

Because the options dialog is autogenerated and fairly sophisticated
for wxgrass, it would be helpful if all commands that take "none" for
a color had an identical interface description.

You can assume that anything that takes RRR:GGG:BBB input should accept
"none" as well. (that may not do anything, but it should be a no-op and
not an error)

i.e. I may be wrong, but I think the ->gisprompt=GISPROMPT_COLOR Tcl GUI
can safely have a None button in it. Can you grey-out a color wheel?

things which are just taking a color name right now have to be
explicitly coded to accept "none", hopefully that will show up on the
->options pulldown list when available.

Hamish

20

Moritz wrote:

> How about a an option allowing you to display the computational
> region as a box in the map display (cf QGIS) ?

Michael wrote:

Interesting idea. Though this would only be helpful for cases where
the computational region is smaller than the display region.

(I'm thinking about something like the lower-left QGIS guide window)

you could then "flip it" and make the display region drawn as say a blue
box inside the computational region. (computational region inside a
display region could be a red box). Maybe this is too nifty and asking
for confusion? Actually it would be ok if you could half-shade the
computational part in the guide-subwindow, so either a shaded box in the
middle or an unshaded box in the middle for the other mode. (visual-only
display area would be clear). A checkbox by the guide could turn that
effect on & off.

At some point we will have just reinvented the QGIS GUI..... maybe that
is best left to the QGIS/GRASS toolbox.

just to make things more complicated:
If display and computational regions are totally disconnected, you can
do other tricks in the display window like rotate the display along
heading instead of north-up. (think of in-car GPS navigation displays)

Hamish