improve module wxGUI tab logic

[hamish]

I propose guisection->_("main") (important|core|primary|...?) as the first module wxGUI tab, which

• Required=YES options are automatically assigned to,
• and other options can be assigned to it as needed...

the Required tab while usually doing the right thing, is too blunt an instrument for all cases.

thanks, Hamish

[hamish]

Replying to hamish:

I propose guisection->_("main") (important|core|primary|...?) as the first module wxGUI tab, which

• Required=YES options are automatically assigned to,
  
• and other options can be assigned to it as needed...
  

the Required tab, while usually doing the right thing, is too blunt an instrument for all cases.

also this allows to have input= or output= on the front tab even if it can be optional due to a flag that prints some info to the terminal and exits. Forcing users to specify output=dummy to overcome Req=YES + --list style flags isn't a very nice solution, when Req=YES is just there to force the important option on to the front tab for visibility.

any thoughts?

Hamish

[cmbarton]

Replying to hamish:

Replying to hamish:

I propose guisection->_("main") (important|core|primary|...?) as the first module wxGUI tab, which

• Required=YES options are automatically assigned to,
  
• and other options can be assigned to it as needed...
  

the Required tab, while usually doing the right thing, is too blunt an instrument for all cases.

also this allows to have input= or output= on the front tab even if it can be optional due to a flag that prints some info to the terminal and exits. Forcing users to specify output=dummy to overcome Req=YES + --list style flags isn't a very nice solution, when Req=YES is just there to force the important option on to the front tab for visibility.

any thoughts?

Hamish

This sounds like a good idea. It should make GUI tabs more rational.

Michael

[hamish]

any more thoughts on this? ie some way to get around some of the wx module gui usability problems when none of the module's options are (nor should be) required, or some important non-required ones are hidden away in less obvious tabs.

I fear for things like m.proj that default to input=stdin that the best solution from the gui will ultimately be a wrapper script that forces it to require a real file.

Hamish

[martinl]

Replying to hamish:

also this allows to have input= or output= on the front tab even if it can be optional due to a flag that prints some info to the terminal and exits. Forcing users to specify output=dummy to overcome Req=YES + --list style flags isn't a very nice solution, when Req=YES is just there to force the important option on to the front tab for visibility.

suppress_required solves this problem. I am quite satisfied with "Required" as the first tab. Probably we could rename "Optional" to "Others".

Martin

[hamish]

Replying to martinl:

suppress_required solves this problem.

it mitigates the symptoms of the problem, but does not solve it.

I guess my main complaint is Req=YES being used just to force the important options on to the front tab for visibility purposes. Even if a work around exists which lets it not be strictly Required after all. 'd.vect disp=' is an example. These convolutions and tricks strike me as a strong hint that there's something amiss in our current module UI design, perhaps because it's born from our programmer's perspective not the user's perspective.

I am quite satisfied with "Required" as the first tab.

and yet that last 5% is bugging me.. it's a close fit but not exactly right.

Probably we could rename "Optional" to "Others".

I don't really mind either way, but at least "Required"+"Optional" are matched & not mixing metaphors. Verbally (and so logically to the user) I would think that "Others" would more match something like "Important". So as long as there is "Req'd" I'd stick with "Optional", at least it matches..

perhaps I need to read some more design books to better articulate what I mean.

ho ho, Hamish

[hamish]

I guess my main complaint is Req=YES being used just to force the important options on to the front tab for visibility purposes.

... and so the clean command line usage being sacrificed for the benefit of the GUI. With better tab logic these two things would not have to be in conflict.

e.g. the ability to pipe stdin and stdout from m.proj without needing to type cluttering input=- output=-. Maybe redirection locking to avoid the GUI freezing waiting for input when the default input is stdin is a matter for another ticket, but stems from the same GUI+CLI design issues/conflicts. What we have now works pretty well, but it can be improved.

Hamish

[cmbarton]

This ticket is seems to be about a couple of different things

1. The tabs. What argument is on which tab is not needed for the GUI to parse a command. However, for proper error trapping and messaging, the GUI needs to know which fields are required and which are optional. Already, there is a specification for which fields are required and which are optional. Trying to use this specification for tabs has always been clunky. We should not inherently link (and confuse) *WHICH* tab (i.e., notebook page) an argument or flag goes on in the GUI with whether or not the argument or flag is required or not. What would be more sensible would be to do the following:

a) Each command would have a set of tab numbers and name specifications, and each named tab would get its own page in a GUI notebook. For example, in pseudo code, tab 1="Important things"; tab 2="Other things"; tab 3="Trival things". This would produce a dialog with 5 tabs (notebook pages), one each for the specified tabs 1-3, plus a tab for the command output and one for the manual. There may or may not be any arguments or flags on tabs 1-3, but the tabs would be generated nonetheless. It is up to the programmer who manages a module to name and populate the tabs appropriately.

b) Each argument or flag has a specification as to the *NUMBERED* tab on which it is placed. For example, "input" and "output" could go on tab 1, while all flags could go on tab 2. But placement is up to the module programmer/maintainer. Items that are actually *REQUIRED* should be colored, boldfaced, marked with an asterisk, or otherwise noted in some standardized way for all of GRASS. But they don't need to always go on the first tab (notebook page) or on a tab named "Required". It is a good idea to put all required items where they can be easily seen, of course. This is usually on tab 1, but there may be cases where it makes more sense to place some required items on tab 1 and others on tab 2. It certainly makes sense to put some required things and some non-required things under the same tab at times. But what is and what is not required should be clearly indicated in the GUI.

2. Command operation. From my perspective, any command that operates by waiting for user input into a terminal is problematic not only for the GUI but for any kind of scripting. For all GRASS commands to work in a consistent fashion such that they can be used by a human from the CLI and in a program, they need to run such that input can be entered as a value for an argument prior to running the command; the command is then run, does its thing, and ends without any further user interaction. This value can be a path to a text file and things are still OK. While it is OK if commands can accept pipes or redirects, they should not *require* it as a way to get needed information into a command. By the same token, using 'arg=-' as a way to allow interactive user input from the command line is OK, as long at it is not the default. IMHO, this is a cleaner and more consistent command line usage (i.e,. all commands work alike) than having some needing interactive command line input and others not.

[glynn]

Replying to cmbarton:

This ticket is seems to be about a couple of different things

We should not inherently link (and confuse) *WHICH* tab (i.e., notebook page) an argument or flag goes on in the GUI with whether or not the argument or flag is required or not.

Except: required options really should be on the first page. The user shouldn't have to hunt through all of the pages looking for options which they must provide. However, the first page shouldn't be limited to required options.

Other than that: isn't this what ->guisection is for?

[martinl]

Copied from ML

Michael and others. In reference to this issue, I think the proposed
fix is too complex. I would like to suggest a simpler approach.

Let all placement of all fields to be governed by the guisection
command and have developer guidelines and recommendations about the
placement of flags, and required fields on different tabs.

I think for simple modules the hard coded placement is fine, but when
writing more complex modules (like my recent Marxan add ons), the lack
of flexibility can be an obstacle to making things intuitive.

Just my 2 cents.

TSW

[cmbarton]

I agree about using guisection in this way. My point is that there should not be a hard-coded link between the fist notebook page (tab 1), using the word "Required" as the name of the tab, and flagging an argument as required or not. These arrangements should be determined by the module programmer, but should follow GRASS programming standards.

I agree with Glynn that putting required items up front is a very good idea. I simply can imagine a case where it might make more sense from the user perspective to have a required item on another tab.

It would be good if all required items were visually identified in a consistent way. This is a GUI parsing function. This makes it easy for the user to see what MUST be filled in.

Michael

[martinl]

Replying to hamish:

Probably we could rename "Optional" to "Others".

I don't really mind either way, but at least "Required"+"Optional" are matched & not mixing metaphors. Verbally (and so logically to the user) I would think that "Others" would more match something like "Important". So as long as there is "Req'd" I'd stick with "Optional", at least it matches..

most of modules don't have just two tabs (or groups of options) - Required and Optional. Usually optional options are collected to logical groups, e.g. for d.vect into Selection, Colors, Lines, Symbols, Labels. The rest of options goes to Optional. That's reason why I suggested to rename Optional to Others (like other optional options).

Martin

[wenzeslaus]

Currently, you can have required items on other tabs if you specify the guisection. The required items are marked using red star. I consider this as fixing the ticket. Current state is quite satisfactory, but open a new ticket if there are some improvements which could be done.

Optional is still Optional, not Others. It might be better to have Other but perhaps it should be Others if there is no Optional but this starts to be complicated. Please, open a new ticket or write to the mailing list to discuss it.