Hi,
2014-12-28 5:35 GMT+01:00 <svn_grass@osgeo.org>:
I would suggest to rename
bgcolor
to
bg_color.
Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
Hi,
2014-12-28 14:08 GMT+01:00 Martin Landa <landa.martin@gmail.com>:
I would suggest to rename
bgcolor
to
bg_color.
it would be nice to solve it before RC1. Any objections?
Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
On Mon, Dec 29, 2014 at 11:47 AM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2014-12-28 14:08 GMT+01:00 Martin Landa <landa.martin@gmail.com>:
I would suggest to rename
bgcolor
to
bg_color.
it would be nice to solve it before RC1. Any objections?
for me it is ok.
ciao
Markus
Martin Landa wrote:
> I would suggest to rename
>
> bgcolor
>
> to
>
> bg_color.it would be nice to solve it before RC1. Any objections?
Not an objection as such, but FWIW I'd still prefer a solution which
allows background_color=, as well as bg_color=.
--
Glynn Clements <glynn@gclements.plus.com>
2014-12-29 12:26 GMT+01:00 Glynn Clements <glynn@gclements.plus.com>:
it would be nice to solve it before RC1. Any objections?
Not an objection as such, but FWIW I'd still prefer a solution which
allows background_color=, as well as bg_color=.
what does it mean exactly? back_ground_color or ?
Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
On Mon, Dec 29, 2014 at 7:11 AM, Martin Landa <landa.martin@gmail.com>
wrote:
2014-12-29 12:26 GMT+01:00 Glynn Clements <glynn@gclements.plus.com>:
>> it would be nice to solve it before RC1. Any objections?
I think it's not necessary, it doesn't help with anything, everybody will
keep using bgcolor anyway. We already have similar cases (pcurvature,
nwalkers) which where already changed and we don't plan to add another
underscore there.
Anna
> Not an objection as such, but FWIW I'd still prefer a solution which
> allows background_color=, as well as bg_color=.what does it mean exactly? back_ground_color or ?
Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Mon, Dec 29, 2014 at 5:47 AM, Martin Landa <landa.martin@gmail.com>
wrote:
Hi,
2014-12-28 14:08 GMT+01:00 Martin Landa <landa.martin@gmail.com>:
> I would suggest to rename
>
> bgcolor
>
> to
>
> bg_color.it would be nice to solve it before RC1. Any objections?
Actually yes, although not strong one. I don't see any advantage in
bg_color. It's quite easy to find color there even if your English is rough.
Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
2014-12-29 13:26 GMT+01:00 Anna Petrášová <kratochanna@gmail.com>:
I think it's not necessary, it doesn't help with anything, everybody will
keep using bgcolor anyway. We already have similar cases (pcurvature,
nwalkers) which where already changed and we don't plan to add another
underscore there.
I meant color-related options. They are named 'color' or 'something_color'.
What about 'background_color' option? Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
On Mon, Dec 29, 2014 at 11:29 AM, Martin Landa <landa.martin@gmail.com>
wrote:
Hi,
2014-12-29 13:26 GMT+01:00 Anna Petrášová <kratochanna@gmail.com>:
> I think it's not necessary, it doesn't help with anything, everybody will
> keep using bgcolor anyway. We already have similar cases (pcurvature,
> nwalkers) which where already changed and we don't plan to add another
> underscore there.I meant color-related options. They are named 'color' or 'something_color'.
what's special about color options?
What about 'background_color' option? Martin
I stated my opinion on this earlier: I am against changing options which
are easy to understand and people are used to them just because they
represent a shortcut, especially when we don't have any good candidate.
What would be the advantage of background_color? bg_color or
back_ground_color can be at least shorten to bgcolor.
However, since you did most of the work recently, I think you have the
right to decide it.
Anna
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
Martin Landa wrote:
>> it would be nice to solve it before RC1. Any objections?
>
> Not an objection as such, but FWIW I'd still prefer a solution which
> allows background_color=, as well as bg_color=.what does it mean exactly? back_ground_color or ?
That would work but it's undesirable, as "background" itself is a
single word.
I'm just considering whether there is a viable solution which allows
either form without artificially breaking up compound words.
One alternative is to extend the option matcher to support an
alternative marker character (e.g. "back'ground_color"). An
alternative marker could be omitted in some contexts yet shown in
others. E.g. the "Usage" section in the --help output might omit it
but the longer "Parameters" section could show it (or the description
could include a note, e.g. "background may be abbreviated as bg").
Another alternative is capitalisation (e.g. "backGround_color").
Captalisation could be retained in most contexts, as it is less
intrusive than an underscore (it used to be common to indicate
"accelerator" characters on terminal-based interfaces).
Another alternative would be to allow parenthesised abbreviations,
e.g. background(bg)_color. The abbreviated form could be shown by
--help while the full form could be used in scripts.
In each case, the GUI could follow different rules to the command line
as to how such option names are presented.
A simpler alternative (in terms of implementation) is to just add both
options, with the description for one stating that it is an alias for
the other.
None of this is critical. If people are particularly keen to duck the
issue, I'll just forget about it.
--
Glynn Clements <glynn@gclements.plus.com>