WinBoard-AA beta release

[hgm]

I have "save settings on exit" switched off. I want XBoard to start in a reasonable default state, and if I do something to the windows for something particular I want to do, I don't want that to be remembered. What would be useful is the ability to store different settings as a "profile" and let me pick the one I need from a list.

This sounds like a task for the "themes" list. Currently the window configuration is not amongst the options that would be included in a new theme you create, but it would be easy to do so. Perhaps the View->Board dialog should have a checkbox "include window configuration", which, when checked, would also save the options that control opening of the main auxiliary windows (Engine Output, Move History and Eval Graph), and perhaps their geometry.

Storing the engine list as part of the settings is understandable from a design point of view, but a mistake from a user point of view. It should be separate.

This both has advantages and disadvantages. I run WinBoard with different settings files for different tasks, so that each of the tasks can use its own persistent settigs. E.g. as ICS client I want it to look completely different as for engine matches, (not to mention doing Chess vs Chu Shogi), and I don't want to have to reconfigure it every time I switch to another task. As it is now, each task can have its own engine list.

I guess it would still be possible to store engine lists separately for different tasks, by making the name of the list file a persistent option. Then different settings files used for different tasks could still refer to the same list, but they could also use different lists. So this is even more flexible than having the engine list stored in the settings file.

So a (persistent) option -engineList <FILENAME> could behave exactly the same as the option -settingsFile (-ini) does now, except that the filename gets remembered separately, and will then be used for all operations on the engine list, rather than for saving the persistent settings. The option -firstChessProgramNames would then no longer be persistent, and thus not get into the settings file. Manipulation of the engine list would then occur on opening/closing the Load Engine (and Edit Engine List) dialogs, rather than on starting / quitting XBoard. This would also solve the synchronization problem you describe below, at least for the engine list. And of course I would make a similar option for the themes list.

This would make some of the solutions I described in the previous posting much cleaner: I would not have to read a settings file without processing the options, just to hunt for the engine list and either process only that, or replace it by an updated version. It just can read or overwrite the entire file it currenly uses as engine list. And I cannot imagine any downside yet. I really like this.

I don't think there is a way to synchronise different instances, unless you make them aware of eachother and have them share data explicitly. In the case of the engine list, the problem could be ameliorated by having an explicit "reload" option. Or you do that if, on gaining focus, the engine list has been updated since it was last read.

[hgm]

OK, I have pushed some patches in the v4.9.x branch of the hgm.nubati.net XBoard repository, which implement storing the engine list in a separate file. For WinBoard this is yet untested.

I implemented the -engineList option as a normal persistent filename option. But after reading the normal persistent settings file, and processing the command-line arguments, it now also parses the specified engineList (if the name is not an empty string, which it would be by default) as a settings file. This is supposed to contain only the -firstChessProgramNames option, and its processing would overrule the list in the normal settings file.

Whenever the Edit Engine List or Load Engine dialog is popped up, the file with the engine list is parsed again, before the engine list is displayed. When these dialogs are left with 'OK', the (modified?) engine list is written to this file. This should make that modifications to the engine list are always saved, and always shared between all XBoard instances.

To activate this mechanism, you can run XBoard once with the -engineList option, and a filename of choice. In the future I will configure XBoard to use some standard name for this hidden in the user's home directory (e.g. .xb_englistrc ?).

BTW, this version also does unconditional protocol detection, and when you try to install an engine as WB v2 (i.e. not ticking the UCI or WB v1 checkboxes), it will discover it when it is in fact UCI or v1, and will add the -fUCI or -protocolVersion 1 options to its entry in the engine list. (This will only work for the first engine. (Because the second engine will only be loaded when actually needed, and thus cannot be vetted.)

[Evert]

To activate this mechanism, you can run XBoard once with the -engineList option, and a filename of choice. In the future I will configure XBoard to use some standard name for this hidden in the user's home directory (e.g. .xb_englistrc ?).

BTW, this version also does unconditional protocol detection, and when you try to install an engine as WB v2 (i.e. not ticking the UCI or WB v1 checkboxes), it will discover it when it is in fact UCI or v1, and will add the -fUCI or -protocolVersion 1 options to its entry in the engine list. (This will only work for the first engine. (Because the second engine will only be loaded when actually needed, and thus cannot be vetted.)

I think the modern standard is to store various settings in files under ~/.xboard/ rather than cluttering the home directory with .rc files (so ~/.xboard/engine_list). I'll update to see how this works (later in the week, my work weeks are front-loaded). I tend to run from the command-line though, so I never used the pre-configured engine list much.
The asymmetry between first and second engine is unfortunate though, from an end-user perspective. Something to keep in the todo-list, I think.

[JoshPettus]

Hey Harm! I saw some of your new work and wanted to give it a try. There looks to be a bug with the checkbox "Add this engine too list" where it appears to be adding the engine regardless if the box is checked or not.

For autodetection, Are there any special settings for -adapterCommand and -uxiAdapter? I tried it with crafty stockfish and anita (UCCI), and so far it was only successful with stockfish. Anita, it tags -firstProtocolVersion 1 at the end rather then -fUCCI and crafty it just says "Failed to start chess program, image not found."

I have for the app bundle
-adapterCommand '~~/../../bin/uci2wb %fcp %fd'
-uxiAdapter "~~/../../bin/uci2wb -%variant %fcp %fd"


Another thing, and I think we had this discussion. Under "Engine Directory" it puts a "." as default. Underneath it mentions that leaving it blank allows it to derive the directory from the engine path. Wouldn't we want this to be the default behavior? The "." rather undermines the whole functionality.

[hgm]

Ah, yes, the new code does not pay attention to that checkbox anymore, because due to popular demand I was thinking about deleting it altogether. There is reasonable doubt whether anyone except me would actually use that. If it only is needed in rare cases Edit Engine List seems an acceptable option to delete it later.

I hate to expose non-expert users to the engine list. But it is much more likely that people would want to delete existing engines somewhere within the list (e.g. when the install a newer version) than that they would want to prevent a new one from being added. So having them delete it in the latter case doesn't significantly increase their exposure to the list.

The auto-detection currently only works for WB vs UCI. It doesn't try UCCI or USI. I am not sure auto-detect is a good idea for USI and UCCI engines. These are typically very fragile, and crash or hang when they don't get what they expect. (E.g. if you would send 'xboard' to PetitShogi it already dies.) I could of course make the 'uci' probe when there is no response to 'protover 2' depend on the variant (i.e. use 'usi' in shogi, and 'ucci' in xiangqi), but there also exist UCI Xiangqi engines. And if the engine is already dead or hangs by the time that probe is sent, it would be detected as WB v1 anyway. So I guess a better solution here would be to provide an option -defaultInstallProtocol, for use in packages intended for Shogi or Xiangqi use, which would make the Load Engine dialog start the protocol combobox as USI or UCCI, rather than 'autodetect'.

You have configured the adapters correctly.

In Linux '.' would be the correct default; compliant Linux engines do not need a specific directory; they should know the path to their support files (like /usr/local/share/games/fairymax/). So I used '.' there as a method to ensure there would be no change in directory when starting the engine. It could very well be that this is not satisfactory for an OSX app, however. In that case we should add an option 'defaultEngineDirectory' to fill that text entry, and configure it as an empty string for the OSX App bundle. On second thought: when installing compliant Linux engines, you are not likely to use the browse button for the engine binary; most people would not even know where to find that. It would be far easier to just type the command ('fruit'). And then there would not be any pathname to derive a directory from, which could be made to default to '.'.

[JoshPettus]

For the checkbox, I suppose that's reasonable. For me, I use that checkbox for testing, in which case, it's great. Is the new code completely incompatible with the option?

-defaultInstallProtocol sounds like a good idea.

For the OSX app, I'd be content to add a -clearDefaultEngineDir flag or something. You're right. Most people would just download a precompiled engine binary somewhere, in which case assuming the binary's directory as the place to look for extra resources is a reasonable default.

[hgm]

OK, I pushed patches which pay attention to the add-to-list checkbox again, and with options to control the initial content of the directory an protocol controls.

[JoshPettus]

I'm sorry to say your repo has an error when I attempt to log on.

Code: Select all

syntax error at gitweb.cgi line 3182, near "$format qw(RSS Atom)"
Global symbol "$format" requires explicit package name at gitweb.cgi line 3186.
Global symbol "$type" requires explicit package name at gitweb.cgi line 3187.
syntax error at gitweb.cgi line 3210, near "} else"
syntax error at gitweb.cgi line 3217, near "}"
syntax error at gitweb.cgi line 3279, near "}"
syntax error at gitweb.cgi line 3297, near "$format qw(RSS Atom)"
Global symbol "$format" requires explicit package name at gitweb.cgi line 3298.
Global symbol "%href_params" requires explicit package name at gitweb.cgi line 3299.
Global symbol "%href_params" requires explicit package name at gitweb.cgi line 3300.
Global symbol "$format" requires explicit package name at gitweb.cgi line 3300.
Global symbol "$format" requires explicit package name at gitweb.cgi line 3301.
syntax error at gitweb.cgi line 3302, near "}"
gitweb.cgi has too many errors.

[hgm]

That is weird. My first thought was that my website must have been hacked. But when I logged on with ssh, the gitweb.cgi file shows as not being changed since 2010. It is a Perl script, and since I don't know Perl, it is not possible for me to see whether the error messages make sense. Likely they are caused by the data on which it acts (i.e. the git repository itself) being corrupted. When I try to access the XBoard part of that repository with git itself, it doesn't report any errors, however. The problem could of course be in another repository then xboard.git, but recently I only pushed a commit for UCI2WB, and things certainly worked after that.

I have pushed the XBoard v4.9.x branch now to my winboard.nl repository as well; this still seems to work.

[Evert]

Could be a Perl update on the server. You could see if there's a newer version of the Perl script that displays the repository.