[GRASS-dev] GUI platforms

GRASS GIS GRASS GIS developer
1

The recent discussion over where to head in terms of GUI platforms for GRASS
is very useful. Here are some suggestions about how to proceed and structure
this important design decision. Please feel free to suggest or amend.

Primary functions of the GRASS GUI:

1. Provide a GUI interface for GRASS program modules. This includes simple
dialogs and more complex modules like v.digit that also require
visualization
2. Provide a CLI interface for GRASS program modules
3. Manage graphical display/visualization for GRASS geospatial
data--particularly raster and vector files, but also including display
enhancements like profiles, scales, text, grids, etc. This also includes
2.5-3D display handled by NVIZ and output of graphical displays to files for
inclusion in other applications.
4. Manage non-graphic output from GRASS commands--normally as text.
5. Provide an interface for interactive attribute management for vector
data. This is not currently handled in the GUI, but could be.

Some questions to ask about GUI platforms (not necessarily in order of
priority):

1. Is it open source and compatible with GRASS's GPL license?
2. How well can it accomplish the GUI functions? Most especially important
is how it can handle the display/visualization management since GRASS's
modular structure makes creating an interface to most commands relatively
straightforward (digitizing and georeferencing being notable exceptions).
3. How well can it create a consistent and platform-appropriate interface
across the many OS platforms on which GRASS runs? Ideally, we should only
have to code the GUI once in order to deploy it across multiple platforms.
In order for GRASS to be used easily on these platforms, how well can it do
this without relying on X11?
4. How easily can it be used by GRASS's volunteer developer community, most
of whom are researchers? This is important for both development and longer
term maintenance.
5. Does it require any special tools for development that might be of
limited availability? Are open source development tools available for all
platforms on which it runs?
6. Does it require any special packages to run that would significantly add
to GRASS's overhead or make installation more difficult?
7. How well and easily can it create a GUI that is easy to use--for both
newcomers and experienced GRASS users--and visually appealing?

Suggestions for the next steps:

1. Given comments over the past few months, it seems that developers and
users are generally satisfied with the design direction GRASS has taken.
Unless there strong arguments to the contrary, I suggest that we 'freeze'
this for GRASS 6.2 and simply work on bugs (tweaks, error trapping, fixing
region issues, finding and fixing other errors). I can try working on an
ipoints replacement if the general freeze for 6.2 drags on for awhile, but
am hesitant to put an inordinate amount of work into it if we are going to
change to a new platform soon. There are some other design issues that are
very much worth considering (e.g., replacing some or most of the menu
hierarchy with a toolbox approach, offering multiple display modes,
integrating 2D and 3D visualization in some way, creating an interface for
vector attribute management), but which can be left to 6.3.

2. Continue discussions as needed on GUI platforms. Once the 6.2 freeze is
in, take a vote on which platform to use. It would really help if people who
have some familiarity with whichever platform we choose are willing to help
start porting the GUI to that platform.

3. Start GUI development for 6.3 in the new platform. Revisit existing
design issues so that they can be addressed in the new platform.

Michael

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

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

2

2. Continue discussions as needed on GUI platforms. Once the 6.2
freeze is in, take a vote on which platform to use.

Why wait for 6.2 to decide?

Hamish

3

I only figured that everyone would be kind of tied up with getting 6.2 out
the door. It's better if we can decide sooner than later.

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

From: Hamish <hamish_nospam@yahoo.com>
Date: Tue, 23 May 2006 13:12:23 +1200
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] GUI platforms

2. Continue discussions as needed on GUI platforms. Once the 6.2
freeze is in, take a vote on which platform to use.

Why wait for 6.2 to decide?

Hamish

4

On Mon, 22 May 2006 14:32:08 -0700
Michael Barton <michael.barton@asu.edu> wrote:

The recent discussion over where to head in terms of GUI platforms for GRASS
is very useful. Here are some suggestions about how to proceed and structure
this important design decision. Please feel free to suggest or amend.

Primary functions of the GRASS GUI:

1. Provide a GUI interface for GRASS program modules. This includes simple
dialogs and more complex modules like v.digit that also require
visualization

Do you envision something that would be a plugin replacement for
g.parser that would possibly allow for more interactive dialogues, but
would allow existing modules to work without modification. If so I
think this would be ideal, but not being familiar with that code I
don't know what is possible.

2. Provide a CLI interface for GRASS program modules

Do we need to drop bash? If so a lot of existing modules and add on's
will go away or need to be ported for 6.3. Or do we envision providing
something like a language based shell (eg Python) as well as bash for
6.3 to allow for transition and dropping shell programming for 6.4 or
6.5 (I now way out in the future, but worth thinking about so we don't
make short term decisions that limit that vision).

3. Manage graphical display/visualization for GRASS geospatial
data--particularly raster and vector files, but also including display
enhancements like profiles, scales, text, grids, etc. This also includes
2.5-3D display handled by NVIZ and output of graphical displays to files for
inclusion in other applications.
4. Manage non-graphic output from GRASS commands--normally as text.

For example something that will parse text and convert it to a gui
format?

5. Provide an interface for interactive attribute management for vector
data. This is not currently handled in the GUI, but could be.

Yes, this would be highly desirable.

Some questions to ask about GUI platforms (not necessarily in order of
priority):

1. Is it open source and compatible with GRASS's GPL license?
2. How well can it accomplish the GUI functions? Most especially important
is how it can handle the display/visualization management since GRASS's
modular structure makes creating an interface to most commands relatively
straightforward (digitizing and georeferencing being notable exceptions).
3. How well can it create a consistent and platform-appropriate interface
across the many OS platforms on which GRASS runs? Ideally, we should only
have to code the GUI once in order to deploy it across multiple platforms.
In order for GRASS to be used easily on these platforms, how well can it do
this without relying on X11?
4. How easily can it be used by GRASS's volunteer developer community, most
of whom are researchers? This is important for both development and longer
term maintenance.
5. Does it require any special tools for development that might be of
limited availability? Are open source development tools available for all
platforms on which it runs?
6. Does it require any special packages to run that would significantly add
to GRASS's overhead or make installation more difficult?

I think the opposite is a better way to think about this, can we in
fact lighten the load. The fewer dependencies possible without giving up
functionality is highly desirable from a maintenance and distribution
point of view.

7. How well and easily can it create a GUI that is easy to use--for both
newcomers and experienced GRASS users--and visually appealing?

8. Does the platform under consideration create another potential
rewrite down the road. Right now we are talking about a complete
rewrite, because of the limitations of Tcl/Tk. I don't think we want to
find ourselves in this situation again any time soon, so if we come
down to two or three options and find that one will work for now, but
may limit us in the future, we probably want to remove it from
consideration.

Suggestions for the next steps:

1. Given comments over the past few months, it seems that developers and
users are generally satisfied with the design direction GRASS has taken.
Unless there strong arguments to the contrary, I suggest that we 'freeze'
this for GRASS 6.2 and simply work on bugs (tweaks, error trapping, fixing
region issues, finding and fixing other errors). I can try working on an
ipoints replacement if the general freeze for 6.2 drags on for awhile, but
am hesitant to put an inordinate amount of work into it if we are going to
change to a new platform soon. There are some other design issues that are
very much worth considering (e.g., replacing some or most of the menu
hierarchy with a toolbox approach, offering multiple display modes,
integrating 2D and 3D visualization in some way, creating an interface for
vector attribute management), but which can be left to 6.3.

2. Continue discussions as needed on GUI platforms. Once the 6.2 freeze is
in, take a vote on which platform to use. It would really help if people who
have some familiarity with whichever platform we choose are willing to help
start porting the GUI to that platform.

I like the idea of taking some time to think about this as I am finding
I am continuing to learn about different options as this discussion
unfolds.

3. Start GUI development for 6.3 in the new platform. Revisit existing
design issues so that they can be addressed in the new platform.

Thanks Michael.

T
--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

5

Trevor,

Thanks for the feedback. My answers below.

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

From: Trevor Wiens <twiens@interbaun.com>
Date: Mon, 22 May 2006 21:45:08 -0600
To: Michael Barton <michael.barton@asu.edu>
Cc: grass developers list <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] GUI platforms

On Mon, 22 May 2006 14:32:08 -0700
Michael Barton <michael.barton@asu.edu> wrote:

The recent discussion over where to head in terms of GUI platforms for GRASS
is very useful. Here are some suggestions about how to proceed and structure
this important design decision. Please feel free to suggest or amend.

Primary functions of the GRASS GUI:

1. Provide a GUI interface for GRASS program modules. This includes simple
dialogs and more complex modules like v.digit that also require
visualization

Do you envision something that would be a plugin replacement for
g.parser that would possibly allow for more interactive dialogues, but
would allow existing modules to work without modification. If so I
think this would be ideal, but not being familiar with that code I
don't know what is possible.

I'm talking about functionality at a conceptual level, not implementation.
How to do this might vary depending on the platform chosen. Since (I think)
g.parser is specific to TclTk, a new version would need to be written that
is not--either in the GUI platform or in GRASS functions/libraries.

2. Provide a CLI interface for GRASS program modules

Do we need to drop bash? If so a lot of existing modules and add on's
will go away or need to be ported for 6.3. Or do we envision providing
something like a language based shell (eg Python) as well as bash for
6.3 to allow for transition and dropping shell programming for 6.4 or
6.5 (I now way out in the future, but worth thinking about so we don't
make short term decisions that limit that vision).

We should NOT drop Bash--or any other scripting language currently use. The
point here is if we don't require X11, you can't depend on a terminal being
there (e.g., in Windows or Mac). So the GUI should include a command line
interface to make sure that it will be possible to issue grass commands and
run any script whether GRASS is launched from a terminal or not. We've
already done that to a large extent--initially with my command console and
now with Cedric's gronsole. You can enter any command there that the shell
will accept, as well as GRASS commands.

3. Manage graphical display/visualization for GRASS geospatial
data--particularly raster and vector files, but also including display
enhancements like profiles, scales, text, grids, etc. This also includes
2.5-3D display handled by NVIZ and output of graphical displays to files for
inclusion in other applications.
4. Manage non-graphic output from GRASS commands--normally as text.

For example something that will parse text and convert it to a gui
format?

That would be nice. But again, this is a function of not being able to
depend on the presence of an X11 terminal. So text output from commands will
need to end up somewhere. Currently it goes either to the module dialog
output tab window or to the gronsole (primarily for display-related
commands). In whatever manner, the GUI needs to handle output from GRASS
commands in a consistent (and hopefully elegant) manner.

5. Provide an interface for interactive attribute management for vector
data. This is not currently handled in the GUI, but could be.

Yes, this would be highly desirable.

I agree. If we were sticking with TclTk, I think I almost have the knowledge
to create this.

Some questions to ask about GUI platforms (not necessarily in order of
priority):

1. Is it open source and compatible with GRASS's GPL license?
2. How well can it accomplish the GUI functions? Most especially important
is how it can handle the display/visualization management since GRASS's
modular structure makes creating an interface to most commands relatively
straightforward (digitizing and georeferencing being notable exceptions).
3. How well can it create a consistent and platform-appropriate interface
across the many OS platforms on which GRASS runs? Ideally, we should only
have to code the GUI once in order to deploy it across multiple platforms.
In order for GRASS to be used easily on these platforms, how well can it do
this without relying on X11?
4. How easily can it be used by GRASS's volunteer developer community, most
of whom are researchers? This is important for both development and longer
term maintenance.
5. Does it require any special tools for development that might be of
limited availability? Are open source development tools available for all
platforms on which it runs?
6. Does it require any special packages to run that would significantly add
to GRASS's overhead or make installation more difficult?

I think the opposite is a better way to think about this, can we in
fact lighten the load. The fewer dependencies possible without giving up
functionality is highly desirable from a maintenance and distribution
point of view.

Again, I agree. However, I have to say that compared with other GIS's of
comparable ability, GRASS's footprint is pretty small--even if you include
all related libraries.

7. How well and easily can it create a GUI that is easy to use--for both
newcomers and experienced GRASS users--and visually appealing?

8. Does the platform under consideration create another potential
rewrite down the road. Right now we are talking about a complete
rewrite, because of the limitations of Tcl/Tk. I don't think we want to
find ourselves in this situation again any time soon, so if we come
down to two or three options and find that one will work for now, but
may limit us in the future, we probably want to remove it from
consideration.

Absolutely. TclTk has been with GRASS for about a decade. This is pretty
good. If any new GUI platform lasts this long, it will be great.

Suggestions for the next steps:

1. Given comments over the past few months, it seems that developers and
users are generally satisfied with the design direction GRASS has taken.
Unless there strong arguments to the contrary, I suggest that we 'freeze'
this for GRASS 6.2 and simply work on bugs (tweaks, error trapping, fixing
region issues, finding and fixing other errors). I can try working on an
ipoints replacement if the general freeze for 6.2 drags on for awhile, but
am hesitant to put an inordinate amount of work into it if we are going to
change to a new platform soon. There are some other design issues that are
very much worth considering (e.g., replacing some or most of the menu
hierarchy with a toolbox approach, offering multiple display modes,
integrating 2D and 3D visualization in some way, creating an interface for
vector attribute management), but which can be left to 6.3.

2. Continue discussions as needed on GUI platforms. Once the 6.2 freeze is
in, take a vote on which platform to use. It would really help if people who
have some familiarity with whichever platform we choose are willing to help
start porting the GUI to that platform.

I like the idea of taking some time to think about this as I am finding
I am continuing to learn about different options as this discussion
unfolds.

No need to delay this unnecessarily. The sooner we decide on a platform and
get started, the sooner we can get to GRASS 7 :slight_smile:

Nonetheless, this is a big decision and we should not rush into it.

Cheers
Michael

3. Start GUI development for 6.3 in the new platform. Revisit existing
design issues so that they can be addressed in the new platform.

Thanks Michael.

T
--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

6

Since (I think) g.parser is specific to TclTk, a new version would
need to be written that is not--either in the GUI platform or in GRASS
functions/libraries.

Probably it will be best to parse the existing XML --interface-description
either in real-time, at main compile time, or rebuild a module DB in CVS
whenever a new module is added. I expect it is much harder to "source" &
compile command files at run time with other toolkits than it is with
TclTk (??).

Hamish

7

2. Provide a CLI interface for GRASS program modules

Do we need to drop bash? If so a lot of existing modules and add on's
will go away or need to be ported for 6.3. Or do we envision providing
something like a language based shell (eg Python) as well as bash for
6.3 to allow for transition and dropping shell programming for 6.4 or
6.5 (I now way out in the future, but worth thinking about so we don't
make short term decisions that limit that vision).

GRASS doesn't just depend on an X11 display; it depends on Unix. You
can't remove the Unix part and still have GRASS. Unix permiates GRASS
to the core. The GUI should make it easier to use GRASS and Unix not
try to replace it.

8

True.

However, you need a way of communicating with the OS. And a repeated request
is to maintain a CLI for such communication. Hence, there needs to be a
terminal-like interface built into the the GUI where commands can be issued.

A further complicating factor is running GRASS under Windows. Even though
I'm not a big Windows fan, a LOT of people use this platform. It would be
great if GRASS could run in Window without the Cygwin emulator. There is a
version in development now that compiles under MinGW to create a
'Windows-native' GRASS. I assume that you can't issue Unix commands in that
environment. But you should be able to issue commands for Windows versions
of scripting languages like Python.

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

From: David Finlayson <david.p.finlayson@gmail.com>
Date: Mon, 22 May 2006 22:34:36 -0700
To: Michael Barton <michael.barton@asu.edu>
Cc: Trevor Wiens <twiens@interbaun.com>, grass developers list
<grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] GUI platforms

2. Provide a CLI interface for GRASS program modules

Do we need to drop bash? If so a lot of existing modules and add on's
will go away or need to be ported for 6.3. Or do we envision providing
something like a language based shell (eg Python) as well as bash for
6.3 to allow for transition and dropping shell programming for 6.4 or
6.5 (I now way out in the future, but worth thinking about so we don't
make short term decisions that limit that vision).

GRASS doesn't just depend on an X11 display; it depends on Unix. You
can't remove the Unix part and still have GRASS. Unix permiates GRASS
to the core. The GUI should make it easier to use GRASS and Unix not
try to replace it.

9

On Mon, 22 May 2006 22:46:10 -0700
Michael Barton <michael.barton@asu.edu> wrote:

<snip>

I assume that you can't issue Unix commands in that environment.

Using the Qgis internal Grass shell you can.

http://mpa.itc.it/radim/wingrass/ says:

GRASS scripts works both from GRASS tools and shell

Propably thanks to Msys http://www.mingw.org/msys.shtml. ?

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

10

Is the goal to eliminate the GRASS dependency on a Unix environment?
To me, that sounds like throwing the baby out with the bath water.

Why not just merge with Qgis?

David

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

True.

However, you need a way of communicating with the OS. And a repeated request
is to maintain a CLI for such communication. Hence, there needs to be a
terminal-like interface built into the the GUI where commands can be issued.

A further complicating factor is running GRASS under Windows. Even though
I'm not a big Windows fan, a LOT of people use this platform. It would be
great if GRASS could run in Window without the Cygwin emulator. There is a
version in development now that compiles under MinGW to create a
'Windows-native' GRASS. I assume that you can't issue Unix commands in that
environment. But you should be able to issue commands for Windows versions
of scripting languages like Python.

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

> From: David Finlayson <david.p.finlayson@gmail.com>
> Date: Mon, 22 May 2006 22:34:36 -0700
> To: Michael Barton <michael.barton@asu.edu>
> Cc: Trevor Wiens <twiens@interbaun.com>, grass developers list
> <grass-dev@grass.itc.it>
> Subject: Re: [GRASS-dev] GUI platforms
>
>>> 2. Provide a CLI interface for GRASS program modules
>>
>> Do we need to drop bash? If so a lot of existing modules and add on's
>> will go away or need to be ported for 6.3. Or do we envision providing
>> something like a language based shell (eg Python) as well as bash for
>> 6.3 to allow for transition and dropping shell programming for 6.4 or
>> 6.5 (I now way out in the future, but worth thinking about so we don't
>> make short term decisions that limit that vision).
>
> GRASS doesn't just depend on an X11 display; it depends on Unix. You
> can't remove the Unix part and still have GRASS. Unix permiates GRASS
> to the core. The GUI should make it easier to use GRASS and Unix not
> try to replace it.

--
David Finlayson

11

On 5/23/06, Maciek Sieczka <werchowyna@epf.pl> wrote:

> I assume that you can't issue Unix commands in that environment.

Using the Qgis internal Grass shell you can.

The version for Windows is using MSYS terminal+bash not
the built-in shell. Of course it is possible to run GRASS modules
+ cca 60 standard UNIX commands (sed, gawk, grep, ....)

Radim

http://mpa.itc.it/radim/wingrass/ says:

> GRASS scripts works both from GRASS tools and shell

Propably thanks to Msys http://www.mingw.org/msys.shtml. ?

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

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

12

Michael Barton wrote:

> Do you envision something that would be a plugin replacement for
> g.parser that would possibly allow for more interactive dialogues, but
> would allow existing modules to work without modification. If so I
> think this would be ideal, but not being familiar with that code I
> don't know what is possible.

I'm talking about functionality at a conceptual level, not implementation.
How to do this might vary depending on the platform chosen. Since (I think)
g.parser is specific to TclTk, a new version would need to be written that
is not--either in the GUI platform or in GRASS functions/libraries.

"g.parser" isn't specific to Tcl/Tk. G_parser() includes functionality
to output a description of the command-line options in Tcl/Tk syntax.
This can still be used by a non-Tcl/Tk GUI in one of two ways:

1. Use the --ui switch, which spawns "wish" and feeds the Tcl/Tk code
to it (gis.m uses the --tcltk switch, which just writes the Tcl/Tk
code to stdout).

2. Parse the Tcl/Tk code. The generated code is extremely restricted
in its form, and could easily be parsed by a C program.

Alternatively, a C module could use the XML generated by the
--interface-description switch. Or G_parser() could easily be extended
to generate a different format (e.g. XML usable by the Glade library).

--
Glynn Clements <glynn@gclements.plus.com>

13

David Finlayson wrote:

>> 2. Provide a CLI interface for GRASS program modules
>
> Do we need to drop bash? If so a lot of existing modules and add on's
> will go away or need to be ported for 6.3. Or do we envision providing
> something like a language based shell (eg Python) as well as bash for
> 6.3 to allow for transition and dropping shell programming for 6.4 or
> 6.5 (I now way out in the future, but worth thinking about so we don't
> make short term decisions that limit that vision).

GRASS doesn't just depend on an X11 display; it depends on Unix.

Not really. Most of the Unix-specific code in GRASS could easily be
supplemented with equivalent Windows code.

You
can't remove the Unix part and still have GRASS. Unix permiates GRASS
to the core. The GUI should make it easier to use GRASS and Unix not
try to replace it.

If you're referring to command-line usage, that isn't Unix specific.
You can run bash (or csh, zsh etc) on Windows, or use cmd.exe (which
is a lot less capable than a Unix shell, but Windows users may be more
comfortable with it).

Also, one of the by-products of the GUI work will be to make existing
command-line modules more suitable for use in scripts. A common
problem with several modules is the use of the terminal for
question-and-answer interaction. Getting rid of that is necessary for
the GUI but will also benefit scripting.

--
Glynn Clements <glynn@gclements.plus.com>

14

David Finlayson wrote:

Is the goal to eliminate the GRASS dependency on a Unix environment?

Yes. GRASS should also work on Windows (with neither Cygwin nor an X
server) and MacOSX (without an X server) as well as it does on Unix.

To me, that sounds like throwing the baby out with the bath water.

Nothing is getting "thrown out".

--
Glynn Clements <glynn@gclements.plus.com>

15

Thanks for the clarification.

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

From: Radim Blazek <radim.blazek@gmail.com>
Date: Tue, 23 May 2006 09:18:00 +0200
To: Maciek Sieczka <werchowyna@epf.pl>
Cc: Michael Barton <michael.barton@asu.edu>, <twiens@interbaun.com>,
<david.p.finlayson@gmail.com>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] GUI platforms

On 5/23/06, Maciek Sieczka <werchowyna@epf.pl> wrote:

I assume that you can't issue Unix commands in that environment.

Using the Qgis internal Grass shell you can.

The version for Windows is using MSYS terminal+bash not
the built-in shell. Of course it is possible to run GRASS modules
+ cca 60 standard UNIX commands (sed, gawk, grep, ....)

Radim

http://mpa.itc.it/radim/wingrass/ says:

GRASS scripts works both from GRASS tools and shell

Propably thanks to Msys http://www.mingw.org/msys.shtml. ?

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko
najlepsze z nich!
http://katalog.panoramainternetu.pl/

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

16

This flexibility will make it easier to switch to a different GUI platform.

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

From: Glynn Clements <glynn@gclements.plus.com>
Date: Tue, 23 May 2006 08:50:29 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Trevor Wiens <twiens@interbaun.com>, grass developers list
<grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] GUI platforms

Michael Barton wrote:

Do you envision something that would be a plugin replacement for
g.parser that would possibly allow for more interactive dialogues, but
would allow existing modules to work without modification. If so I
think this would be ideal, but not being familiar with that code I
don't know what is possible.

I'm talking about functionality at a conceptual level, not implementation.
How to do this might vary depending on the platform chosen. Since (I think)
g.parser is specific to TclTk, a new version would need to be written that
is not--either in the GUI platform or in GRASS functions/libraries.

"g.parser" isn't specific to Tcl/Tk. G_parser() includes functionality
to output a description of the command-line options in Tcl/Tk syntax.
This can still be used by a non-Tcl/Tk GUI in one of two ways:

1. Use the --ui switch, which spawns "wish" and feeds the Tcl/Tk code
to it (gis.m uses the --tcltk switch, which just writes the Tcl/Tk
code to stdout).

2. Parse the Tcl/Tk code. The generated code is extremely restricted
in its form, and could easily be parsed by a C program.

Alternatively, a C module could use the XML generated by the
--interface-description switch. Or G_parser() could easily be extended
to generate a different format (e.g. XML usable by the Glade library).

--
Glynn Clements <glynn@gclements.plus.com>

17

Is the goal to eliminate the GRASS dependency on a Unix environment?

Yes. GRASS should also work on Windows (with neither Cygwin nor an X
server) and MacOSX (without an X server) as well as it does on Unix.

As I said, that IS throwing the baby out with the bathwater.

GRASS on Unix is more than just a collection of GIS programs. It is
also 50 or more Unix commands, a powerful shell, and a philosophy
about how to integrate those tools seamlessly. None of those things
exist on Windows, and they only exist in OS X if you go out of your
way to activate the Unix underpinnings of the OS.

Frankly, Unix IS primitive in some ways. All modules communicate by
text strings. But it is a lot easier to pepper a new program with
print statements than to implement an entire RPC infrastructure such
as IDispatch on Windows. A crappy programmer like me can get things
done. Something more sophisticated will reduce the pool of programmers
accordingly.

Eliminate Unix and in one fell swoop every script in GRASS is
unusable. All 50+ of the official scripts will need to be rewritten in
Python or whatever the script language de jour is. Some things that we
take for granted today (like grep, sed, awk, head, tail, cut...),
stuff I use every day, is going too. Every one of them will need an
OS-specific replacement or complete recode in a portable language.

The most compelling reason not to go down this road is ArcGIS itslef.
They did EXACTLY this 10 years ago. Dumped Unix and went to an all GUI
infrastructure. I can hardly call it an unsuccessful move...ESRI is
the 900 lb gorilla of GIS now. But have you ever tried to automate it?
Its a nightmare.

Now they are bolting on a model builder and trying to get
COM-compliant scripting languages like Python to work with their API.
There is a lot of boilerplate code for each script that needs to be
written because of the RPC needed between tools. Frankly, they are
reinventing what they lost when the dumped the command line and they
are having a difficult time of it. IT is hard to program and the
enormous API is difficult to debug, so the whole thing is buggy,
fragile and slow.

What you guys are proposing with the GUI change is really much more
than that. It is a fundamental re-architecture of the GRASS program. A
few of us have been alarmed by it. Maybe a lot more people are
relieved. But at any rate it seems like that decision should be more
transparent to the community of GRASS users.

A good OS X program is not a good Unix program (though it might be
more popular with more people).

David

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

This flexibility will make it easier to switch to a different GUI platform.

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

> From: Glynn Clements <glynn@gclements.plus.com>
> Date: Tue, 23 May 2006 08:50:29 +0100
> To: Michael Barton <michael.barton@asu.edu>
> Cc: Trevor Wiens <twiens@interbaun.com>, grass developers list
> <grass-dev@grass.itc.it>
> Subject: Re: [GRASS-dev] GUI platforms
>
> Michael Barton wrote:
>
>>> Do you envision something that would be a plugin replacement for
>>> g.parser that would possibly allow for more interactive dialogues, but
>>> would allow existing modules to work without modification. If so I
>>> think this would be ideal, but not being familiar with that code I
>>> don't know what is possible.
>>
>> I'm talking about functionality at a conceptual level, not implementation.
>> How to do this might vary depending on the platform chosen. Since (I think)
>> g.parser is specific to TclTk, a new version would need to be written that
>> is not--either in the GUI platform or in GRASS functions/libraries.
>
> "g.parser" isn't specific to Tcl/Tk. G_parser() includes functionality
> to output a description of the command-line options in Tcl/Tk syntax.
> This can still be used by a non-Tcl/Tk GUI in one of two ways:
>
> 1. Use the --ui switch, which spawns "wish" and feeds the Tcl/Tk code
> to it (gis.m uses the --tcltk switch, which just writes the Tcl/Tk
> code to stdout).
>
> 2. Parse the Tcl/Tk code. The generated code is extremely restricted
> in its form, and could easily be parsed by a C program.
>
> Alternatively, a C module could use the XML generated by the
> --interface-description switch. Or G_parser() could easily be extended
> to generate a different format (e.g. XML usable by the Glade library).
>
> --
> Glynn Clements <glynn@gclements.plus.com>

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

--
David Finlayson

18

I should add this:

1. I really like the new GUI. I am not implying by the above that GUIs
are bad --- just that I feel Unix should remain a dependency of GRASS.
(How hard is it to install Cygwin?)

2. I really respect the commitment that you (Glynn and Michael in
particular) have made to GRASS and free gis. I am trying to return
something myself (how do you both find the time??)

David

On 5/23/06, David Finlayson <david.p.finlayson@gmail.com> wrote:

>> Is the goal to eliminate the GRASS dependency on a Unix environment?

> Yes. GRASS should also work on Windows (with neither Cygwin nor an X
> server) and MacOSX (without an X server) as well as it does on Unix.

As I said, that IS throwing the baby out with the bathwater.

GRASS on Unix is more than just a collection of GIS programs. It is
also 50 or more Unix commands, a powerful shell, and a philosophy
about how to integrate those tools seamlessly. None of those things
exist on Windows, and they only exist in OS X if you go out of your
way to activate the Unix underpinnings of the OS.

Frankly, Unix IS primitive in some ways. All modules communicate by
text strings. But it is a lot easier to pepper a new program with
print statements than to implement an entire RPC infrastructure such
as IDispatch on Windows. A crappy programmer like me can get things
done. Something more sophisticated will reduce the pool of programmers
accordingly.

Eliminate Unix and in one fell swoop every script in GRASS is
unusable. All 50+ of the official scripts will need to be rewritten in
Python or whatever the script language de jour is. Some things that we
take for granted today (like grep, sed, awk, head, tail, cut...),
stuff I use every day, is going too. Every one of them will need an
OS-specific replacement or complete recode in a portable language.

The most compelling reason not to go down this road is ArcGIS itslef.
They did EXACTLY this 10 years ago. Dumped Unix and went to an all GUI
infrastructure. I can hardly call it an unsuccessful move...ESRI is
the 900 lb gorilla of GIS now. But have you ever tried to automate it?
Its a nightmare.

Now they are bolting on a model builder and trying to get
COM-compliant scripting languages like Python to work with their API.
There is a lot of boilerplate code for each script that needs to be
written because of the RPC needed between tools. Frankly, they are
reinventing what they lost when the dumped the command line and they
are having a difficult time of it. IT is hard to program and the
enormous API is difficult to debug, so the whole thing is buggy,
fragile and slow.

What you guys are proposing with the GUI change is really much more
than that. It is a fundamental re-architecture of the GRASS program. A
few of us have been alarmed by it. Maybe a lot more people are
relieved. But at any rate it seems like that decision should be more
transparent to the community of GRASS users.

A good OS X program is not a good Unix program (though it might be
more popular with more people).

David

On 5/23/06, Michael Barton <michael.barton@asu.edu> wrote:
> This flexibility will make it easier to switch to a different GUI platform.
>
> 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
>
> > From: Glynn Clements <glynn@gclements.plus.com>
> > Date: Tue, 23 May 2006 08:50:29 +0100
> > To: Michael Barton <michael.barton@asu.edu>
> > Cc: Trevor Wiens <twiens@interbaun.com>, grass developers list
> > <grass-dev@grass.itc.it>
> > Subject: Re: [GRASS-dev] GUI platforms
> >
> > Michael Barton wrote:
> >
> >>> Do you envision something that would be a plugin replacement for
> >>> g.parser that would possibly allow for more interactive dialogues, but
> >>> would allow existing modules to work without modification. If so I
> >>> think this would be ideal, but not being familiar with that code I
> >>> don't know what is possible.
> >>
> >> I'm talking about functionality at a conceptual level, not implementation.
> >> How to do this might vary depending on the platform chosen. Since (I think)
> >> g.parser is specific to TclTk, a new version would need to be written that
> >> is not--either in the GUI platform or in GRASS functions/libraries.
> >
> > "g.parser" isn't specific to Tcl/Tk. G_parser() includes functionality
> > to output a description of the command-line options in Tcl/Tk syntax.
> > This can still be used by a non-Tcl/Tk GUI in one of two ways:
> >
> > 1. Use the --ui switch, which spawns "wish" and feeds the Tcl/Tk code
> > to it (gis.m uses the --tcltk switch, which just writes the Tcl/Tk
> > code to stdout).
> >
> > 2. Parse the Tcl/Tk code. The generated code is extremely restricted
> > in its form, and could easily be parsed by a C program.
> >
> > Alternatively, a C module could use the XML generated by the
> > --interface-description switch. Or G_parser() could easily be extended
> > to generate a different format (e.g. XML usable by the Glade library).
> >
> > --
> > Glynn Clements <glynn@gclements.plus.com>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>

--
David Finlayson

--
David Finlayson

19

David,

We are not proposing to get rid of anything. All scripts will continue to
work as they do now in all *nix environments. I've written a number of them,
am creating more in my ongoing research, and use them regularly. The only
things suggested for change in GRASS modules related to the UI are:

1) make modules that require interactive terminal use (i.e., questions and
answers) be useable by standard command line arguments. This will make them
more scriptable under Bash or any other scripting. It will also make them
easier to use in a variety of UI's

2) provide a way to see maps and other display items that does not depend on
X11 displays only. Again, this makes visualization more flexible, not less.

GRASS is ALREADY compiled to run natively on Windows under MinGW. It is
making NO difference to anyone's ability to coordinate GRASS with Bash or
any other scripting language. GRASS ALREADY can run natively without X11 on
the Mac. Again, it does not diminish any access to shell commands or
scripting.

You primarily seem to be responding to my statement about wanting to build
in CLI facilities to the GUI. This is so that users CAN run Unix and other
commands, even if they do not open a separate terminal. It makes the kind of
flexibility you like available to all GRASS users, regardless of the
environment they are working in. You can use a variety of terminal programs
in X11, for example if you don't like the basic "term" that comes with it.
I'm just suggesting that the GUI should ALSO include a terminal interface so
that users can access CLI functions.

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

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

From: David Finlayson <david.p.finlayson@gmail.com>
Date: Tue, 23 May 2006 10:13:23 -0700
To: Michael Barton <michael.barton@asu.edu>
Cc: Glynn Clements <glynn@gclements.plus.com>, Trevor Wiens
<twiens@interbaun.com>, grass developers list <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] GUI platforms

Is the goal to eliminate the GRASS dependency on a Unix environment?

Yes. GRASS should also work on Windows (with neither Cygwin nor an X
server) and MacOSX (without an X server) as well as it does on Unix.

As I said, that IS throwing the baby out with the bathwater.

GRASS on Unix is more than just a collection of GIS programs. It is
also 50 or more Unix commands, a powerful shell, and a philosophy
about how to integrate those tools seamlessly. None of those things
exist on Windows, and they only exist in OS X if you go out of your
way to activate the Unix underpinnings of the OS.

Frankly, Unix IS primitive in some ways. All modules communicate by
text strings. But it is a lot easier to pepper a new program with
print statements than to implement an entire RPC infrastructure such
as IDispatch on Windows. A crappy programmer like me can get things
done. Something more sophisticated will reduce the pool of programmers
accordingly.

Eliminate Unix and in one fell swoop every script in GRASS is
unusable. All 50+ of the official scripts will need to be rewritten in
Python or whatever the script language de jour is. Some things that we
take for granted today (like grep, sed, awk, head, tail, cut...),
stuff I use every day, is going too. Every one of them will need an
OS-specific replacement or complete recode in a portable language.

The most compelling reason not to go down this road is ArcGIS itslef.
They did EXACTLY this 10 years ago. Dumped Unix and went to an all GUI
infrastructure. I can hardly call it an unsuccessful move...ESRI is
the 900 lb gorilla of GIS now. But have you ever tried to automate it?
Its a nightmare.

Now they are bolting on a model builder and trying to get
COM-compliant scripting languages like Python to work with their API.
There is a lot of boilerplate code for each script that needs to be
written because of the RPC needed between tools. Frankly, they are
reinventing what they lost when the dumped the command line and they
are having a difficult time of it. IT is hard to program and the
enormous API is difficult to debug, so the whole thing is buggy,
fragile and slow.

What you guys are proposing with the GUI change is really much more
than that. It is a fundamental re-architecture of the GRASS program. A
few of us have been alarmed by it. Maybe a lot more people are
relieved. But at any rate it seems like that decision should be more
transparent to the community of GRASS users.

A good OS X program is not a good Unix program (though it might be
more popular with more people).

David

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

This flexibility will make it easier to switch to a different GUI platform.

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

From: Glynn Clements <glynn@gclements.plus.com>
Date: Tue, 23 May 2006 08:50:29 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Trevor Wiens <twiens@interbaun.com>, grass developers list
<grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] GUI platforms

Michael Barton wrote:

Do you envision something that would be a plugin replacement for
g.parser that would possibly allow for more interactive dialogues, but
would allow existing modules to work without modification. If so I
think this would be ideal, but not being familiar with that code I
don't know what is possible.

I'm talking about functionality at a conceptual level, not implementation.
How to do this might vary depending on the platform chosen. Since (I think)
g.parser is specific to TclTk, a new version would need to be written that
is not--either in the GUI platform or in GRASS functions/libraries.

"g.parser" isn't specific to Tcl/Tk. G_parser() includes functionality
to output a description of the command-line options in Tcl/Tk syntax.
This can still be used by a non-Tcl/Tk GUI in one of two ways:

1. Use the --ui switch, which spawns "wish" and feeds the Tcl/Tk code
to it (gis.m uses the --tcltk switch, which just writes the Tcl/Tk
code to stdout).

2. Parse the Tcl/Tk code. The generated code is extremely restricted
in its form, and could easily be parsed by a C program.

Alternatively, a C module could use the XML generated by the
--interface-description switch. Or G_parser() could easily be extended
to generate a different format (e.g. XML usable by the Glade library).

--
Glynn Clements <glynn@gclements.plus.com>

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

--
David Finlayson

20

Thanks David. I hope my last response clarifies things.

There is really no issue for Mac. It IS Unix. The issue under windows is
that Cygwin is simply a problem for many Windows users. It there is a way to
run GRASS without it, it will make GRASS available to a much wider audience
that wants to run it.

It may also make them want to switch to Linux or Mac if they find they can't
do all the things that you describe to enhance GRASS :wink:

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

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

From: David Finlayson <david.p.finlayson@gmail.com>
Date: Tue, 23 May 2006 10:28:54 -0700
To: Michael Barton <michael.barton@asu.edu>
Cc: Glynn Clements <glynn@gclements.plus.com>, Trevor Wiens
<twiens@interbaun.com>, grass developers list <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] GUI platforms

I should add this:

1. I really like the new GUI. I am not implying by the above that GUIs
are bad --- just that I feel Unix should remain a dependency of GRASS.
(How hard is it to install Cygwin?)

2. I really respect the commitment that you (Glynn and Michael in
particular) have made to GRASS and free gis. I am trying to return
something myself (how do you both find the time??)

David

On 5/23/06, David Finlayson <david.p.finlayson@gmail.com> wrote:

Is the goal to eliminate the GRASS dependency on a Unix environment?

Yes. GRASS should also work on Windows (with neither Cygwin nor an X
server) and MacOSX (without an X server) as well as it does on Unix.

As I said, that IS throwing the baby out with the bathwater.

GRASS on Unix is more than just a collection of GIS programs. It is
also 50 or more Unix commands, a powerful shell, and a philosophy
about how to integrate those tools seamlessly. None of those things
exist on Windows, and they only exist in OS X if you go out of your
way to activate the Unix underpinnings of the OS.

Frankly, Unix IS primitive in some ways. All modules communicate by
text strings. But it is a lot easier to pepper a new program with
print statements than to implement an entire RPC infrastructure such
as IDispatch on Windows. A crappy programmer like me can get things
done. Something more sophisticated will reduce the pool of programmers
accordingly.

Eliminate Unix and in one fell swoop every script in GRASS is
unusable. All 50+ of the official scripts will need to be rewritten in
Python or whatever the script language de jour is. Some things that we
take for granted today (like grep, sed, awk, head, tail, cut...),
stuff I use every day, is going too. Every one of them will need an
OS-specific replacement or complete recode in a portable language.

The most compelling reason not to go down this road is ArcGIS itslef.
They did EXACTLY this 10 years ago. Dumped Unix and went to an all GUI
infrastructure. I can hardly call it an unsuccessful move...ESRI is
the 900 lb gorilla of GIS now. But have you ever tried to automate it?
Its a nightmare.

Now they are bolting on a model builder and trying to get
COM-compliant scripting languages like Python to work with their API.
There is a lot of boilerplate code for each script that needs to be
written because of the RPC needed between tools. Frankly, they are
reinventing what they lost when the dumped the command line and they
are having a difficult time of it. IT is hard to program and the
enormous API is difficult to debug, so the whole thing is buggy,
fragile and slow.

What you guys are proposing with the GUI change is really much more
than that. It is a fundamental re-architecture of the GRASS program. A
few of us have been alarmed by it. Maybe a lot more people are
relieved. But at any rate it seems like that decision should be more
transparent to the community of GRASS users.

A good OS X program is not a good Unix program (though it might be
more popular with more people).

David

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

This flexibility will make it easier to switch to a different GUI platform.

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

From: Glynn Clements <glynn@gclements.plus.com>
Date: Tue, 23 May 2006 08:50:29 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Trevor Wiens <twiens@interbaun.com>, grass developers list
<grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] GUI platforms

Michael Barton wrote:

Do you envision something that would be a plugin replacement for
g.parser that would possibly allow for more interactive dialogues, but
would allow existing modules to work without modification. If so I
think this would be ideal, but not being familiar with that code I
don't know what is possible.

I'm talking about functionality at a conceptual level, not implementation.
How to do this might vary depending on the platform chosen. Since (I
think)
g.parser is specific to TclTk, a new version would need to be written that
is not--either in the GUI platform or in GRASS functions/libraries.

"g.parser" isn't specific to Tcl/Tk. G_parser() includes functionality
to output a description of the command-line options in Tcl/Tk syntax.
This can still be used by a non-Tcl/Tk GUI in one of two ways:

1. Use the --ui switch, which spawns "wish" and feeds the Tcl/Tk code
to it (gis.m uses the --tcltk switch, which just writes the Tcl/Tk
code to stdout).

2. Parse the Tcl/Tk code. The generated code is extremely restricted
in its form, and could easily be parsed by a C program.

Alternatively, a C module could use the XML generated by the
--interface-description switch. Or G_parser() could easily be extended
to generate a different format (e.g. XML usable by the Glade library).

--
Glynn Clements <glynn@gclements.plus.com>

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

--
David Finlayson

--
David Finlayson