Typing in g.region without parameters does not open a g.region window

[pvanbosgeo]

Normally when you type a command, e.g., g.region, without parameters, a new window for that command opens.

This does not seem to work for a few commands at the moment. Three ones that seem to be affected are g.region, g.rename and g.copy.

Typing in these commands in the command console of the GRASS GIS layer manager do open the windows

My system info:

GRASS version: 7.0.svn GRASS SVN Revision: 53621 GIS Library Revision: 52468 (2012-07-27) GDAL/OGR: 1.9.2 PROJ4: Rel. 4.7.1, 23 September 2009 Python: 2.7.3 wxPython: 2.8.12.1 Platform: Linux-3.5.0-17-generic-x86_64-with-Ubuntu-12.10-quantal

[pvanbosgeo]

Another example is r.colors, see:

GRASS 7.0.svn (CRU):~ > r.colors ERROR: Options <map> or <file> must be specified [Raster MASK present] GRASS 7.0.svn (CRU):~ >

[pvanbosgeo]

Sorry, that wasn't clear, let me try again:

GRASS 7.0.svn (CRU):~ > r.colors
ERROR: Options <map> or <file> must be specified
[Raster MASK present]
GRASS 7.0.svn (CRU):~ >

[pvanbosgeo]

Another example is r.mask (rev 54310)

[hamish]

Hi,

I can reproduce in trunk.

as a workaround,

g.module --ui

gets you the module GUI.

Hamish

[mlennert]

All the examples given in this ticket are modules that have no required parameters. As soon as at least one of the parameters is marked as required, calling the module without parameters opens the GUI.

ISTR that there is an option to mark several parameters as "at least one of these is required", but I can't find how to do this in the programmer's manual.

[glynn]

Replying to pvanbosgeo:

Normally when you type a command, e.g., g.region, without parameters, a new window for that command opens.

This does not seem to work for a few commands at the moment. Three ones that seem to be affected are g.region, g.rename and g.copy.

This is normal. If a command doesn't have any required options, executing the command without parameters will not open a parameter dialog. You can force a parameter dialog to be displayed using the --ui switch.

[glynn]

Replying to mlennert:

ISTR that there is an option to mark several parameters as "at least one of these is required", but I can't find how to do this in the programmer's manual.

No such feature exists at present, although it has been discussed on occasion.

The only thing that has changed between 6.x and 7.0 in this regard is that in 7.0, flags have a ->suppress_required field. If set, the parser won't complain about "required" options not being provided if the flag is used. This is useful for flags which perform a "show current status" function for modules which normally have required options.

[martinl]

Replying to glynn:

Replying to pvanbosgeo:

Normally when you type a command, e.g., g.region, without parameters, a new window for that command opens.

This does not seem to work for a few commands at the moment. Three ones that seem to be affected are g.region, g.rename and g.copy.

This is normal. If a command doesn't have any required options, executing the command without parameters will not open a parameter dialog. You can force a parameter dialog to be displayed using the --ui switch.

I would call it rather "current behaviour". It's probably confusing to the user. Is there any reason why the dialog is not open in this case?

[neteler]

Replying to martinl:

Replying to glynn:

This is normal. If a command doesn't have any required options, executing the command without parameters will not open a parameter dialog. You can force a parameter dialog to be displayed using the --ui switch.

I would call it rather "current behaviour". It's probably confusing to the user. Is there any reason why the dialog is not open in this case?

For example, from d.erase (on CMD line) you expect that the screen be erased, not that you have to do extra GUI clicking. Or do you refer to g.region?

[martinl]

Replying to neteler:

Replying to martinl:

Replying to glynn:

This is normal. If a command doesn't have any required options, executing the command without parameters will not open a parameter dialog. You can force a parameter dialog to be displayed using the --ui switch.

I would call it rather "current behaviour". It's probably confusing to the user. Is there any reason why the dialog is not open in this case?

For example, from d.erase (on CMD line) you expect that the screen be erased, not that you have to do extra GUI clicking. Or do you refer to g.region?

yes, I am referring to g.region. There are probably more modules without required parameters which have no expected effect as eg. d.erase.

[glynn]

Replying to martinl:

I would call it rather "current behaviour". It's probably confusing to the user. Is there any reason why the dialog is not open in this case?

If it's valid (so far as the parser can determine) to run a module without providing any options, then it will just get on with it, and not stop to ask for additional options.

The real problem here is that there's no way to tell the parser that "some" options are required when no particular option is required.

[cmbarton]

Remind me again why the parser was changed so that a module does not open a GUI window when it is called from the command line and there are no required parameters.

Michael

[glynn]

Replying to cmbarton:

Remind me again why the parser was changed so that a module does not open a GUI window when it is called from the command line and there are no required parameters.

Because it's a nuisance having e.g. "d.erase" pop up a parameter dialog (or getting an error message about $DISPLAY not being set). It's also a nuisance having to type "d.erase bgcolor=none" when that's the default.

The --ui flag exists if you specifically want a parameter dialog to be displayed.

[annakrat]

So we need options to have another field (something like 'group_required') which tells the parser that the certain options belong to a group of options where one of them has to be specified by the user. Would it be complicated to implement?

[cmbarton]

Or something...

The problem you describe is indeed annoying. But it does not seem like a good idea to have modules behave inconsistently and unpredictably from the user perspective in order to solve it. The --ui flag should be default behavior and not need the flag. Consistent behavior was one of the goals of getting rid of persistent processes in modules.

The actual problem, and to my mind implementing a solution, seems to lie in the modules that should run without a dialog rather than altering the default behavior of launching a dialog when a module is run without parameters. A logically better fix is to require the --ui flag only on modules whose normal behavior is to run without arguments. g.region is not such a module; d.erase is such a module. Perhaps there are even more elegant fixes.

Michael

[glynn]

Replying to cmbarton:

The problem you describe is indeed annoying. But it does not seem like a good idea to have modules behave inconsistently and unpredictably from the user perspective in order to solve it.

The modules don't behave inconsistently. If you specify all of the required parameters, the module just does what it's told without further prompting.

[glynn]

Replying to annakrat:

So we need options to have another field (something like 'group_required') which tells the parser that the certain options belong to a group of options where one of them has to be specified by the user. Would it be complicated to implement?

The main complication is that someone will need to modify a very large number of modules to have them declare their requirements. If we're going to all that trouble, it would be better to finish the job.

As well as the case where at least one of a group of options must be supplied, it's also common for certain options to be mutually exclusive, or for certain options to require other options. In all cases, there may be multiple such relationships.

If the information on the relationships between options was supplied to the parser, not only could the parser perform such checks automatically, but it would be able to supply the information to the GUI. So the GUI could display this information to the user, e.g. by adding radio buttons to options which belong to an "exactly one of" group, and/or greying out options which have been excluded by the use of other options.

To have the parser perform checking, it would be enough to specify the requirements as a boolean expression which must evaluate to true. But that's hard for the GUI to translate into visual cues, and it's also hard to produce useful error messages if the requirements aren't met.

So we really need a more restrictive form, but still something which is flexible enough to handle the majority of the inter-dependencies between options. As to exactly what that form should be, we really need some input from the GUI developers.

[hamish]

Replying to glynn:

So the GUI could display this information to the user, e.g. by adding radio buttons to options which belong to an "exactly one of" group, and/or greying out options which have been excluded by the use of other options.

Hi,

fwiw, where modules have grown to contain many such flags often the basic answer is to replace the flags with a single option=string with a drop down menu containing the mutually exclusive possibilities. Radio buttons shouldn't be needed when we have opt->options = ""; and opt->descriptions = "";.

that doesn't cover "multi-mode" modules, but for my 2c I'd consider those by definition to be arbitrarily complicated special cases and leave the error checking to the programmer not the parser.

regards, Hamish

[mlennert]

I think these discussions are important to improve usability, but I don't think this bug warrants a "critical" priority. In fact, it is probably not even a bug, but an enhancement request, as the modules in question do work as expected. Downgrading to normal.

Moritz

[cmbarton]

It is not critical but I'm not sure I'd call it an enhancement. Not really a bug either, though it will appear to be one to many users. The important conceptual issue is, should the default behavior of GRASS modules when called without arguments be

1. to launch a GUI dialog?
2. to do something?

If we agree on the behavior conceptually, then we can work out ways to achieve it. Personally, I think it should be #1. Some others think it should be #2 (launching a GUI only if there is a particular required argument that has not been set). Currently, GRASS 7 is set for #2.

My vote for #1 comes from thinking about usability for people who are novice or infrequent users of the command line and the fact that GRASS 7 appears to behave like #1 for most modules. This leads to what appears to be inconsistent behavior of modules launched from the command line (even though it is in fact consistent from the #2 approach). There is no way for a user to know in advance whether a module called without arguments will

a) launch a GUI (has a particular required argument that is not set), b) do something (runs a process with some default setting with no required argument), or c) do nothing (requires SOME argument, no particular argument to run).

A flag (-ui) can be added to any module to ensure it launches a GUI, but is only necessary for a few modules. AFAICT, this behavior is not documented anywhere (run g.region help or look in the manual for GRASS). I tend to think that 'secret' behavior of any interface element is not a good idea from the user perspective--even if the secret is inadvertent and logical from other perspectives.

I think the argument for #2 is primarily one of easier, more rapid use of modules from the command line by experienced and frequent users. There may be other arguments that have not been articulated yet.

[martinl]

Replying to cmbarton:

A flag (-ui) can be added to any module to ensure it launches a GUI, but is only necessary for a few modules. AFAICT, this behavior is not documented anywhere (run g.region help or look in the manual for GRASS). I tend to think that 'secret' behavior of any interface element is not a good idea from the user perspective--even if the secret is inadvertent and logical from other perspectives.

the attached patch attachment:force_gui.diff​ adds '--ui' to the help printed by the parser (see example below). I agree that this switch is not documented well, even it's not noted in the g.parser's help page.

Description:
 Displays user-specified raster map in the active graphics frame.

Keywords:
 display, graphics, raster

Usage:
 d.rast [-ni] map=name [values=value[-value][,value[-value],...]]
   [bgcolor=color] [--verbose] [--quiet] [--ui]

Flags:
  -n   Make null cells opaque
  -i   Invert value list
 --v   Verbose module output
 --q   Quiet module output
 --ui  Force GUI dialog to come up

Parameters:
      map   Name of raster map to be displayed
   values   List of categories or values to be displayed
  bgcolor   Background color (for null)
             Either a standard color name or R:G:B triplet
            default: white

[martinl]

add '--ui' to the help text

[glynn]

Replying to cmbarton:

It is not critical but I'm not sure I'd call it an enhancement. Not really a bug either, though it will appear to be one to many users. The important conceptual issue is, should the default behavior of GRASS modules when called without arguments be

1. to launch a GUI dialog?
2. to do something?

Arguments or not, the default behaviour behaviour should be to do something. We're discussing the behaviour in the event of an error, i.e. if the supplied arguments are insufficient for the module to actually do something.

In that situation, my preference would be an error message, preferably a more useful one than

Unable to access the X Display, is $DISPLAY set properly?

If I wanted GUI dialogs, I'd use the GUI.

My vote for #1 comes from thinking about usability for people who are novice or infrequent users of the command line

Optimising the command-line interface for people who don't use it at the expense of those who do doesn't seem particularly sensible. Also, optimising for novice users results in something which is useful for the first few weeks then a nuisance for the next decade, which again seems like a poor trade-off.

I think the argument for #2 is primarily one of easier, more rapid use of modules from the command line by experienced and frequent users. There may be other arguments that have not been articulated yet.

There's also the fact that it can result in command-line modules blocking forever in the case that the connection to the X server succeeds but there's no user to interact with it. I.e. the same problem as with the previous terminal-based prompting, except that closing stdin won't save you (unsetting DISPLAY will, at least on Unix, provided that you've already anticipated that failure mode).

To that end, I'd rather GUI dialogs were never displayed, so that e.g. a shell script which does "r.module $args" (when $args is empty for whatever reason) sees an error rather than a module which just runs forever. That would also be consistent with almost every other command-line utility from every package which isn't GRASS.

The problem is that it's rather hard for a module to determine whether interactivity is a plus or a minus. An environment variable wouldn't necessarily help; if it's set for an interactive shell, any scripts run from the shell would inherit it. They'll also inherit the fact that stdin is a tty and $DISPLAY is set.

[wenzeslaus]

Removing the start GUI if no parameters behavior to ensure right behavior of scripts is not bad idea. However, don't think that there is a will to do it. I'm using this functionality a lot and as far as I know others too. And I never had a problem with empty $args (but I don't think I will not).

So if we want start GUI if no parameters behavior, I think that the solution could be to provide a function in gpraser library to show the GUI. Module itself can check its parameters and when no parameters are set, instead of ​NOP (e.g., g.region) or error (e.g., r3.colors), it can call the function to show GUI. (By the way, g.region should do something, e.g. print error message, because NOP is not expected behavior even when writing script.)

Note that this is can be a wide problem since a lot of (temporal-related) modules now accept multiple input (map names) parameter or file containing map names. (Correct me if I'm wrong.)

Also note, that there is an unresolved problem of starting generated GUI vs hand-written GUI for a module (​Additional switch(es) for <g.mapsets>?, ​nabble). There was even a diff (not sure if public) implementing the enforcing of generated GUI by --ui. But this is not ideal since it conflicts with standard use of --ui (it would mean that modules with no required parameters would not be eligible to have hand-written GUI).

[glynn]

Replying to wenzeslaus:

So if we want start GUI if no parameters behavior, I think that the solution could be to provide a function in gparser library to show the GUI. Module itself can check its parameters and when no parameters are set, instead of ​NOP (e.g., g.region) or error (e.g., r3.colors), it can call the function to show GUI.

No, the module shouldn't be calling a function to show a GUI. A correct solution for this case is to add a flag to the GModule structure which the module would set to indicate that it cannot run without parameters, even though none of its options have the ->required flag. The parser would then use this flag in determining whether to show a parameter dialog.

This is similar to the existing mechanism (in 7.0) whereby a module can set the ->overwrite flag in the the GModule structure to indicate that the --overwrite switch should be included in the --help, --interface-description, etc output even though the module has no options with "new" in the ->gisprompt field.

[martinl]

Replying to martinl:

the attached patch attachment:force_gui.diff​ adds '--ui' to the help printed by the parser (see example below). I agree that this switch is not documented well, even it's not noted in the g.parser's help page.

any objection to committing this patch?

[glynn]

Replying to martinl:

any objection to committing this patch?

Not really, although I note that we don't list --help, --script or any of the --*-description options either.

I suppose that --script and --*-description aren't of interest to end users, and if you're reading the help text, you probably don't need to be told about --help (although it would be nice if we could train users to use that so that we can remove the argv[1]=="help" check; although "help" isn't likely to be particularly common as an option value, I dislike having special cases on principle).

[hamish]

No, I don't think --ui should be added to the help page. It should only needed in special circumstances (like debugging or having the main GUI progmatically force open a dialog), much like --script and --interface-description aren't interesting in the main help pages even though possible.

I'm still highly confused about the need for any change since everything seemed to be working very smoothly in GRASS 6. For example d.erase if called alone would do its job without a GUI, you could add "color=black" or whatever extra option on the command line if needed, or use --ui to get a GUI module in the rare cases that you wanted one or add '--ui' to the menus.xml file to force one if called from there.

Other modules in G6 that are special cases where no command line arguments are needed (although possible) test argc or $# to decide how to act. Since it's only a few of them special parser handling/support isn't needed, the module programmer can make that decision on a one-off basis.

?, Hamish

[glynn]

Replying to hamish:

I'm still highly confused about the need for any change since everything seemed to be working very smoothly in GRASS 6. For example d.erase if called alone would do its job without a GUI,

That's because it does this:

    if (argc > 1 && G_parser(argc, argv))
	exit(1);

If you run it without arguments, G_parser() never gets called (this was to prevent it using the terminal-based interactive prompting which preceded the parameter dialogs).

But in 7.0, it's required that all modules call G_parser(), always, no exceptions. This is required e.g. for setting the verbose/quiet/overwrite status from environment variables. It's possible that other initialisation tasks may be moved from G_gisinit() to G_parser() in the future.

Consequently, G_parser() can't be skipped, and changing the dialog condition from "no options given" to "no options given, but at least one required" was the simplest way to preserve the "no unnecessary dialogs" behaviour. However, because it's now implemented in the parser rather than the module, the module can't override the decision in the event that the "no required options" logic is inadequate.

[annakrat]

Now we can finally solve this ticket thanks to new rules implemented by glynn and hcho. We just need to specify the group of options where at least one must be given. In case of g.region, it looks like all options and flags should be in this group?

[annakrat]

Replying to annakrat:

Now we can finally solve this ticket thanks to new rules implemented by glynn and hcho. We just need to specify the group of options where at least one must be given. In case of g.region, it looks like all options and flags should be in this group?

Done in r62506 and backported in 62507. Closing this ticket.