[GRASS-dev] WxPython front-end to ps.map

[Hamish]

> Hamish wrote:
> > So yes, please work on it if you like to. The only thing I ask is
> > that there is continuity with the rest of GRASS when possible. (e.g.
> > both d.vect and ps.map use the "rgb_column" name, and work in a
> > similar [and thus expected] way, etc)  You can probably copy a good
> > bit of the code from d.vect.

Martin Landa wrote:
> Looking at the code, there is used sizecol mapping instruction. So I
> am not sure about rgb_column. Maybe it is better to use rgbcol, but I
> would prefer rgb_column. Or to change sizecol to size_column? Not sure
> about that. One example in d.vect -- there is attrcol, wcolumn and
> rgb_column -- so three different approaches.

:)

which is the source of my request above, to try and stop this 4-names-
for-the-same-thing happening in future. I can only imagine how cryptic
it all is for a non-english speaker to decode.

Martin:
> thinking about it I suggest to use rgbcolumn. I suppose that renaming
> sizecol to sizecolumn is not good idea. It should wait for GRASS7.

that's fine, my main point is that when adding new options we take
measures to work towards greater consistency throughout the entire
software package. It makes it much easier to learn that way.

Preferably the development section of the wiki could have a page which
specified style rules, like exist for source code in the SUBMITTING
files.

FWIW, ps.map's sizecol could be renamed sizecolumn in GRASS 6, but you
would have to use strncmp(,7) instead of strcmp() to check the match.
The same is true for g.*,r.*,.. module options, they can be lengthened
without harm as the parser only checks enough letters to make sure there
is no name collision. It's not something you want to do without a very
good reason, but it doesn't break backwards compatibility either and so
isn't flatly outlawed.



Hamish