> ok... how about trying several default engines in that case that should be > easier to implement... e.g. try fairymax then crafty then gnuchess. I > would think that on many systems that might also solve the problem that > fairymax won't be installed on many systems.
I think this is a bad idea. It goes against the logic of using a variable name from the appData, and only initializing this at startup. It would require a list of hard-coded engine names to be buried very deep in XBoard, and the names will in most cases not be what the user wants. (Why not Fruit, why not Glaurung?) The problem of a missing default engine is clearly addressed in the FAQ. If we want to protect the user from it occurring, we should simply package the engine with the XBoard binary. But I think bundling is a bad idea on Linux syetems. Just let them get used to the idea that they should select the engine they want by giving -fcp <engine>, or use -ncp.
