new tabs in GUI have required last

[cmbarton]

Someone went through and added new tabs to several of the module interface sections. This is nice. However, in the couple I've run into (e.g. r.colors and v.in.ascii), the "required" tab is the bottom one on the stack and rightmost tab. That is the stuff that is most important is the most hidden. Also v.in.ascii required output vector name is in the options section, not the required section, and while the input raster name for r.colors is in the required section, its description says it is optional.

Michael

[hamish]

FWIW I don't really see the point in putting options in a Required tab using the guisection control. That info is already supplied by the opt->required parser switch.

I'm not completely sold on putting all parser required options in the front tab. I would be happy if those options were just bolded. (I can see the problem with something like d.vect where you would have to hunt for them in lots of tabs, annoying)

For r.colors, v.in.ascii the input can come from stdin which is why those input filenames are not required by the parser, although piping to stdin isn't really an option from a GUI window.

I am not sure about the wxPython GUI but for the TclTk one IIRC tabs are created in the order their options arrive, with flags having the first pass, and all sorts of other funny rules. I think it is bad policy to do a lot of option reordering to make the tabs look nice. IMO they should be grouped in logical order when viewed serially from the help page. Special care must be taken with the first option as users may expect it to be the optional "opt=" from the command line. see trac task #88.

2c, Hamish

[martinl]

Replying to cmbarton:

Someone went through and added new tabs to several of the module interface sections. This is nice. However, in the couple I've run into (e.g. r.colors and v.in.ascii), the "required" tab is the bottom one on the stack and rightmost tab. That is the stuff that is most important is the most

strange, I cannot reproduce this behaviour, 'Required' tab is the most-left on my machine. Looking at the code, 'Required' (formerly called 'Main') should be always first, see

​http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/gui_modules/menuform.py#L865

hidden. Also v.in.ascii required output vector name is in the options section, not the required

I see this option in 'Required tab', see the attached screenshot.

section, and while the input raster name for r.colors is in the required section, its description says it is optional.

The input parameter is option because

-l   List available rules then exit

then you don't need to set dummy value for 'r.colors -l' (otherwise 'r.colors in=dummy -l'). For GUI dialog this parameter is forced to be moved to 'Required' tab.

option->guisection = _("Required");

It seems to me less confusing for GUI user - "I want to change color table of raster map, then I am expecting input raster map name to be required". Maybe tab should called 'Main' not 'Required'.

Martin

[martinl]

GUI dialog for v.in.ascii (required tab)

[martinl]

Replying to hamish:

FWIW I don't really see the point in putting options in a Required tab using the guisection control. That info is already supplied by the opt->required parser switch.

Yes, that's true. But there are some exceptions like r.in/out.gdal, v.in/out.ogr where naturally required parameters (input, output) are not marked as required. Mainly because of 'list' flag. Otherwise you would have to type

r.in.gdal in=dummy -f

instead of

r.in.gdal -f

which is a bit ugly. For GUI dialog it could be for user a bit confusing, to launch r.in.gdal and to find input and output option in 'Optional' tab, even dialog for importing raster file into GRASS without 'Required' tab.

I'm not completely sold on putting all parser required options in the front tab. I would be happy if those options were just bolded. (I can see the problem with something like d.vect where you would have to hunt for them in lots of tabs, annoying)

For r.colors, v.in.ascii the input can come from stdin which is why those input filenames are not required by the parser, although piping to stdin isn't really an option from a GUI window.

Maybe we could rename 'Required' tab to 'Main' tab, bolded required option (option->required = YES) and move here few options like in the case of r.in.gdal.

I am not sure about the wxPython GUI but for the TclTk one IIRC tabs are created in the order their options arrive, with flags having the first pass, and all sorts of other funny rules. I

It should be same for wxPython, just 'Required' tab is always first and 'Optional' (i.e. parameter without guisection) the second.

think it is bad policy to do a lot of option reordering to make the tabs look nice. IMO they should be grouped in logical order when viewed serially from the help page. Special care must be taken with the first option as users may expect it to be the optional "opt=" from the command line. see trac task #88.

I agree (CLI and GUI should be consistent here).

Martin

[glynn]

Replying to hamish:

For r.colors, v.in.ascii the input can come from stdin which is why those input filenames are not required by the parser, although piping to stdin isn't really an option from a GUI window.

I suggest modifying the parser so that "-" is always accepted for "old,file" options.

Providing incorrect type information so that "-" works is a rather ugly hack.

[martinl]

From grass-dev ML:

2008/3/20, Michael Barton <michael.barton@…>:

There is no need for the CLI and GUI to be consistent with respect to

options ordering. For the CLI, option order is irrelevant; options can be typed in any order.

I don't think so, there is no reason to leave CLI and GUI syntax description inconsistent. The order of parameters should be logical. Yes, you can type them in order whatever you like, the point here is module usage description, e.g. v.in.ascii

input -> tab 'Required' output -> tab 'Required'

fs -> not defined (tab 'Optional') skip ->not defined (tab 'Optional')

columns -> tab 'Columns' x > tab 'Columns' y -> tab 'Columns' z -> tab 'Columns' cat -> tab 'Columns'

and some flags ...

For the GUI option order is very important because the user must access the options only in the order presented by the GUI. Thus we need to make sure the options order in the GUI section is the most logical and useable for the GUI. This section has no impact at all on the CLI.

yes, anyway I think the order of parameters given to G_parser() should be logical and be grouped by guisection identifier.

Martin

[hamish]

Replying to glynn:

Replying to hamish:

Hamish:

For r.colors, v.in.ascii the input can come from stdin which is why those input filenames are not required by the parser, although piping to stdin isn't really an option from a GUI window.

Glynn:

I suggest modifying the parser so that "-" is always accepted for "old,file" options.

Providing incorrect type information so that "-" works is a rather ugly hack.

What I was trying to get at was the modules work like "if input file is NULL, assume input comes from stdin". I don't think those modules actually have code to deal with input=-, they will treat that as a filename not something special. Some modules do recognize that trick, for consistency's sake I suppose all that can read from stdin should, and if the parser needs to be aware of that then so be it.

And AFAIK the parser does not actually check to see if an "old,file" option's answer actually exists. It leaves that to the module. All it provides is the folder file picker GUI. (Same is true for cell, vector, group, ... elements) (??)

So the type isn't being dropped to accomodate 'oldfile=-', ->required is being dropped to accomodate "if input file is NULL, assume input comes from stdin".

not sure if we're talking about the same thing here...

Hamish

[cmbarton]

I think I've fixed this. If a "Required" tab exists, it is not first and is raised. If it doesn't exist, the parser reverts to option begin first. This works on my Mac with OSX 10.5; please test on other confiurations.

Michael