XBoard interactive help

[JoshPettus]

Well most people download some stand alone app with the engine (usually stockfish) built-in. (Unless it's Hiarcs, it is probably lacking) That really is apple's model. But lets for the sake of argument forget that.

If it's SCID vs Mac or Xboard we are talking about, then most people will grab their engine on-line. Julian's web page has quite a few, Stockfish is always available, throw the engine on their hard drive and have the app point to it just as people do with windows.

The truth is OSX is a whole paradigm floating on top of UNIX operating system, and as far as most end users are concerned, you have to forget that that stuff exists. The whole /usr directory (as with /etc /var /bin /sbin /opt) are all very well hidden from users. It doesn't even come with the tools to run installation scripts. You have to download XCode for that (and for a long time you had to register as a developer to do that!). Then you possibly have use a package manager like fink, macports, or homebrew to fill in the necessary holes. (which most people who just want to play chess are not going to do) Your plug in system, while novel, unfortunately will not work for mass deployment on OSX.

With ChessBase for mac being as bad as it is, Chess for macs have been a pretty bad scene..

[hgm]

AFAIK the engines Julian hosts are just bare executables. If that is what people use, then they obviously will have no manual. The whole system only makes sense when the engine comes as a multi-component package with some standard structure, so that the path name of an engine can somehow imply the pathname of a manual file in some standard format.

Linux engines distributed as tar balls often come with sub-directories .../bin/ in which the actual binary then is located. In this model it would be logical to have a .../share/man/man6/ with the actual manual file, a .../share/games/<name>/ for opening books etc. For a compliant install people could unzip such packages in /usr/local/. That doesn't seem much more work than unzipping them anywhere else.

To make it easier for the user unpacking of the tar ball could be left to XBoard. The Engine field of the Load Engine dialog could be used to browse to the tar ball for the engine, and the OK function of that dialog could detect the .tar.gz extension, and unpack the tar ball in /usr/local/.

[Evert]

It's true that applications come in bundles (for non-mac users: dressed up directories with a standard layout), but what about plugins for applications? Could chess engenes be treated as those?

I suppose that would require an "installer" though, which is always weird (running an installer to me always feels like running a lazy port of a Windows program). However, that could nevertheless install the engine in a well-defined place where it can be picked up by other GUIs. It just needs to be documented.

[JoshPettus]

That might not be a bad idea..
But perhaps we can forgo the installer

Take a folder labeled EngineName.bundle have the engine executable in the root of that folder with any resource files, manual, and logo and have people drag that bundle file to a place where XBoard will find it.

Or we can create a new container .CEngine or something unique and have xboard automatically register it when people click on it. I know the dosbox emulator Boxer creates it's own container files called .boxer which are the dos game self-contained in a pseudo executable

I kind of like the second idea, I'll look into it.