[GRASSGUI] graphic overlays

[Michael Barton]

I want to suggest that most or all graphic overlays be done via wxPython
rather than using GRASS d.* commands.

These are: north arrow, scale, grid (and geodetic lines maybe), and text.
We?ll need someone to design some nice (and GRASS distinctive) north arrows
and scales.

I suggest that these be accessed through an item or items (popup checkbox
menu?) on the map display tool bar, rather than having them added as layers.
They should be able to be turned on and off of course, as well as being
positioned with a mouse (the latter will be much easier if they are wxPython
graphic objects). Each will need it?s own dialog with options, but that
shouldn?t be too difficult to do.

Vector labels could go either way<as something done from the map display
tool bar or as an independent layer.

Other opinions?

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Glynn Clements]

Post by Michael Barton
I want to suggest that most or all graphic overlays be done via wxPython
rather than using GRASS d.* commands.
These are: north arrow, scale, grid (and geodetic lines maybe), and text.
We?ll need someone to design some nice (and GRASS distinctive) north arrows
and scales.
I suggest that these be accessed through an item or items (popup checkbox
menu?) on the map display tool bar, rather than having them added as layers.
They should be able to be turned on and off of course, as well as being
positioned with a mouse (the latter will be much easier if they are wxPython
graphic objects). Each will need it?s own dialog with options, but that
shouldn?t be too difficult to do.
Vector labels could go either way<as something done from the map display
tool bar or as an independent layer.
Other opinions?

I suggest that this is implemented in such a way that the user can
easily choose to use the equivalent d.* commands instead, so that the
display contents can be exported as a script which can be used outside
of the GUI (i.e. with an X/PNG monitor).

[Michael Barton]

This kind of negates the idea (I thought you were promoting too) of using
native GUI functions for all 'decorations'. It's not hard to add a layer
managers for d.grid, d.text, d.scalebar, etc. But it could clutter up the
main control more.

What if we could make it scriptable using wxPython graphic elements?

Michael

Post by Glynn Clements

Post by Michael Barton
I want to suggest that most or all graphic overlays be done via wxPython
rather than using GRASS d.* commands.
These are: north arrow, scale, grid (and geodetic lines maybe), and text.
We?ll need someone to design some nice (and GRASS distinctive) north arrows
and scales.
I suggest that these be accessed through an item or items (popup checkbox
menu?) on the map display tool bar, rather than having them added as layers.
They should be able to be turned on and off of course, as well as being
positioned with a mouse (the latter will be much easier if they are wxPython
graphic objects). Each will need it?s own dialog with options, but that
shouldn?t be too difficult to do.
Vector labels could go either way<as something done from the map display
tool bar or as an independent layer.
Other opinions?

I suggest that this is implemented in such a way that the user can
easily choose to use the equivalent d.* commands instead, so that the
display contents can be exported as a script which can be used outside
of the GUI (i.e. with an X/PNG monitor).

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Glynn Clements]

Post by Michael Barton

Post by Glynn Clements

Post by Michael Barton
I want to suggest that most or all graphic overlays be done via wxPython
rather than using GRASS d.* commands.
These are: north arrow, scale, grid (and geodetic lines maybe), and text.
We?ll need someone to design some nice (and GRASS distinctive) north arrows
and scales.
I suggest that these be accessed through an item or items (popup checkbox
menu?) on the map display tool bar, rather than having them added as layers.
They should be able to be turned on and off of course, as well as being
positioned with a mouse (the latter will be much easier if they are wxPython
graphic objects). Each will need it?s own dialog with options, but that
shouldn?t be too difficult to do.
Vector labels could go either way<as something done from the map display
tool bar or as an independent layer.
Other opinions?

I suggest that this is implemented in such a way that the user can
easily choose to use the equivalent d.* commands instead, so that the
display contents can be exported as a script which can be used outside
of the GUI (i.e. with an X/PNG monitor).

This kind of negates the idea (I thought you were promoting too) of using
native GUI functions for all 'decorations'.

FWIW, I don't support requiring the GUI in order to render anything
which might reasonably appear on a printed map (labels, scale bar,
legend etc).

These should all be achievable using d.* commands, and the GUI should
provide a convenient interface to those commands (e.g. using the mouse
to identify coordinates for placement).

Post by Michael Barton
It's not hard to add a layer
managers for d.grid, d.text, d.scalebar, etc. But it could clutter up the
main control more.
What if we could make it scriptable using wxPython graphic elements?

I'm not entirely sure what you mean by that.

But, essentially, I feel that it should be possible to save the
contents of the display as a script which will work on a system with
only core GRASS modules (no Python, no X server; can you render
wxPython graphics into an image file on a system with no X server?).

[Michael Barton]

Post by Glynn Clements

Post by Michael Barton

Post by Glynn Clements

Post by Michael Barton
I want to suggest that most or all graphic overlays be done via wxPython
rather than using GRASS d.* commands.
These are: north arrow, scale, grid (and geodetic lines maybe), and text.
We?ll need someone to design some nice (and GRASS distinctive) north arrows
and scales.
I suggest that these be accessed through an item or items (popup checkbox
menu?) on the map display tool bar, rather than having them added as
layers.
They should be able to be turned on and off of course, as well as being
positioned with a mouse (the latter will be much easier if they are
wxPython
graphic objects). Each will need it?s own dialog with options, but that
shouldn?t be too difficult to do.
Vector labels could go either way<as something done from the map display
tool bar or as an independent layer.
Other opinions?

I suggest that this is implemented in such a way that the user can
easily choose to use the equivalent d.* commands instead, so that the
display contents can be exported as a script which can be used outside
of the GUI (i.e. with an X/PNG monitor).

This kind of negates the idea (I thought you were promoting too) of using
native GUI functions for all 'decorations'.

FWIW, I don't support requiring the GUI in order to render anything
which might reasonably appear on a printed map (labels, scale bar,
legend etc).

I don't think we should necessarily limit the GUI to only being able to do
what plain GRASS command modules can do. The programming that goes into the
GUI is value added to anyone who uses this. Underneath, it is still just
running GRASS modules. So anyone who wants to script as creatively can get
the same results. But that doesn't mean that simply running a series of
GRASS commands will necessarily achieve the same result. Especially for
graphic rendering, a good GUI may well be able to some things that GRASS
outside the GUI cannot do. I don't see this as an issue. If people want to
use the features of the GUI they can. If they don't want to they don't have
to. If they want to recreate the GUI coding in another platform, that's fine
too. But a bash shell script may not be able to achieve what can be done in
a wxPython script.

Post by Glynn Clements
These should all be achievable using d.* commands, and the GUI should
provide a convenient interface to those commands (e.g. using the mouse
to identify coordinates for placement).

This is fine as far as it goes. d.grid is fairly complete as is. However,
d.barscale is very limited in its style of north arrows and scales. And
there is no way to adjust the size of either. If someone wants to program in
a bunch of arrow and scale styles, along with ways of setting scale
parameters and arrow sizes, that's fine. But it may well be much easier to
to do this in the GUI than in a C module. I don't advocate getting rid of
d.barscale. But I don't think the GUI should be limited by its restrictions.
d.text is similarly limited. You can do quite a bit more with text in the
GUI, and do so more easily (e.g., built in font-setting dialogs that are
appropriate to whatever platform it's run on). For all of these, interactive
placing and moving with a mouse is difficult if we only use the d.* command
modules. While I can click and send coordinates to d.barscale (like we can
do in the TclTk GUI), I don't know how I could grab a north arrow with a
mouse and drag it to reposition it in another locale on the screen using
d.barscale. However, I can do that with wxPython generated graphics.

Post by Glynn Clements

Post by Michael Barton
It's not hard to add a layer
managers for d.grid, d.text, d.scalebar, etc. But it could clutter up the
main control more.
What if we could make it scriptable using wxPython graphic elements?

I'm not entirely sure what you mean by that.
But, essentially, I feel that it should be possible to save the
contents of the display as a script which will work on a system with
only core GRASS modules (no Python, no X server; can you render
wxPython graphics into an image file on a system with no X server?).

NVIZ can be scripted, but you can't render an NVIZ image without NVIZ. I
don't see that as a problem. If you want to render a 2.5D or 4D image, you
need NVIZ. There is no way to render this using plain vanilla GRASS
commands. I wouldn't want to not have this tool simply because we couldn't
render its images with plain command line C modules.

I'm a very big advocate of GRASS's scripting potential. I've written a
number of scripts. And this scriptability is what makes it possible to wrap
the commands in a nice GUI. But as you've pointed out, there are limitations
to graphic output rendering from command-line modules alone. Continued
improvements to ps.map may be a way to achieve this. Perhaps it could be
made to render to a PNG or PPM file as well as a postscript one. Just some
thoughts.

Michael

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Martin Landa]

Hi,

just *note* -- from my point of view it would be nice to design new
GUI only as an interface (without any extra functionality). User can
choose between CLI or GUI. But the functionality (including
decorations) would be almost identical (i.e. accessible via GUI or
CLI). E.g. I don't like that the user can set transparency level of
raster layers via GUI in the current GIS Manager but not via CLI (I
mean using directly d.rast).

Martin

Post by Michael Barton

Post by Glynn Clements

Post by Michael Barton

Post by Glynn Clements

Post by Michael Barton
I want to suggest that most or all graphic overlays be done via wxPython
rather than using GRASS d.* commands.
These are: north arrow, scale, grid (and geodetic lines maybe), and text.
We?ll need someone to design some nice (and GRASS distinctive) north arrows
and scales.
I suggest that these be accessed through an item or items (popup checkbox
menu?) on the map display tool bar, rather than having them added as layers.
They should be able to be turned on and off of course, as well as being
positioned with a mouse (the latter will be much easier if they are wxPython
graphic objects). Each will need it?s own dialog with options, but that
shouldn?t be too difficult to do.
Vector labels could go either way<as something done from the map display
tool bar or as an independent layer.
Other opinions?

I suggest that this is implemented in such a way that the user can
easily choose to use the equivalent d.* commands instead, so that the
display contents can be exported as a script which can be used outside
of the GUI (i.e. with an X/PNG monitor).

This kind of negates the idea (I thought you were promoting too) of using
native GUI functions for all 'decorations'.

FWIW, I don't support requiring the GUI in order to render anything
which might reasonably appear on a printed map (labels, scale bar,
legend etc).

I don't think we should necessarily limit the GUI to only being able to do
what plain GRASS command modules can do. The programming that goes into the
GUI is value added to anyone who uses this. Underneath, it is still just
running GRASS modules. So anyone who wants to script as creatively can get
the same results. But that doesn't mean that simply running a series of
GRASS commands will necessarily achieve the same result. Especially for
graphic rendering, a good GUI may well be able to some things that GRASS
outside the GUI cannot do. I don't see this as an issue. If people want to
use the features of the GUI they can. If they don't want to they don't have
to. If they want to recreate the GUI coding in another platform, that's fine
too. But a bash shell script may not be able to achieve what can be done in
a wxPython script.

Post by Glynn Clements
These should all be achievable using d.* commands, and the GUI should
provide a convenient interface to those commands (e.g. using the mouse
to identify coordinates for placement).

This is fine as far as it goes. d.grid is fairly complete as is. However,
d.barscale is very limited in its style of north arrows and scales. And
there is no way to adjust the size of either. If someone wants to program in
a bunch of arrow and scale styles, along with ways of setting scale
parameters and arrow sizes, that's fine. But it may well be much easier to
to do this in the GUI than in a C module. I don't advocate getting rid of
d.barscale. But I don't think the GUI should be limited by its restrictions.
d.text is similarly limited. You can do quite a bit more with text in the
GUI, and do so more easily (e.g., built in font-setting dialogs that are
appropriate to whatever platform it's run on). For all of these, interactive
placing and moving with a mouse is difficult if we only use the d.* command
modules. While I can click and send coordinates to d.barscale (like we can
do in the TclTk GUI), I don't know how I could grab a north arrow with a
mouse and drag it to reposition it in another locale on the screen using
d.barscale. However, I can do that with wxPython generated graphics.

Post by Glynn Clements

Post by Michael Barton
It's not hard to add a layer
managers for d.grid, d.text, d.scalebar, etc. But it could clutter up the
main control more.
What if we could make it scriptable using wxPython graphic elements?

I'm not entirely sure what you mean by that.
But, essentially, I feel that it should be possible to save the
contents of the display as a script which will work on a system with
only core GRASS modules (no Python, no X server; can you render
wxPython graphics into an image file on a system with no X server?).

NVIZ can be scripted, but you can't render an NVIZ image without NVIZ. I
don't see that as a problem. If you want to render a 2.5D or 4D image, you
need NVIZ. There is no way to render this using plain vanilla GRASS
commands. I wouldn't want to not have this tool simply because we couldn't
render its images with plain command line C modules.
I'm a very big advocate of GRASS's scripting potential. I've written a
number of scripts. And this scriptability is what makes it possible to wrap
the commands in a nice GUI. But as you've pointed out, there are limitations
to graphic output rendering from command-line modules alone. Continued
improvements to ps.map may be a way to achieve this. Perhaps it could be
made to render to a PNG or PPM file as well as a postscript one. Just some
thoughts.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton
_______________________________________________
grassgui mailing list
http://grass.itc.it/mailman/listinfo/grassgui

[Glynn Clements]

Post by Michael Barton

Post by Glynn Clements
These should all be achievable using d.* commands, and the GUI should
provide a convenient interface to those commands (e.g. using the mouse
to identify coordinates for placement).

This is fine as far as it goes. d.grid is fairly complete as is. However,
d.barscale is very limited in its style of north arrows and scales. And
there is no way to adjust the size of either.

So improve d.barscale, rather than writing a GUI-only alternative.

Post by Michael Barton
If someone wants to program in
a bunch of arrow and scale styles, along with ways of setting scale
parameters and arrow sizes, that's fine. But it may well be much easier to
to do this in the GUI than in a C module.

No, there's no reason why this can't be implemented in d.barscale.

Post by Michael Barton
I don't advocate getting rid of
d.barscale. But I don't think the GUI should be limited by its restrictions.

The GUI should be an *interface*, not a new (and interactive-use-only)
graphics architecture.

Post by Michael Barton
d.text is similarly limited. You can do quite a bit more with text in the
GUI,

Such as?

Post by Michael Barton
and do so more easily (e.g., built in font-setting dialogs that are
appropriate to whatever platform it's run on).

Providing font-selection dialogs is a reasonable task for the GUI, but
that doesn't mean that the GUI should then take over all text
rendering.

Post by Michael Barton
For all of these, interactive
placing and moving with a mouse is difficult if we only use the d.* command
modules. While I can click and send coordinates to d.barscale (like we can
do in the TclTk GUI), I don't know how I could grab a north arrow with a
mouse and drag it to reposition it in another locale on the screen using
d.barscale.

Pan the image which d.barscale generates. Or use the GUI to draw a
preview; just don't offer features which can't then be re-created
using d.barscale.

[Michael Barton]

We have no problem accepting that bash scripts offer value added
functionality to simple GRASS commands by augmenting them with the rich
procedural language of shell scripts--a language that is external to GRASS.
That is, there are many things that you can't do from the command line (or
would find extraordinarily tedious) that are possible if you wrap GRASS
commands in a script.

This is the same for a GUI--which also augments GRASS commands with a
graphical and interactive environment. To say that we should not develop a
modern GUI for displaying GRASS GIS data in a rich, interactive, graphical
environment simply because it cannot be duplicated from typing textual
commands seems very restrictive. Should we drop transparency--which is a
very useful tool as well as a way to make visually appealing and informative
maps--simply because it is not easy to do by typing? Should we drop NVIZ
from GRASS simply because you can't get the same effects by typing on the
command line? I don't think that would serve the GRASS user community well.

Michael

Post by Martin Landa
Hi,
just *note* -- from my point of view it would be nice to design new
GUI only as an interface (without any extra functionality). User can
choose between CLI or GUI. But the functionality (including
decorations) would be almost identical (i.e. accessible via GUI or
CLI). E.g. I don't like that the user can set transparency level of
raster layers via GUI in the current GIS Manager but not via CLI (I
mean using directly d.rast).
Martin

Post by Michael Barton

Post by Glynn Clements

Post by Michael Barton

Post by Glynn Clements

Post by Michael Barton
I want to suggest that most or all graphic overlays be done via wxPython
rather than using GRASS d.* commands.
These are: north arrow, scale, grid (and geodetic lines maybe), and text.
We?ll need someone to design some nice (and GRASS distinctive) north
arrows
and scales.
I suggest that these be accessed through an item or items (popup checkbox
menu?) on the map display tool bar, rather than having them added as
layers.
They should be able to be turned on and off of course, as well as being
positioned with a mouse (the latter will be much easier if they are
wxPython
graphic objects). Each will need it?s own dialog with options, but that
shouldn?t be too difficult to do.
Vector labels could go either way<as something done from the map display
tool bar or as an independent layer.
Other opinions?

I suggest that this is implemented in such a way that the user can
easily choose to use the equivalent d.* commands instead, so that the
display contents can be exported as a script which can be used outside
of the GUI (i.e. with an X/PNG monitor).

This kind of negates the idea (I thought you were promoting too) of using
native GUI functions for all 'decorations'.

FWIW, I don't support requiring the GUI in order to render anything
which might reasonably appear on a printed map (labels, scale bar,
legend etc).

I don't think we should necessarily limit the GUI to only being able to do
what plain GRASS command modules can do. The programming that goes into the
GUI is value added to anyone who uses this. Underneath, it is still just
running GRASS modules. So anyone who wants to script as creatively can get
the same results. But that doesn't mean that simply running a series of
GRASS commands will necessarily achieve the same result. Especially for
graphic rendering, a good GUI may well be able to some things that GRASS
outside the GUI cannot do. I don't see this as an issue. If people want to
use the features of the GUI they can. If they don't want to they don't have
to. If they want to recreate the GUI coding in another platform, that's fine
too. But a bash shell script may not be able to achieve what can be done in
a wxPython script.

Post by Glynn Clements
These should all be achievable using d.* commands, and the GUI should
provide a convenient interface to those commands (e.g. using the mouse
to identify coordinates for placement).

This is fine as far as it goes. d.grid is fairly complete as is. However,
d.barscale is very limited in its style of north arrows and scales. And
there is no way to adjust the size of either. If someone wants to program in
a bunch of arrow and scale styles, along with ways of setting scale
parameters and arrow sizes, that's fine. But it may well be much easier to
to do this in the GUI than in a C module. I don't advocate getting rid of
d.barscale. But I don't think the GUI should be limited by its restrictions.
d.text is similarly limited. You can do quite a bit more with text in the
GUI, and do so more easily (e.g., built in font-setting dialogs that are
appropriate to whatever platform it's run on). For all of these, interactive
placing and moving with a mouse is difficult if we only use the d.* command
modules. While I can click and send coordinates to d.barscale (like we can
do in the TclTk GUI), I don't know how I could grab a north arrow with a
mouse and drag it to reposition it in another locale on the screen using
d.barscale. However, I can do that with wxPython generated graphics.

Post by Glynn Clements

Post by Michael Barton
It's not hard to add a layer
managers for d.grid, d.text, d.scalebar, etc. But it could clutter up the
main control more.
What if we could make it scriptable using wxPython graphic elements?

I'm not entirely sure what you mean by that.
But, essentially, I feel that it should be possible to save the
contents of the display as a script which will work on a system with
only core GRASS modules (no Python, no X server; can you render
wxPython graphics into an image file on a system with no X server?).

NVIZ can be scripted, but you can't render an NVIZ image without NVIZ. I
don't see that as a problem. If you want to render a 2.5D or 4D image, you
need NVIZ. There is no way to render this using plain vanilla GRASS
commands. I wouldn't want to not have this tool simply because we couldn't
render its images with plain command line C modules.
I'm a very big advocate of GRASS's scripting potential. I've written a
number of scripts. And this scriptability is what makes it possible to wrap
the commands in a nice GUI. But as you've pointed out, there are limitations
to graphic output rendering from command-line modules alone. Continued
improvements to ps.map may be a way to achieve this. Perhaps it could be
made to render to a PNG or PPM file as well as a postscript one. Just some
thoughts.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton
_______________________________________________
grassgui mailing list
http://grass.itc.it/mailman/listinfo/grassgui

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Daniel Calvelo]

On 3/25/07, Michael Barton <***@asu.edu> wrote:
[...]

Post by Michael Barton
This is the same for a GUI--which also augments GRASS commands with a
graphical and interactive environment. To say that we should not develop a
modern GUI for displaying GRASS GIS data in a rich, interactive, graphical
environment simply because it cannot be duplicated from typing textual
commands seems very restrictive.

Not restrictive, it is demanding.

Post by Michael Barton
Should we drop transparency--which is a
very useful tool as well as a way to make visually appealing and informative
maps--simply because it is not easy to do by typing? Should we drop NVIZ
from GRASS simply because you can't get the same effects by typing on the
command line?

We shouldn't drop them, but we must strive at making the added
functionality a part of the GRASS system as a whole. I mean, e.g., if
we add mouse-based placement of north arrows, we must strive at
providing similar functionality from the command-line, i.e. a
d.northarrow command whose parameters may be produced by the
interactive version.

This is not very hard to do, as making it in python is a fine first
step. It is just a constraint (and I think a very good one) and
discipline in the way we must structure and think about the "gui"
code.

For instance, in the north arrow matter, it is better to use a python
reader for GRASS' icon/symbol description language and build nice
north arrow in that language than to use, say, SVG astounding
gradient-filled and alpha-blended symbols, which cannot easily be used
by the rest of GRASS code.

Post by Michael Barton
I don't think that would serve the GRASS user community well.

Of course not. IMO the matter under discussion is reusability of
current developments and newer functionality under the original GRASS
philosophy.

BTW, anybody has pointers to a discussion that seems to have arisen
with respect to GRASStep?

Daniel.

Post by Michael Barton
Michael

Post by Martin Landa
Hi,
just *note* -- from my point of view it would be nice to design new
GUI only as an interface (without any extra functionality). User can
choose between CLI or GUI. But the functionality (including
decorations) would be almost identical (i.e. accessible via GUI or
CLI). E.g. I don't like that the user can set transparency level of
raster layers via GUI in the current GIS Manager but not via CLI (I
mean using directly d.rast).
Martin

Post by Michael Barton

Post by Glynn Clements

Post by Michael Barton

Post by Glynn Clements

Post by Michael Barton
I want to suggest that most or all graphic overlays be done via wxPython
rather than using GRASS d.* commands.
These are: north arrow, scale, grid (and geodetic lines maybe), and text.
We?ll need someone to design some nice (and GRASS distinctive) north arrows
and scales.
I suggest that these be accessed through an item or items (popup checkbox
menu?) on the map display tool bar, rather than having them added as layers.
They should be able to be turned on and off of course, as well as being
positioned with a mouse (the latter will be much easier if they are wxPython
graphic objects). Each will need it?s own dialog with options, but that
shouldn?t be too difficult to do.
Vector labels could go either way<as something done from the map display
tool bar or as an independent layer.
Other opinions?

I suggest that this is implemented in such a way that the user can
easily choose to use the equivalent d.* commands instead, so that the
display contents can be exported as a script which can be used outside
of the GUI (i.e. with an X/PNG monitor).

This kind of negates the idea (I thought you were promoting too) of using
native GUI functions for all 'decorations'.

FWIW, I don't support requiring the GUI in order to render anything
which might reasonably appear on a printed map (labels, scale bar,
legend etc).

I don't think we should necessarily limit the GUI to only being able to do
what plain GRASS command modules can do. The programming that goes into the
GUI is value added to anyone who uses this. Underneath, it is still just
running GRASS modules. So anyone who wants to script as creatively can get
the same results. But that doesn't mean that simply running a series of
GRASS commands will necessarily achieve the same result. Especially for
graphic rendering, a good GUI may well be able to some things that GRASS
outside the GUI cannot do. I don't see this as an issue. If people want to
use the features of the GUI they can. If they don't want to they don't have
to. If they want to recreate the GUI coding in another platform, that's fine
too. But a bash shell script may not be able to achieve what can be done in
a wxPython script.

Post by Glynn Clements
These should all be achievable using d.* commands, and the GUI should
provide a convenient interface to those commands (e.g. using the mouse
to identify coordinates for placement).

This is fine as far as it goes. d.grid is fairly complete as is. However,
d.barscale is very limited in its style of north arrows and scales. And
there is no way to adjust the size of either. If someone wants to program in
a bunch of arrow and scale styles, along with ways of setting scale
parameters and arrow sizes, that's fine. But it may well be much easier to
to do this in the GUI than in a C module. I don't advocate getting rid of
d.barscale. But I don't think the GUI should be limited by its restrictions.
d.text is similarly limited. You can do quite a bit more with text in the
GUI, and do so more easily (e.g., built in font-setting dialogs that are
appropriate to whatever platform it's run on). For all of these, interactive
placing and moving with a mouse is difficult if we only use the d.* command
modules. While I can click and send coordinates to d.barscale (like we can
do in the TclTk GUI), I don't know how I could grab a north arrow with a
mouse and drag it to reposition it in another locale on the screen using
d.barscale. However, I can do that with wxPython generated graphics.

Post by Glynn Clements

Post by Michael Barton
It's not hard to add a layer
managers for d.grid, d.text, d.scalebar, etc. But it could clutter up the
main control more.
What if we could make it scriptable using wxPython graphic elements?

I'm not entirely sure what you mean by that.
But, essentially, I feel that it should be possible to save the
contents of the display as a script which will work on a system with
only core GRASS modules (no Python, no X server; can you render
wxPython graphics into an image file on a system with no X server?).

NVIZ can be scripted, but you can't render an NVIZ image without NVIZ. I
don't see that as a problem. If you want to render a 2.5D or 4D image, you
need NVIZ. There is no way to render this using plain vanilla GRASS
commands. I wouldn't want to not have this tool simply because we couldn't
render its images with plain command line C modules.
I'm a very big advocate of GRASS's scripting potential. I've written a
number of scripts. And this scriptability is what makes it possible to wrap
the commands in a nice GUI. But as you've pointed out, there are limitations
to graphic output rendering from command-line modules alone. Continued
improvements to ps.map may be a way to achieve this. Perhaps it could be
made to render to a PNG or PPM file as well as a postscript one. Just some
thoughts.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton
_______________________________________________
grassgui mailing list
http://grass.itc.it/mailman/listinfo/grassgui

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton
_______________________________________________
grassgui mailing list
http://grass.itc.it/mailman/listinfo/grassgui

[Michael Barton]

I can agree with all of this.

Please keep in mind, all, that I would love to be able to write scripts that
could display maps in a wxPython canvas with all kinds of nice decorations
like legends, arrows, and scales. In my lab, we are currently developing
dynamic GIS and cellular automata models, as well as coupled agent-based and
surface process models, that call for dynamic displays to track changing
landscapes. At the present, we can only do that via an x monitor, but I
would prefer to move this into a better display environment.

So I definitely favor a scriptable display architecture. However, this may
require code beyond basic GRASS C modules--like the new scripts that Jachym
has written.

The scripting that we are doing in my lab adds iterative dynamics to GRASS
commands via bash shell scripting. This is not practical to do with
individual GRASS commands via the command line. That's why it's great that
GRASS is so scriptable. But we are definitely adding functionality to GRASS
that is not there in the C modules alone.

The same thing goes for GUI code. I agree with the direction that Daniel is
advocating--and in fact maybe we all agree in general. I'm just trying to be
practical and realistic. We might well be able to have command-line control
of complex displays, including NVIZ-like displays. However, we may only be
able to do this if we have access to wxPython and OGL. That is, it may not
be possible only with C code command modules and nothing else. I don't think
that is inherently bad. We use GDAL and PROJ code to handle import/export
and projection, and the current GUI won't run unless TclTk is available. So
there are precedents. I agree that we always need to minimize dependencies
as much as possible. But some are unavoidable, or at least highly desirable.

Since I don't write C code, maybe I'm being overly pessimistic. However,
Glynn is pretty much the only one on the team who is writing new and
sophisticated graphics rendering routines into GRASS C code. This has made
an enormous difference, but he hasn't had much help and I am unable to offer
any.

Michael

Post by Daniel Calvelo
[...]

Post by Michael Barton
This is the same for a GUI--which also augments GRASS commands with a
graphical and interactive environment. To say that we should not develop a
modern GUI for displaying GRASS GIS data in a rich, interactive, graphical
environment simply because it cannot be duplicated from typing textual
commands seems very restrictive.

Not restrictive, it is demanding.

Post by Michael Barton
Should we drop transparency--which is a
very useful tool as well as a way to make visually appealing and informative
maps--simply because it is not easy to do by typing? Should we drop NVIZ
from GRASS simply because you can't get the same effects by typing on the
command line?

We shouldn't drop them, but we must strive at making the added
functionality a part of the GRASS system as a whole. I mean, e.g., if
we add mouse-based placement of north arrows, we must strive at
providing similar functionality from the command-line, i.e. a
d.northarrow command whose parameters may be produced by the
interactive version.
This is not very hard to do, as making it in python is a fine first
step. It is just a constraint (and I think a very good one) and
discipline in the way we must structure and think about the "gui"
code.
For instance, in the north arrow matter, it is better to use a python
reader for GRASS' icon/symbol description language and build nice
north arrow in that language than to use, say, SVG astounding
gradient-filled and alpha-blended symbols, which cannot easily be used
by the rest of GRASS code.

Post by Michael Barton
I don't think that would serve the GRASS user community well.

Of course not. IMO the matter under discussion is reusability of
current developments and newer functionality under the original GRASS
philosophy.
BTW, anybody has pointers to a discussion that seems to have arisen
with respect to GRASStep?
Daniel.

Post by Michael Barton
Michael

Post by Martin Landa
Hi,
just *note* -- from my point of view it would be nice to design new
GUI only as an interface (without any extra functionality). User can
choose between CLI or GUI. But the functionality (including
decorations) would be almost identical (i.e. accessible via GUI or
CLI). E.g. I don't like that the user can set transparency level of
raster layers via GUI in the current GIS Manager but not via CLI (I
mean using directly d.rast).
Martin

Post by Michael Barton

Post by Glynn Clements

Post by Michael Barton

Post by Glynn Clements

Post by Michael Barton
I want to suggest that most or all graphic overlays be done via
wxPython
rather than using GRASS d.* commands.
These are: north arrow, scale, grid (and geodetic lines maybe), and
text.
We?ll need someone to design some nice (and GRASS distinctive) north
arrows
and scales.
I suggest that these be accessed through an item or items (popup
checkbox
menu?) on the map display tool bar, rather than having them added as
layers.
They should be able to be turned on and off of course, as well as being
positioned with a mouse (the latter will be much easier if they are
wxPython
graphic objects). Each will need it?s own dialog with options, but that
shouldn?t be too difficult to do.
Vector labels could go either way<as something done from the map
display
tool bar or as an independent layer.
Other opinions?

I suggest that this is implemented in such a way that the user can
easily choose to use the equivalent d.* commands instead, so that the
display contents can be exported as a script which can be used outside
of the GUI (i.e. with an X/PNG monitor).

This kind of negates the idea (I thought you were promoting too) of using
native GUI functions for all 'decorations'.

FWIW, I don't support requiring the GUI in order to render anything
which might reasonably appear on a printed map (labels, scale bar,
legend etc).

I don't think we should necessarily limit the GUI to only being able to do
what plain GRASS command modules can do. The programming that goes into the
GUI is value added to anyone who uses this. Underneath, it is still just
running GRASS modules. So anyone who wants to script as creatively can get
the same results. But that doesn't mean that simply running a series of
GRASS commands will necessarily achieve the same result. Especially for
graphic rendering, a good GUI may well be able to some things that GRASS
outside the GUI cannot do. I don't see this as an issue. If people want to
use the features of the GUI they can. If they don't want to they don't have
to. If they want to recreate the GUI coding in another platform, that's
fine
too. But a bash shell script may not be able to achieve what can be done in
a wxPython script.

Post by Glynn Clements
These should all be achievable using d.* commands, and the GUI should
provide a convenient interface to those commands (e.g. using the mouse
to identify coordinates for placement).

This is fine as far as it goes. d.grid is fairly complete as is. However,
d.barscale is very limited in its style of north arrows and scales. And
there is no way to adjust the size of either. If someone wants to program
in
a bunch of arrow and scale styles, along with ways of setting scale
parameters and arrow sizes, that's fine. But it may well be much easier to
to do this in the GUI than in a C module. I don't advocate getting rid of
d.barscale. But I don't think the GUI should be limited by its
restrictions.
d.text is similarly limited. You can do quite a bit more with text in the
GUI, and do so more easily (e.g., built in font-setting dialogs that are
appropriate to whatever platform it's run on). For all of these,
interactive
placing and moving with a mouse is difficult if we only use the d.* command
modules. While I can click and send coordinates to d.barscale (like we can
do in the TclTk GUI), I don't know how I could grab a north arrow with a
mouse and drag it to reposition it in another locale on the screen using
d.barscale. However, I can do that with wxPython generated graphics.

Post by Glynn Clements

Post by Michael Barton
It's not hard to add a layer
managers for d.grid, d.text, d.scalebar, etc. But it could clutter up the
main control more.
What if we could make it scriptable using wxPython graphic elements?

I'm not entirely sure what you mean by that.
But, essentially, I feel that it should be possible to save the
contents of the display as a script which will work on a system with
only core GRASS modules (no Python, no X server; can you render
wxPython graphics into an image file on a system with no X server?).

NVIZ can be scripted, but you can't render an NVIZ image without NVIZ. I
don't see that as a problem. If you want to render a 2.5D or 4D image, you
need NVIZ. There is no way to render this using plain vanilla GRASS
commands. I wouldn't want to not have this tool simply because we couldn't
render its images with plain command line C modules.
I'm a very big advocate of GRASS's scripting potential. I've written a
number of scripts. And this scriptability is what makes it possible to wrap
the commands in a nice GUI. But as you've pointed out, there are
limitations
to graphic output rendering from command-line modules alone. Continued
improvements to ps.map may be a way to achieve this. Perhaps it could be
made to render to a PNG or PPM file as well as a postscript one. Just some
thoughts.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton
_______________________________________________
grassgui mailing list
http://grass.itc.it/mailman/listinfo/grassgui

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton
_______________________________________________
grassgui mailing list
http://grass.itc.it/mailman/listinfo/grassgui

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Moritz Lennert]

Post by Michael Barton
So
there are precedents. I agree that we always need to minimize dependencies
as much as possible. But some are unavoidable, or at least highly desirable.

I my understanding, the issue is not about dependencies, but about
trying to avoid diverging development of two versions of GRASS: CLI and
GUI. If we start adding more and more features to the GUI which are not
available on the CLI, people might be obliged to use the GUI to access a
specific feature, just because it was easier to code this for the GUI
than for the CLI, and so noone bothered for the latter.

In my eyes, the GUI should be a convenience, not an obligation.

The examples you cited for justifying going directly through the GUI are
all doable in the modules directly. It is obvious that we are more
limited in developer power in C (although seeing the speed at which you
learned tcltk and python, I don't think it would take you very long to
get the gist of C ;-), but these are typically "small", well
circumscribed tasks which we can try to tackle through Google summers of
code, or even try to get institutions which use GRASS to contribute some
development financing for... It might not be as fast as doing it through
the GUI, but the final added value will be higher, IMHO.

Moritz

[Glynn Clements]

Post by Moritz Lennert

Post by Michael Barton
there are precedents. I agree that we always need to minimize dependencies
as much as possible. But some are unavoidable, or at least highly desirable.

I my understanding, the issue is not about dependencies, but about
trying to avoid diverging development of two versions of GRASS: CLI and
GUI. If we start adding more and more features to the GUI which are not
available on the CLI, people might be obliged to use the GUI to access a
specific feature, just because it was easier to code this for the GUI
than for the CLI, and so noone bothered for the latter.
In my eyes, the GUI should be a convenience, not an obligation.

FWIW, the above is essentially my position also.

Post by Moritz Lennert
The examples you cited for justifying going directly through the GUI are
all doable in the modules directly. It is obvious that we are more
limited in developer power in C (although seeing the speed at which you
learned tcltk and python, I don't think it would take you very long to
get the gist of C ;-), but these are typically "small", well
circumscribed tasks which we can try to tackle through Google summers of
code, or even try to get institutions which use GRASS to contribute some
development financing for... It might not be as fast as doing it through
the GUI, but the final added value will be higher, IMHO.

Alternatives to C include using d.graph or creating Python bindings
for the raster/display libraries.