[GRASS-dev] Re: [GRASS GIS] #254: wxpython Layer Manager: higher raster hides the lower (GRASS GIS)

[Glynn Clements]

Martin Landa wrote:

> >> The -o flag is additionally problematic in that it is very similar to
> >> the --o flag which means "overwrite" in other contexts. We will need
> >> to keep the -o flag for the GRASS 6 series, but I would recommend
> >> changing it to something else for GRASS 7.
> >
> > Change in r32771. d.rast now makes nulls transparent by default; use
> > -n to make them opaque. The -o flag no longer exists.
> >
> > The GUIs will need to be updated accordingly.
> 
> done in r32774.
> 
> BTW, when I start g.gui without arguments the dialog is launched
> instead of the GUI. This behaviour is not right I guess, the 'gui'
> parameter has already defined default value. Now you are forced to run
> `g.gui gui=wxpython`.

That's becasue the gui= option is marked as required:

    type = G_define_option();
    type->key = "gui";
	...
    type->required = YES;

even though it always has a default value:

    gui_type_env = G__getenv("GRASS_GUI");
    if (gui_type_env && strcmp(gui_type_env, "text")) {
	type->answer = G_store(gui_type_env);
    }
    else {
	type->answer = "tcltk";
    }

If you remove the ->required setting, the dialog shouldn't appear.

In r32756, I removed all of the "argc > 1" hacks, and always call
G_parser(). It only generates the dialog if no arguments are given and
there is at least one required option.

Previously, it would always generate the dialog if no arguments were
given. Modules which have no required arguments would evade this
"feature" by not calling G_parser() if no arguments were given.

But this has some undesirable side effects, e.g. module->overwrite
won't reflect the setting of $GRASS_OVERWRITE. So now, everything
always calls G_parser().

BTW, g.gui shouldn't be using G__getenv() to initialise type->answer. 
It should leave it uninitialised, then check the GRASS_GUI setting if
it's still null when G_parser() returns.

Initialising the default to a variable means that e.g. the g.gui
manual page will show a default value which depends upon the GRASS_GUI
setting at the point that the documentation was generated.

This hack is so common that I'm considering modifying a few key
functions (e.g. those which read the $GISRC and WIND files) to
generate a fatal error if G_parser() hasn't been called yet.

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