[GRASS5] New GRASS intro

GRASS GIS GRASS GIS developer
,
1

With the move toward releasing GRASS 6.2, it’s time we had a new intro to greet users starting GRASS.

I’d hoped to make something really spiffy, easy for first time users to navigate without getting confused about GRASS jargon, but still quick for experienced users. Alas, I haven’t had the time to do all this before the impending 6.2 feature freeze, but I did manage to update things somewhat from the venerable, Spartan grey intro.

I’ve rearranged the items on the intro screen to distinguish different functions, changed the descriptions to make it clearer that locations are for projections and mapsets are where a ‘GIS’ is stored, etc. I also added a new button to create a projection location from a georeferenced file (uses GDAL/OGR via g.proj). Finally, I added some color to the intro. No I didn’t make it green, but I did add a nice GRASS graphic.

Many thanks to Markus who helped me get this committed to the cvs, where it now resides for your geospatial enjoyment.

I think the next step would be to replace the g.setproj terminal screen for defining projections with a nicer GUI one based on g.proj. Another thing would be to add a search function to the excellent EPSG codes database.

Cheers,
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

Hallo developers,

personaly I do not use the new gui, because I can not use d.* commands
(d.rast and d.vect). I thing, that the new monitors do have the right
functions (zooming, panning, redrawing, ...), but it is often faster to
write, what map one would like to see, then to click it in the gui.

Would it be possible to make run this monitors in background as daemons, so they
would "observe" the png files (png1-png7) and redraw them selve every
time, the files would be changed?

Jachym

On Tue, Apr 25, 2006 at 12:49:19PM -0700, Michael Barton wrote:

With the move toward releasing GRASS 6.2, it?s time we had a new intro to
greet users starting GRASS.

I?d hoped to make something really spiffy, easy for first time users to
navigate without getting confused about GRASS jargon, but still quick for
experienced users. Alas, I haven?t had the time to do all this before the
impending 6.2 feature freeze, but I did manage to update things somewhat
from the venerable, Spartan grey intro.

I?ve rearranged the items on the intro screen to distinguish different
functions, changed the descriptions to make it clearer that locations are
for projections and mapsets are where a ŒGIS? is stored, etc. I also added a
new button to create a projection location from a georeferenced file (uses
GDAL/OGR via g.proj). Finally, I added some color to the intro. No I didn?t
make it green, but I did add a nice GRASS graphic.

Many thanks to Markus who helped me get this committed to the cvs, where it
now resides for your geospatial enjoyment.

I think the next step would be to replace the g.setproj terminal screen for
defining projections with a nicer GUI one based on g.proj. Another thing
would be to add a search function to the excellent EPSG codes database.

Cheers,
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

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

3

I could probably make them update automatically every time anything is
changed in the layer tree. I thought about doing so and discussed this a bit
with some of the folks contributing to the GUI discussions. The general
feeling was that it would be better to let the user decide when to update
the monitor. This allows you to change multiple aspects of a set of
overlaying maps and not have to wait through a screen redraw for each
change...the way it is in some commercial packages.

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: Jachym Cepicky <jachym.cepicky@centrum.cz>
Date: Tue, 25 Apr 2006 22:29:27 +0200
To: Michael Barton <michael.barton@asu.edu>
Cc: grass developers list <grass5@grass.itc.it>, Multiple recipients of list
<GRASSLIST@baylor.edu>
Subject: Re: [GRASS5] New GRASS intro

Hallo developers,

personaly I do not use the new gui, because I can not use d.* commands
(d.rast and d.vect). I thing, that the new monitors do have the right
functions (zooming, panning, redrawing, ...), but it is often faster to
write, what map one would like to see, then to click it in the gui.

Would it be possible to make run this monitors in background as daemons, so
they
would "observe" the png files (png1-png7) and redraw them selve every
time, the files would be changed?

Jachym

On Tue, Apr 25, 2006 at 12:49:19PM -0700, Michael Barton wrote:

With the move toward releasing GRASS 6.2, it?s time we had a new intro to
greet users starting GRASS.

I?d hoped to make something really spiffy, easy for first time users to
navigate without getting confused about GRASS jargon, but still quick for
experienced users. Alas, I haven?t had the time to do all this before the
impending 6.2 feature freeze, but I did manage to update things somewhat
from the venerable, Spartan grey intro.

I?ve rearranged the items on the intro screen to distinguish different
functions, changed the descriptions to make it clearer that locations are
for projections and mapsets are where a ?GIS? is stored, etc. I also added a
new button to create a projection location from a georeferenced file (uses
GDAL/OGR via g.proj). Finally, I added some color to the intro. No I didn?t
make it green, but I did add a nice GRASS graphic.

Many thanks to Markus who helped me get this committed to the cvs, where it
now resides for your geospatial enjoyment.

I think the next step would be to replace the g.setproj terminal screen for
defining projections with a nicer GUI one based on g.proj. Another thing
would be to add a search function to the excellent EPSG codes database.

Cheers,
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

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

4

I've been a bit concerned about the loss of command line control of
the display myself. Are there plans to update the d.* commands so that
they interface with the new tcl canvas?

On 4/25/06, Jachym Cepicky <jachym.cepicky@centrum.cz> wrote:

Hallo developers,

personaly I do not use the new gui, because I can not use d.* commands
(d.rast and d.vect). I thing, that the new monitors do have the right
functions (zooming, panning, redrawing, ...), but it is often faster to
write, what map one would like to see, then to click it in the gui.

Would it be possible to make run this monitors in background as daemons, so they
would "observe" the png files (png1-png7) and redraw them selve every
time, the files would be changed?

Jachym

On Tue, Apr 25, 2006 at 12:49:19PM -0700, Michael Barton wrote:
> With the move toward releasing GRASS 6.2, it?s time we had a new intro to
> greet users starting GRASS.
>
> I?d hoped to make something really spiffy, easy for first time users to
> navigate without getting confused about GRASS jargon, but still quick for
> experienced users. Alas, I haven?t had the time to do all this before the
> impending 6.2 feature freeze, but I did manage to update things somewhat
> from the venerable, Spartan grey intro.
>
> I?ve rearranged the items on the intro screen to distinguish different
> functions, changed the descriptions to make it clearer that locations are
> for projections and mapsets are where a ŒGIS? is stored, etc. I also added a
> new button to create a projection location from a georeferenced file (uses
> GDAL/OGR via g.proj). Finally, I added some color to the intro. No I didn?t
> make it green, but I did add a nice GRASS graphic.
>
> Many thanks to Markus who helped me get this committed to the cvs, where it
> now resides for your geospatial enjoyment.
>
> I think the next step would be to replace the g.setproj terminal screen for
> defining projections with a nicer GUI one based on g.proj. Another thing
> would be to add a search function to the excellent EPSG codes database.
>
> Cheers,
> 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
>

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEToamyKt0uAjU4I8RAlwzAJ9yIySlaAB47X9+b58+E/39d3vWagCgqrjw
p2ZkL7zdmpw84qznSZI3lO0=
=3rlr
-----END PGP SIGNATURE-----

--
David Finlayson

5

Glynn can answer this best, but the short answer is yes.

However, the commands still work for simple display in an x-display just
like they always did. Just type d.mon x0 and run d.vect or d.rast as much as
you want. It shouldn't interfere with the TclTk canvas displays.

The new displays, with the nice control buttons, etc are an integrated part
of the GUI, not a simple viewing window like the x-displays are. This is the
advantage of having a more sophisticated user interface beyond the very
basic display we've had before.

If the d.* commands are updated so that they can display directly to PPM/PNG
files, without running d.mon, as planned, they can still be displayed and
composited (even with transparency) in a simple viewer using g.pnmcomp.

Everyone wants the command line interface to be maintained. However, there
are features that can be implemented in an integrated GUI in ways that are
not possible with a CLI.

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, 25 Apr 2006 13:43:36 -0700
To: Jachym Cepicky <jachym.cepicky@centrum.cz>
Cc: Michael Barton <michael.barton@asu.edu>, grass developers list
<grass5@grass.itc.it>, Multiple recipients of list <GRASSLIST@baylor.edu>
Subject: Re: [GRASS5] New GRASS intro

I've been a bit concerned about the loss of command line control of
the display myself. Are there plans to update the d.* commands so that
they interface with the new tcl canvas?

On 4/25/06, Jachym Cepicky <jachym.cepicky@centrum.cz> wrote:

Hallo developers,

personaly I do not use the new gui, because I can not use d.* commands
(d.rast and d.vect). I thing, that the new monitors do have the right
functions (zooming, panning, redrawing, ...), but it is often faster to
write, what map one would like to see, then to click it in the gui.

Would it be possible to make run this monitors in background as daemons, so
they
would "observe" the png files (png1-png7) and redraw them selve every
time, the files would be changed?

Jachym

On Tue, Apr 25, 2006 at 12:49:19PM -0700, Michael Barton wrote:

With the move toward releasing GRASS 6.2, it?s time we had a new intro to
greet users starting GRASS.

I?d hoped to make something really spiffy, easy for first time users to
navigate without getting confused about GRASS jargon, but still quick for
experienced users. Alas, I haven?t had the time to do all this before the
impending 6.2 feature freeze, but I did manage to update things somewhat
from the venerable, Spartan grey intro.

I?ve rearranged the items on the intro screen to distinguish different
functions, changed the descriptions to make it clearer that locations are
for projections and mapsets are where a ŒGIS? is stored, etc. I also added a
new button to create a projection location from a georeferenced file (uses
GDAL/OGR via g.proj). Finally, I added some color to the intro. No I didn?t
make it green, but I did add a nice GRASS graphic.

Many thanks to Markus who helped me get this committed to the cvs, where it
now resides for your geospatial enjoyment.

I think the next step would be to replace the g.setproj terminal screen for
defining projections with a nicer GUI one based on g.proj. Another thing
would be to add a search function to the excellent EPSG codes database.

Cheers,
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

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEToamyKt0uAjU4I8RAlwzAJ9yIySlaAB47X9+b58+E/39d3vWagCgqrjw
p2ZkL7zdmpw84qznSZI3lO0=
=3rlr
-----END PGP SIGNATURE-----

--
David Finlayson

6

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

Everyone wants the command line interface to be maintained. However, there
are features that can be implemented in an integrated GUI in ways that are
not possible with a CLI.

I am always torn on this issue. On the one hand, if GRASS had a
friendly user interface, maybe it wouldn't be in the GIS ghetto it is
now (in USA anyway). On the other hand, the reason I use GRASS is
because it integrates with my Unix toolbox (sed, grep, cut, etc).

If there comes a day when a Bash script isn't a first-class interface
to GRASS. Well, that's the day I stop using GRASS.

David

7

David

Scripting flexibility is one of the great benefits of GRASS. However, in
scripts one isn't doing interactive display management. This has always been
the case and remains so. We are just working to make the interactive part
much less primitive than it was before. So we are trying to add new
capabilities, not remove existing ones. On the other hand, all the
interactive display features in the new GIS Manager are carried out with
existing GRASS commands. Hence, they can be replicated in multiple display
architectures--and scripted.

As I understand the direction of the display architecture, it should be
easier that it is now to script the complex composition and output of
multiple GIS layers to a graphics file that can be viewed in multiple ways
rather than only on an x-windows display monitor.

Beyond this, the greatest power of scripting is in the ability to carry out
complex management and analysis tasks that are unique to a given project or
create functionality that is not otherwise available.

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, 25 Apr 2006 14:29:00 -0700
To: Michael Barton <michael.barton@asu.edu>
Cc: Jachym Cepicky <jachym.cepicky@centrum.cz>, grass developers list
<grass5@grass.itc.it>, Multiple recipients of list <GRASSLIST@baylor.edu>
Subject: Re: [GRASS5] New GRASS intro

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

Everyone wants the command line interface to be maintained. However, there
are features that can be implemented in an integrated GUI in ways that are
not possible with a CLI.

I am always torn on this issue. On the one hand, if GRASS had a
friendly user interface, maybe it wouldn't be in the GIS ghetto it is
now (in USA anyway). On the other hand, the reason I use GRASS is
because it integrates with my Unix toolbox (sed, grep, cut, etc).

If there comes a day when a Bash script isn't a first-class interface
to GRASS. Well, that's the day I stop using GRASS.

David

8

On Tue, Apr 25, 2006 at 02:29:00PM -0700, David Finlayson wrote:

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

> Everyone wants the command line interface to be maintained. However, there
> are features that can be implemented in an integrated GUI in ways that are
> not possible with a CLI.

I am always torn on this issue. On the one hand, if GRASS had a
friendly user interface, maybe it wouldn't be in the GIS ghetto it is
now (in USA anyway). On the other hand, the reason I use GRASS is
because it integrates with my Unix toolbox (sed, grep, cut, etc).

If there comes a day when a Bash script isn't a first-class interface
to GRASS. Well, that's the day I stop using GRASS.

Me, too :slight_smile:

But there is not interest in dropping the command line interface.
In fact, it will remain and be maintained (at least by me and many
other developers).

There will be *also* high developed GUI(s).

So, no worries,

Markus

--
Markus Neteler <neteler itc it> http://mpa.itc.it
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

9

I¹d hoped to make something really spiffy, easy for first time users to
navigate without getting confused about GRASS jargon, but still quick for
experienced users. Alas, I haven¹t had the time to do all this before the
impending 6.2 feature freeze, but I did manage to update things somewhat
from the venerable, Spartan grey intro.

Any chance to work on this wish? (double click on mapset name implies <ok>)
  https://intevation.de/rt/webrt?serial_num=3295

I¹ve rearranged the items on the intro screen to distinguish different
functions, changed the descriptions to make it clearer that locations are
for projections and mapsets are where a ŒGIS¹ is stored, etc. I also added a
new button to create a projection location from a georeferenced file (uses
GDAL/OGR via g.proj). Finally, I added some color to the intro. No I didn¹t
make it green, but I did add a nice GRASS graphic.

Could you post a quick screenshot?

I think the next step would be to replace the g.setproj terminal screen for
defining projections with a nicer GUI one based on g.proj. Another thing
would be to add a search function to the excellent EPSG codes database.

Yes, yes.

thanks,
Hamish

10

I could probably make them update automatically every time anything is
changed in the layer tree. I thought about doing so and discussed this
a bit with some of the folks contributing to the GUI discussions. The
general feeling was that it would be better to let the user decide
when to update the monitor. This allows you to change multiple aspects
of a set of overlaying maps and not have to wait through a screen
redraw for each change...

Maybe as soon as it is potentially out of date make a big red blinking
ring around the redraw button, or simply change the redraw icon to one
with a red ring around it. ?

the way it is in some commercial packages.

While it is nice to have company, let's do this right for ourselves, not
do contortions to match someone else's way (unless it is clearly
superior).

Hamish

11

Michael,

My opinion is that the manual redraw is best from the user perspective
for reasons you gave.

Tom

Michael Barton wrote:

I could probably make them update automatically every time anything is
changed in the layer tree. I thought about doing so and discussed this a bit
with some of the folks contributing to the GUI discussions. The general
feeling was that it would be better to let the user decide when to update
the monitor. This allows you to change multiple aspects of a set of
overlaying maps and not have to wait through a screen redraw for each
change...the way it is in some commercial packages.

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: Jachym Cepicky <jachym.cepicky@centrum.cz>
Date: Tue, 25 Apr 2006 22:29:27 +0200
To: Michael Barton <michael.barton@asu.edu>
Cc: grass developers list <grass5@grass.itc.it>, Multiple recipients of list
<GRASSLIST@baylor.edu>
Subject: Re: [GRASS5] New GRASS intro

Hallo developers,

personaly I do not use the new gui, because I can not use d.* commands
(d.rast and d.vect). I thing, that the new monitors do have the right
functions (zooming, panning, redrawing, ...), but it is often faster to
write, what map one would like to see, then to click it in the gui.

Would it be possible to make run this monitors in background as daemons, so
they
would "observe" the png files (png1-png7) and redraw them selve every
time, the files would be changed?

Jachym

On Tue, Apr 25, 2006 at 12:49:19PM -0700, Michael Barton wrote:
    

With the move toward releasing GRASS 6.2, it?s time we had a new intro to
greet users starting GRASS.

I?d hoped to make something really spiffy, easy for first time users to
navigate without getting confused about GRASS jargon, but still quick for
experienced users. Alas, I haven?t had the time to do all this before the
impending 6.2 feature freeze, but I did manage to update things somewhat
from the venerable, Spartan grey intro.

I?ve rearranged the items on the intro screen to distinguish different
functions, changed the descriptions to make it clearer that locations are
for projections and mapsets are where a ?GIS? is stored, etc. I also added a
new button to create a projection location from a georeferenced file (uses
GDAL/OGR via g.proj). Finally, I added some color to the intro. No I didn?t
make it green, but I did add a nice GRASS graphic.

Many thanks to Markus who helped me get this committed to the cvs, where it
now resides for your geospatial enjoyment.

I think the next step would be to replace the g.setproj terminal screen for
defining projections with a nicer GUI one based on g.proj. Another thing
would be to add a search function to the excellent EPSG codes database.

Cheers,
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

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507
    
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
  
--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

12

David,

I agree completely with the need to maintain the Bash interface scripting capability as it currently exists. This is critical for many things that I do in GRASS and is one of the most powerful features. This should never be an either/or proposition.

Tom

David Finlayson wrote:

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

Everyone wants the command line interface to be maintained. However, there
are features that can be implemented in an integrated GUI in ways that are
not possible with a CLI.
    
I am always torn on this issue. On the one hand, if GRASS had a
friendly user interface, maybe it wouldn't be in the GIS ghetto it is
now (in USA anyway). On the other hand, the reason I use GRASS is
because it integrates with my Unix toolbox (sed, grep, cut, etc).

If there comes a day when a Bash script isn't a first-class interface
to GRASS. Well, that's the day I stop using GRASS.

David

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
  
--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

13

David Finlayson wrote:

> Everyone wants the command line interface to be maintained. However, there
> are features that can be implemented in an integrated GUI in ways that are
> not possible with a CLI.

I am always torn on this issue. On the one hand, if GRASS had a
friendly user interface, maybe it wouldn't be in the GIS ghetto it is
now (in USA anyway). On the other hand, the reason I use GRASS is
because it integrates with my Unix toolbox (sed, grep, cut, etc).

If there comes a day when a Bash script isn't a first-class interface
to GRASS. Well, that's the day I stop using GRASS.

If anything, the changes required for the GUI work will make scripting
easier.

Essentially, the GUI works by executing GRASS commands. In order to
work effectively, the GRASS commands need to be able to operate
without any user interaction. No yes/no prompts, or waiting for the
user to do something with the mouse, or expecting data to be entered
via the terminal.

Any changes which make a program more useful to the GUI should equally
make it more useful for scripting.

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

14

Agreed. That was my (overly subtle apparently) point.

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: Wed, 26 Apr 2006 22:04:34 +1200
To: Michael Barton <michael.barton@asu.edu>
Cc: <jachym.cepicky@centrum.cz>, <grass5@grass.itc.it>, <GRASSLIST@baylor.edu>
Subject: Re: [GRASS5] New GRASS intro

the way it is in some commercial packages.

While it is nice to have company, let's do this right for ourselves, not
do contortions to match someone else's way (unless it is clearly
superior).

15

Hallo,

new intro looks good, but it does not fit into my 800x600 screen - would
it be problem to resize it a bit?

Thanks

Jachym

On Tue, Apr 25, 2006 at 12:49:19PM -0700, Michael Barton wrote:

With the move toward releasing GRASS 6.2, it?s time we had a new intro to
greet users starting GRASS.

I?d hoped to make something really spiffy, easy for first time users to
navigate without getting confused about GRASS jargon, but still quick for
experienced users. Alas, I haven?t had the time to do all this before the
impending 6.2 feature freeze, but I did manage to update things somewhat
from the venerable, Spartan grey intro.

I?ve rearranged the items on the intro screen to distinguish different
functions, changed the descriptions to make it clearer that locations are
for projections and mapsets are where a ŒGIS? is stored, etc. I also added a
new button to create a projection location from a georeferenced file (uses
GDAL/OGR via g.proj). Finally, I added some color to the intro. No I didn?t
make it green, but I did add a nice GRASS graphic.

Many thanks to Markus who helped me get this committed to the cvs, where it
now resides for your geospatial enjoyment.

I think the next step would be to replace the g.setproj terminal screen for
defining projections with a nicer GUI one based on g.proj. Another thing
would be to add a search function to the excellent EPSG codes database.

Cheers,
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

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

16

On Wed, 26 Apr 2006 06:58:56 -0700
Michael Barton <michael.barton@asu.edu> wrote:

Agreed. That was my (overly subtle apparently) point.

Since this is agreed, I'd like to rise the case of zooming out tool in
gis.m - could zooming out with a box be abandoned, in favor of zooming
out at each single mouse click?

Who else agrees/disagrees a single click for zoom out is better than
setting the zoom out box?

Maciek

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

17

+1 single click, for me

On Apr 26, 2006, at 12:44 PM, Maciek Sieczka wrote:

On Wed, 26 Apr 2006 06:58:56 -0700
Michael Barton <michael.barton@asu.edu> wrote:

Agreed. That was my (overly subtle apparently) point.

Since this is agreed, I'd like to rise the case of zooming out tool in
gis.m - could zooming out with a box be abandoned, in favor of zooming
out at each single mouse click?

Who else agrees/disagrees a single click for zoom out is better than
setting the zoom out box?

Maciek

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

Earth: "Mostly harmless"

- revised entry in the HitchHiker's Guide to the Galaxy

18

> Agreed. That was my (overly subtle apparently) point.

Since this is agreed, I'd like to rise the case of zooming out tool in
gis.m - could zooming out with a box be abandoned, in favor of zooming
out at each single mouse click?

Who else agrees/disagrees a single click for zoom out is better than
setting the zoom out box?

But this already works !!?

maybe the amount it zooms out on each click could be increased.

Hamish

19

new intro looks good, but it does not fit into my 800x600 screen -
would it be problem to resize it a bit?

For me it is
  Width: 570
  Height: 618

In Tcl can you auto-size a graphic like you can in HTML?

Hamish

20

Hallo,
ee - sorry, I do not understand (?) How can I auto-size graphic?

Thanks

Jachym

On Thu, Apr 27, 2006 at 11:21:19AM +1200, Hamish wrote:

> new intro looks good, but it does not fit into my 800x600 screen -
> would it be problem to resize it a bit?

For me it is
  Width: 570
  Height: 618

In Tcl can you auto-size a graphic like you can in HTML?

Hamish

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507