Engine Settings menu (e.g. for UCI options)
Posted: 14 Jul 2009, 14:36I still have to add a dialog to WinBoard for setting the UCI options from the menu. (Currently they can only be set through command-line options, in particular /firstOptions="..." and /secondOptions="...", not interactively.) In XBoard this dialog already exists, but it looks really ugly, as I just create controls for each option one above the other as the engine sends them, mixing all types.
If you run Toga with Polyglot, the two of them together produce some 50 options...
Are there any suggestions for how I could present 50+ options in a dialog that is still useful? WinBoard would not have the slightest idea what the options are for, so grouping them according to function would not be possible. It could group them by type (I suppose this has some advantages, as some controls are intrinsically less wide than others, so that they could be layed out as multiple columns). Or I could sort them by name, aphabetically. The latter might not be helpful, as the user might also have no idea how options are called and thus what to look for.
If you run a UCI engine through Polyglot, all options that control Polyglot behavior (and there are a lot of those!) have names that start with "Polyglot ". I guess that at least WinBoard could group these in a separate section of the dialog, so that for UCI engines you would have two sections, very much like in the polyglot.ini file. For WinBoard engines this section would be absent, of course.
I guess button and check options are the narrowest (basically just the size needed to print the option name), spins a little wider (as they need a numeric input field next to the name), combo-boxes still wider (as their control element typically contains a short phrase), and string inputs the widest of all. I guess we could make the width ratio of these elements 1 : 1 : 2 : 2 : 4. We could then have 4 buttons or checks on a row, 2 spins or combos, and one string.
Toga has 7 checks, 19 spins, 2 combos and 2 strings. When grouped per type at 4 units per line that could go into 2 + 10 + 1 + 2 = 15 lines.
Polyglot has 15 checks, 5 spins and 2 strings. That could go into 4 + 3 +2 = 9 lines.
That might be just about doable, in two-columns (left column Polyglot, right column the engine, perhaps moving some engine options in the Polyglot column under a separator.).
Problem of grouping the controls for compactness is that many features are controlled by several controls of a different type, that would thus be separated. E.g. Delta Pruning (check) and Delta Margin (spin) or Verification Search (combo) and Verification Reduction (spin). Retaning the order in which the engine sends them would then give alternating check / spin combinations, which could be fit on a line, but still waste space. (And they might accidentally get on different lines because there was still room to fit a check there, defeating the purpose). The worst spacewise would be alternating checks and strings, e.g. Alternate Piece Values (check) and Piece-Value file (string). This would put only a single check per line.
Buttons seem to virtually never occur, and combos seem rare. Another design could be to have a column of checks on the left, and spins or combos right of it, or a total comlun width of 3 units. This could then also be used for a string input control, the name of the string option going above it, with room for a check on that same line. Checks with option names similar to a spin or string following or preceeding them could be preferentially be placed next to it (if WinBoard could be made smat enough to recognize the similarity), and solitary check options could be placed in the holes this placement would leave, top to bottom.
Any other ideas or suggestions?
If you run Toga with Polyglot, the two of them together produce some 50 options...
Are there any suggestions for how I could present 50+ options in a dialog that is still useful? WinBoard would not have the slightest idea what the options are for, so grouping them according to function would not be possible. It could group them by type (I suppose this has some advantages, as some controls are intrinsically less wide than others, so that they could be layed out as multiple columns). Or I could sort them by name, aphabetically. The latter might not be helpful, as the user might also have no idea how options are called and thus what to look for.
If you run a UCI engine through Polyglot, all options that control Polyglot behavior (and there are a lot of those!) have names that start with "Polyglot ". I guess that at least WinBoard could group these in a separate section of the dialog, so that for UCI engines you would have two sections, very much like in the polyglot.ini file. For WinBoard engines this section would be absent, of course.
I guess button and check options are the narrowest (basically just the size needed to print the option name), spins a little wider (as they need a numeric input field next to the name), combo-boxes still wider (as their control element typically contains a short phrase), and string inputs the widest of all. I guess we could make the width ratio of these elements 1 : 1 : 2 : 2 : 4. We could then have 4 buttons or checks on a row, 2 spins or combos, and one string.
Toga has 7 checks, 19 spins, 2 combos and 2 strings. When grouped per type at 4 units per line that could go into 2 + 10 + 1 + 2 = 15 lines.
Polyglot has 15 checks, 5 spins and 2 strings. That could go into 4 + 3 +2 = 9 lines.
That might be just about doable, in two-columns (left column Polyglot, right column the engine, perhaps moving some engine options in the Polyglot column under a separator.).
Problem of grouping the controls for compactness is that many features are controlled by several controls of a different type, that would thus be separated. E.g. Delta Pruning (check) and Delta Margin (spin) or Verification Search (combo) and Verification Reduction (spin). Retaning the order in which the engine sends them would then give alternating check / spin combinations, which could be fit on a line, but still waste space. (And they might accidentally get on different lines because there was still room to fit a check there, defeating the purpose). The worst spacewise would be alternating checks and strings, e.g. Alternate Piece Values (check) and Piece-Value file (string). This would put only a single check per line.
Buttons seem to virtually never occur, and combos seem rare. Another design could be to have a column of checks on the left, and spins or combos right of it, or a total comlun width of 3 units. This could then also be used for a string input control, the name of the string option going above it, with room for a check on that same line. Checks with option names similar to a spin or string following or preceeding them could be preferentially be placed next to it (if WinBoard could be made smat enough to recognize the similarity), and solitary check options could be placed in the holes this placement would leave, top to bottom.
Any other ideas or suggestions?
)