Russell Nelson said:
Mark P. Line writes:
> has more than one input map? Wouldn't this ultimately lead to a great
deal
> of entropy in the user's database with potentially many different
unnamed
> regions being propagated onto output files, as it were?
I would like people to be able to load data, and have GRASS discern
the correct region for that data.
Yes. And since you were offering to code such an enhancement, you would be
the one who determined how GRASS discerns the correct region for any
possible data. 
Hence my question. How are you proposing that a single "correct region"
for an input map, or set of input maps, should be determined?
I expect that sophisticated users will continue to find value in setting
a default region other than the one that GRASS has discerned. Naive
users will be rewarded with success, sophisticated users will not be
impeded. Everybody happy!
My belief is that naked GRASS is not and never has been a tool for naive
users. If there is demand for a point-and-click desktop GIS with GRASS as
the backend, and the current GUI branches are considered dead-ends, then I
bet there'd be enough people around to design and build it.
> Setting a region at start-up has the advantage of helping to keep all
> useful regions organized and named.
It has the disadvantage of presenting the naive user with a question
which is 1) crucial to get right, and 2) impossible to answer.
In what way is <g.region -d> not always a possible answer? What am I
missing? (This is not a rhetorical question: I was out of the GRASS
business for quite a while, and what worked then might not work now. We
all have our learning curves.)
The goal is to flatten out the GRASS learning curve, so that GRASS
proponents don't have to apologize for GRASS's usability problems. At
the 2003 OSCON in San Diego, there was an "Open Source GIS" session
featuring all the cool things that you can do with GRASS. Just about
the first thing out of the presenter's mouth was "Yeah, GRASS is hard
to use, but ...." We've got to stop that by making the GRASS learning
curve less steep.
Absolutely. What GRASS has always needed is an integrated, well-designed
and portable GUI front-end from whole cloth (read: without necessarily
duplicating the legacy user interface architecture and metaphors of
command-line GRASS) that allows command-line GRASS to disappear completely
from the user's view into its proper role as a back-end. I'm seeing some
approaches to that in the works as we speak (although I haven't looked at
them closely enough to have an opinion about them), and I think that's
where usability concerns should be addressed.
Trying to improve the enduser friendliness of naked GRASS -- especially
with a view towards letting naive users loose on the naked system -- would
be a bottomless time sink, in my view. I would no more pursue that than I
would pursue enduser friendliness improvements to autoconf.
-- Mark
Mark P. Line
Polymathix
San Antonio, TX