Xboard 4.6.X Installer for Mac OSX

[imai]

Thanks H.G.M. Time to make up our minds. For the time being I will adjust my xboard GUI to set the default values for the engines and variant based on the installation package of Darklord.

[H.G.Muller]

It is hard for me to suggest something specific if I don't know how the current package is configured. The /usr/local/etc/xboard.conf must specify some user settings file where the actual settings are saved, even if it is not ~/.xboardrc . I suppose this will be in the user's home directory. (Or does Mac OS not have that concept?) If you want to alter your preferences, it would be logical to do it there. This does not require any changes in the distribution package. Just put a file containing

-fcp stockfish
-scp stockfish
-settingsFile ~/myxboard.ini
-saveSettingsFile ~/myxboard.ini

in that location. (Perhaps after renaming the original file there to ~/myxboard.ini , if there were already any settings saved you would like to keep.)

[Josh Pettus]

OSX does have a home directory, but I thought it would be more convenient to put it in the same folder as the Application. I know that isn't exactly the unix way of doing things, Unix lovers do like having different config files for different users. With xboard becoming much more easy to configure from within the program, I think it is about time I did move it to the default way of doing things. I also didn't like ~/.xboard.rc though because that is a hidden file, which isn't a good idea on OSX unless the user happened to downloaded Tinker Tools and reconfigured the OS to view them. (What a pain ) and having it redirect to something visible seemed overly redundant. But oh well, I think it is now time to move it to the default spot so others can ask you for support and it will all be the same.

[H.G.Muller]

Well, I cannot offer any input for what would be most logical on a Mac. Historically WinBoard alwatys had its settings file in the same folder as the executable. In Linux this is of course not acceptable, because all the executables go into folders like /usr/bin or /urs/games, and data files go somewhere else (e.g. /usr/share/games/xboard). That soewhere else is usually not writable by ordinary users, though, so it was also not acceptable. Users there can typically only write their own files, so it was really mandatory to give each user his own settings file. Which could be acheived by letting XBoard recognize ~ in a path name as the user's home directory.

Windows is also evolving in the direction of a multi-user OS, so similar problems started popping up, and people complained about it. So I made it possible also in WinBoard to indicate private user files, by letting it recognize %APPDATA% or %HOMEDIR%.

I don't know how well Mac OS protects users from each other, or even if it knows the concept of different users. If different users can overwrite each others files, there would be no problem in having them share the settings file.

If .xboardrc is not a good idea, xboard.ini could be a logical choice.

If you currently redirect the settings file to the XBoard folder (mimicking the old WinBoard method), the best solution to Imai's problem would be that he puts another redirection file in that place, either to a priviate user file like ~/xboard.ini or to a common file settings.ini in the XBoard folder, and specifies the altered default settings in that redirection file.

[Josh Pettus]

Well OSX is actually very Usr and Permissions specific, but unlike linux distro's there is much more leeway in giving access to files for other users. Things in the /Applications/ folder, for instance, are suppose to read and write accessible to everyone. The home folder is very much accessible only by the usr. Unix specific folders (etc, opt, local...) also exist but are hidden from the average user.


Actually now that you mention it, some of the files generated by the package aren't even read accessible for users other than the person who installed the package, specifically the /usr/local/etc/xboard.conf. Or really the /etc/ folder before it. I need to fix that. Don't worry in OSX permissions are a pain as well.

As for the .../etc/xboard.config file should say how about this?

Code: Select all

-liteBackTextureFile  "/Applications/Xboard/Textures/wood_l.xpm"
-darkBackTextureFile  "/Applications/Xboard/Textures/wood_d.xpm"
-soundProgram "afplay"
-saveSettingsOnExit true
-saveSettingsFile "/Applications/Xboard/xboard.conf"
-settingsFile "/Applications/Xboard/xboard.conf"


I know you wanted the wood textures to be default, and were always accessible in the .xboardrc
-soundProgram is a must as it is OS specific, but is also accessible.

And yes the user can/should put in -saveSettingsFile ~/xboard.ini if they really want to in the /App../xboard/xboard.conf.

[Josh Pettus]

Even then, it doesn't include the default -firstChessProgram option by default when creating the .conf file, which is what he wanted because it is a volatile setting. It has to be added to the xboard.conf manually.

All the options when generating the new config file are still the same as before, which I kinda knew would be the case. It has always written all the nonvolatile settings whether or not that was predetermined in the /usr/local/etc/.conf

I think in order to do what Imai wants, I'd have to include an xboard.conf in the Applications/xboard folder when installing which I didn't want to do, because then it would completely overwrite people's config file when updating. Wouldn't be very nice. he will just have to do that himself.

[imai]

Darklord,
Overwriting the /Applications/Xboard/xboard.conf file should not be such a big problem. There should be only a few lines in this file e.g.:

-fcp /Applications/Xboard/Engines/Fairymax/fairymax
-scp /Applications/Xboard/Engines/Fairymax/fairymax
-variant Normal
-settingsFile ~/xboard.ini
-saveSettingsFile ~/xboard.ini

The user can then change the "volatile" settings in this file and the other settings in ~/xboard.ini, both will then be accessible for the common user.
The usr/local/etc/xboard.conf can remain the same, the settings in this file will be superseded by the settings in /Applications/Xboard/xboard.conf

It would be nice if you would change your installation package in such a way that the user can choose between a clean full install and an update where the existing /Applications/Xboard/xboard.conf file could remain as is. Then there would be no problem at all.

The ideal solution would obviously be that sticky changes of engines and the installation of new engines could be done via the Xboard menu. Nowadays users should not be tempering with config files or using terminal commands but that is something for the (near) future ????

[H.G.Muller]

I am not sure if the mentioned -fcp, -scp commands for Fairy-Max would be needed in the standard install, (-variant normal is certainly superfluous), and if they would need to contain the full path name. In Linux all that is needed to startup Faity-Max is the command 'fairymax' (so -fcp fairymax would suffice if it was not already the compiled-in default). Perhaps on OSX this does not work, but I am not sure if Fairy-Max would be able to find its fmax.ini file in that case either. That depends on where you installed that; it seems that in the Windows-like install it would be logical to place fmax.ini in the same folder as the Fairy-Max executable, and change to that folder before invoking the engine, i.e.

-fd /Applications/Xboard/Engines/Fairymax
-fcp ./fairymax
-sd /Applications/Xboard/Engines/Fairymax
-scp ./fairymax

As for having an easier way to change the default engine: I guess in the future I could make it such that the first line of the -firstChessProgramNames list would be automatically taken as default engine. That is, I could make the compiled-in default for -fcp equal to the empty string, and if it still is an empty string after all ini files and command-line options have been processed, process an extra -fcp with the first line of -firstChessProgramNames (and similar for -scp). And if -firstChessProgramNames is still at its compiled-in default empty string, process an extra -ncp in stead.

I think the user can already edit the list of engines through the menu (or was this only in WinBoard?), so he can easily move the engine he wants to have as default to the top of the list. The list would be stored in his saved settings in that case, not in any file that redirects, because -firstChessProgramNames is a persistent option, not a volatile one.

This does not solve the general problem of adding volatile option specs in redirecting ini files. This is asking a bit much, though, plus that I am not sure it is desirable. There is no limit to the number of redirections through settings files a user can make, so how is XBoard to know which one you want to make changes in? And volatile options were not chosen to be volatile without reason. Inviting for non-expert users to change them by providing menu items for that, has a high likelihood to create a configuration where XBoard no longer seems to function properly, of which they don't know how to get out.

[Josh Pettus]

Well actually, I made the command work. I added a soft link in /usr/bin for fairymax, xboard, and fruit which are installed by the installer. So "xboard -fcp fairymax" will work just fine. I now also edited the fairymax makefile so the fmax.ini can be in the same folder as the engine, or actually the absolute directory /Applications/Xboard/Engines/Fairymax, but it's not in the package yet. Seemed to make sense. Hope you don't mind.

I like that solution Mr. Muller if you can. Iami, if I have the installer put a xboard.conf file with a couple lines in the xboard folder, it won't update the existing file, it will fully replace your file so all there is is a file with a couple lines. Not good for someone like me who has a bunch of engines or specific about their settings.

As for editing the engine list in xboard, as of now, I'm afraid you can't except add to the list, unless you edit the xboard.conf directly.

[imai]

H.G.M. / Darklord42
I would be quit happy with the solution as proposed for the default engine, no need for redirecting or changing the config file.
For the time being I created an Apple script that can change the -firstChessEngine value in the /usr/local/etc/xboard.conf file and let you create a link in /usr/bin for new engines.
If you are interested in the script let me know.
When I was scripting, the question came up what should happen with the links when Xboard is un-installed ? Is the uninstaller of the package taking care of it ? And if so, can I get the code for removing the links from /usr/bin?
Best regards,
Teun

[Josh Pettus]

Sorry didn't see your post. You could always change the first loaded fcp by adding it in /Applications/Xboard/xboard.conf,
e.g. -firstChessProgram fruit -fUCI,
and I think that should be the suggested method. As to the uninstaller with the links, yup it removes them.

It's just simply

sudo rm /usr/bin/fairymax
sudo rm /usr/bin/maxqi
sudo rm /usr/bin/shamax
sudo rm /usr/bin/fruit

I don't think a whole script automating would be necessary with the internal engine manager. But could be useful with the xboard 4.5.2.

[Edit]

Check that for some reason -firstChessProgram fruit -fUCI in xboard.conf isn't working because it's ignoring the -fUCI command. WB engines work fine. Why is that?

[H.G.Muller]

Strange. For me

-fcp fruit -fUCI

in the xboard.conf file is working without problems.

[imai]

This addition cq change will only work in /usr/local/etc/xboard.conf, not in /Applications/Xboard/Xboard.conf where it is removed at the next save of Xboard.
The /usr/local/etc/xboard.conf is a hidden file which is normally not accessible, hence the Apple script.

w.r.t. the un-install part of the Xboard package I had hopes that it would also remove the links of the engines which were installed manually by the user. It would be possible if the user would install new engines solely in sub folders of the Engine folder. At least that is what I do and so a program can check for engines in these sub folders and subsequently remove the links.

[H.G.Muller]

Sure, -fcp and -fUCI are volatile options. They can only be specified in a settings file that redirects, not in the file where the actual settings are saved. If the user wants to alter defaults for volatile options, compared to the master settngs file(which is inaccessibleto him), he has to create another level of redirection. There is no other way.

[Josh Pettus]

@HGM
Ah that makes sense.
@
iami
For the uninstall i can only have it remove things I know exist. It will be up to the end user to remove anything he knows he put in himself. I am no programer you see.

But if your script can manage all that, then that could be very useful.

Again, I think it is necessary to use HGM's built in engine manager, so as to simplify the number of link files that need to be made to a couple crucial programs like xboard itself and polyglot. Of course this will be in beta for a while i'm sure.

So yah, send me the script. I'd be happy to throw it in the xboard stable package.

[imai]

Darklord42,
I have send you the script by PM. It has a menu to change the firstChessProgram name in xboard.conf, to create links of engines in /usr/bin on an individual basis and to remove all engine links in /usr/bin of engines located in the /Applications/Xboard/Engines folder or subfolders.
Any comment or suggestions to improve are welcome.

[imai]

In addition to the previous post:
I would not recommend to include the full Apple script in your installation package. The part that removes all the engine links can be destructive if a user has a (non engine) file in Engines or in a subfolder of Engines with the same name as a program (non Xboard) in /usr/bin. In such a case the program in /usr/bin will be removed causing that program to malfunction or not to function at all.
The parts that changes the xboard.conf and the part that installs the links are i.m.o relatively harmless because the user can always re-install Xboard.

[Josh Pettus]

Well how about this. Can't we put all links in a subfolder in "/usr/bin/" called engine and when we want to remove all and only the engines, we simply delete that folder.

[imai]

Sounds good, simple and efficient but you will have to do more than just that.
I created /usr/bin/engines, put the links to the engines in this folder, set the PATH to this folder, removed the links from /usr/bin and got an error message when I started xboard.
The error was "POLYGLOT : pipex_open(): stockfish : No such file or directory"
I hope you know how to fix this.

[imai]

OK, What happened was that I changed the PATH with "export PATH=$PATH\:/usr/bin/engines" but then the change is not persistent.
After adding "/usr/bin/engines" in the file "/etc/paths" with pico, the configuration works.
I suppose that you intend to create and remove the /usr/bin/engines file in your installation package, so Apple script is not needed for this part.
regards