#1778: Typing in g.region without parameters does not open a g.region window ----------------------------------------+----------------------------------- Reporter: pvanbosgeo | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Default | Version: svn-trunk Keywords: g.region, r.colors, r.mask | Platform: Linux Cpu: x86-64 | ----------------------------------------+-----------------------------------
Comment(by 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. -- Ticket URL: <https://trac.osgeo.org/grass/ticket/1778#comment:20> GRASS GIS <http://grass.osgeo.org> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev