Maybe minor issues but these changes are already being applied and I
wouldn't like to see folks have to repeat work if the group decides on
another way...
It seems to me the wiki is a bad place to try for a consensus due to the
"last edit wins" nature of it and lack of eyes. So to the mailing list...
Ellipses
* Suspension points used to indicate some process is being done
should be placed next to last word, without space. e.g. "Reading map..."
instead of "Reading map ..."
--HB: FWIW & my 2c, 1) to me keeping the space before the ellipse
looks better; is this a purely cosmetic choice or is there some style
logic? 2) these messages may be good candidates for G_verbose_message().
"Map <roads> in <user1>" or "Map <roads@user1>"
* "Map <roads@user1>" preferred - ML
* If the element was given on the command line, then the user knows
which mapset it came from, and the @mapset part is just extra noise,
perhaps use the ->answer string from the parser instead of the
processed ("%s@%s", name, mapset)? If the element is taken from the data
(how? i.group?) where the user hasn't explicitly defined the map, then @mapset it appropriate. Also output maps are always created in the
current mapset* so @mapset is redundant and should not be used for new
maps. [* i.rectify, r.in.gdal, v.in.ogr are exceptions that can create
maps in other mapsets or new locations] --HB
Ellipses
* Suspension points used to indicate some process is being done
should be placed next to last word, without space. e.g. "Reading map..."
instead of "Reading map ..."
--HB: FWIW & my 2c, 1) to me keeping the space before the ellipse
looks better; is this a purely cosmetic choice or is there some style
logic? 2) these messages may be good candidates for G_verbose_message().
1) Yeah I agree space before the ellipsis looks maybe a bit better with
a space before it. However, not having the space before seems to be
recommended, as you can see for instance in Wikipedia [1]
"Map <roads> in <user1>" or "Map <roads@user1>"
* "Map <roads@user1>" preferred - ML
* If the element was given on the command line, then the user knows
which mapset it came from, and the @mapset part is just extra noise,
perhaps use the ->answer string from the parser instead of the
processed ("%s@%s", name, mapset)? If the element is taken from the data
(how? i.group?) where the user hasn't explicitly defined the map, then @mapset it appropriate. Also output maps are always created in the
current mapset* so @mapset is redundant and should not be used for new
maps. [* i.rectify, r.in.gdal, v.in.ogr are exceptions that can create
maps in other mapsets or new locations] --HB
FWIW I think that using @mapset should be limited to cases where mapset
is not the current mapset. And should *always* be used in that case
whether the input came from the user or not.
<aside> the GRASS 6.3 tcl GUI always appends the @mapset to the map name, even for the current mapset. Personally I don't like that- I think it's ugly noise. It does that to clarify to the user which map will be used from the g.mapsets search path if the map name exists in
multiple mapsets.
IIRC, the reason for putting the @mapset was not really to clarify
anything to the user, but rather to avoid the message:
WARNING: 'vector/fields' was found in more mapsets (also found in
PERMANENT).
WARNING: using 'fields@user1'.
On 17/12/07 04:03, Wolf Bergenheim wrote:
On 17.12.2007 01:35, Hamish wrote:
"Map <roads> in <user1>" or "Map <roads@user1>" * "Map <roads@user1>" preferred - ML * If the element was given on the command line, then the user knows which mapset it came from,
Why does he know when on the command line and not in the GUI ?
FWIW I think that using @mapset should be limited to cases where mapset is not the current mapset. And should *always* be used in that
case whether the input came from the user or not.
This would imply that:
On 16/12/07 03:18, Hamish wrote:
I would be happy to just document/recode so that the current mapset
is always searched first, PERMANENT second, and all others after
(alpha? filesystem order?). </aside>
It would be interesting to see how many people deliberately set their mapset search path to something different than the default. This would then give us a notion of how much nuisance such a change would create ?
> <aside> the GRASS 6.3 tcl GUI always appends the @mapset to the map
> name, even for the current mapset. Personally I don't like that- I
> think it's ugly noise. It does that to clarify to the user which map
> will be used from the g.mapsets search path if the map name exists in
> multiple mapsets.
IIRC, the reason for putting the @mapset was not really to clarify
anything to the user, but rather to avoid the message:
WARNING: 'vector/fields' was found in more mapsets (also found in
PERMANENT).
WARNING: using 'fields@user1'.
There's another reason: an unqualified map name does not necessarily
refer to the map with that name in the current mapset, but to the
first map with that name in the mapset search path. The current mapset
comes first in the search path *by default*, but that can be changed.
Unqualified map names are a convenience for command-line use. There is
no need to use them when the user is selecting a specific map from a
map browser.
> FWIW I think that using @mapset should be limited to cases where
> mapset is not the current mapset. And should *always* be used in that
> case whether the input came from the user or not.
This would imply that:
On 16/12/07 03:18, Hamish wrote:
> I would be happy to just document/recode so that the current mapset
> is always searched first, PERMANENT second, and all others after
> (alpha? filesystem order?). </aside>
So long as we have a mapset search path, it makes sense to allow the
user to set it to whatever they want.
It would be interesting to see how many people deliberately set their
mapset search path to something different than the default. This would
then give us a notion of how much nuisance such a change would create ?
It doesn't matter how common this is, only that it's possible.