For a long time it has annoyed me that GUIs require 'installing' of engines before you can use them effectively. (The proper terminology would really be 'configuring the GUI to use the engine', as 'installing' really refers to copying the engine files to your computer.) This goes against the philosophy of Linux packaging, where you want to just "sudo apt-get install" (or your distro's equivalent) and be completely done.
I want to improve that situation. But this requires the introduction of some new standards, and I cannot do that on my own. So I hope that you all want to cooperate to achieve this, by observing the following conventions for installing engines, and equipping GUIs with code to make use of it:
In the following I will use GAMESDATADIR as a symbol to indicate the place where architecture-independent data for games would be stored on the applicable Linux distro. For Ubuntu / Debian this would be
/usr/share/games/
or
/usr/local/share/games/
depending on whether you installed from the repository or from source. My first proposal would be for everyone to pack a (100x50 or 130x65) logo png image with each engine, and install it as
GAMESDATADIR/plugins/logos/<enginecommand>.png
That is, outside the normal data sub-tree for the engine (where it would store books and ini files), which would be at GAMESDATADIR/<packagename>/ . Note the use of <enginecommand> rather than the <packagename>; engine packages can contain binaries for multiple engines (e.g. hoichess and hoixiangqi are in the same package), so that a GUI cannot always know the package name for a given engine. The <enginecommand> does not include any arguments that might have to go on the command line. (In C terms, it is argv[0] only.) So for Fruit the file would be fruit.png, for Crafty it would be crafty.png, etc.
GUIs that want to display logos are then encouraged to look for them in the system plugin logos directory. I will configure the next XBoard release to use this system-wide logo folder rather than one in its own sub-tree.
Then I want to introduce a second convention as well, to make it possible for Linux GUIs to automatically 'install' engines in their engine list. This involves new standard directories
GAMESDATADIR/plugins/<protocol>/
where <protocol> can be "xboard" or "uci" (for starters; any protocol could be added). Engine packages are expected to install a file <enginecommand>.eng here. Any GUI could then search the directories for the protocols it supports (e.g. XBoard would scan the "xboard", "uci" and "usi" directories), at startup or on user command, to see if engines have been installed that it was not yet aware of, and add those (automatically or after user confirmation) to the engine list of that particular user).
For now the contents of the *.eng files would consist of only two lines:
Code: Select all
plugin spec 0.0
<commandline>
In the future this could be extended to contain other information about the engine that would be generally useful to GUIs. Such as games/variants it supports (so the user could for instance limit automatic install to variants he is interested in), how it uses leeway granted to it by the protocol (i.e. whether it prints its PVs as SAN or long algebraic, reports score as own or white POV), non-compliancies with the protocol. (Why require people to admit non-compliancy rather than to fix it? Well, GUIs often have work-around options that could cure them, that now have to be applied by the user, but through this mechanism could be applied by the package maintainers without requiring involvement of the engine programmers, who might no longer be active.)
Obviously standards will have to be developed on how to convey such information. This would be a good place to discuss that. For now this minimalistic version 0.0 of the 'plugin-spec standard' allows us to already start using this mechanism.
I really hope that all developers of Linux GUIs will add support for automatic installing of engines through these plugin/logo and plugin/<protocol> standards.