OSX Xboard 4.7.2 .app

[JoshPettus]

oh btw, all other files work and load correctly, but I just tried to open a trn file with xboard; it didn't load xboard. I realize this isn't a big deal and it's entirely possible trn files were never meant to be used this way and only for syncing multiple xboards in a tournament. But I just wanted to check if that was indeed normal behavior as there wasn't an error message when I had the terminal open. Thanks!

[hgm]

The TRN files are meant to be used this way, as most convenient way to resume an interrupted tourney, or start extra XBoard instances on a running one.

The only thing I can think of why it does not work is that there is something wrong in the association of TRN files with XBoard. XBoard distinguishes files passed to it without preceding option name only in a quite late stage (and should always react, no matter what extension they have, as any unknown extension would be interpreted as a PGN file), and would give some error message if the contents would not match its expectation ("game not found in file", or "unknown option"). BUt if XBoard is not even started the problem obviously cannot be in XBoard.

Can it be that TRN files are already assosiated with another application?

[hgm]

Oh absolutely, infact, I already created the patch but haven't had a chance to upload it. Sorry, today has been a rather busy as I'm sure it is for you

Might want to go through some of it with a grain of salt as not everything would be useful for you.

I still have some questions and remarks about the patches:

*) You redefined the default value of the -openCommand option, but the reason for making this an option in the first place was to make it possible to do such things without changing the source, by including a line "-openCommand open" in the xboard.conf file. So the logical thing would be to patch it there.

*) You redefined SYSCONFDIR/xboard.conf as ../etc/xboard.conf. Does this really work? By specifying a relative path I would expect that XBoard would not be able to find its settings file when you don't start it from the standard directory.

*) The code for suppression of the menu separators seems to have gone. Is this now done automatically by the insert_app_menu_item call?

[JoshPettus]

I should clarify. The TRN File opens xboard, but immediately closes xboard, without any errors, as if the process were finished. it is odd as if it were just that it didn't recognize trn files it would open up a normal window with the conf settings loaded. Can you check if it's not a problem in linux as well? Apparently it has all never worked before because of the / bug, so you may have not noticed the trn not loading.

I didn't realize you could put the open Command in the conf file. I'll do that.

the relative directory works because, prior to launching xboard board, I had the launch script set the working directory to:
cd "${0%/*}"/../Resources/bin
cd $bundle_bin would work as well as that's defined in the script, but I didn't know that at the time. The best solution would be to similarly define such directories within xboard itself; i.e. set */xboard.app/Contents/Resources to be $bundle_res from which i can call upon the various stuff in a more straight forward manner. e.g. for -pid would read bundle_res/share/xboard/textures/default But that would require coding which I don't know. Anyway I chose the bin folder because I could and it would save typing upon calling fairymax, fruit, polyglot and timestamp, which is the majority of everything.

Yah I removed the suppression separator code, as in 2.0.5 version of the library, it removes the adjacent separators for us.

[hgm]

Starting XBoard with a TRN file argument should cause it to proces the -tourneyOptions string as if it were command line (just as bare PGN files or a -viewer argument cause it to process -viewerOptions). So my guess then is that -tourneyOptions is not properly set. To make XBoard start on the tourney would require it to at least contain an -mm option.

If the lauch script does the cd, that's OK. In fact XBoard/WinBoard does a cd itself at startup, but in XBoard I configured the target for this as '.', making it a no-op. WinBoard changes to its install path, so it looks for the master settings file and co-installed adapters and engines always in the same place. I noticed that there was some get_bundle_path function in the GTK-OSX library; perhaps we should use that in OSX to set the internal XBoard variable installDir.

The next XBoard version will know the abbreviation ~~/ in its filename options to indicate its own data directory (/usr/share/games/xboard/ in Ubuntu). This to make it easier to distribute settings files for board themes, so these can refer to the -pieceImageDirectory without having to know its absolute path. This should also make life easier.

[JoshPettus]

I think ~~/ will be more then sufficient in the next version. Until then there is no problems with the relative directory unless we use cmail which sets the working directory to it's own folder for saving its files. And since I don't bother with it, there are no issues.

[JoshPettus]

I finally was able to give loading trn files a try in linux (remembering of course to fix the / bug) And I noticed it was the same exact problem there too. So you shouldn't have a hard time tracking it down. Also for some reason xboard wasn't the default app for .trn files. Might want to take a look at the xml file see if it's there.

[EDIT] Correction! The .trn files that are generated by xboard from the dialog on top of match work fine. I was confused and tried to create with the "Save Tourney Games on" one! I think it's suppose to be a pgn file and so xboard crashed when it tried to load it. (GTK is a little unstable when you hit the browse buttons on that dialog also, even more so in OSX as it's an instant close to desktop. But you said it wasn't finished) This is all the same behavior in OSX. So my mistake.

[hgm]

It is true that the GTK version isn't really finished, but this applies mostly to popup menus (such as the piece menu) and handling of fonts. There shouldn't be any instability in existing dialogs.

Indeed a TRN file is expected to contain options. Feeding it a file containig PGN games is not sensible, but also should not lead to a crash, but to some error message. I will check out what causes the option parser to crash on PNG input.

When you say using the browse buttons on the 'Match' dialog cause crashing, is this as soon as you hit them, or do you see any sign of the file-selector dialog popping up? Is this really different in this dialog than in others (except that there might not be too many others that have a browse button)?

[JoshPettus]

ah ok, That sounds sensible. It's actually on the browse button on some of the dialogs, in Match Options and Engine Options. In linux you will see the browser but if you hit cancel or ok, it will CTD. In OSX it will crash as soon as you click Browse, not sure why the difference.

Dialogs effected include:
Browse on Match -> Save Tourney Games on:
Match -> Game File with Opening Lines
Match -> File with Start Positions
Engine Settings for Fairymax -> Ini File
Engine Settings for Fruit and other UCI engines -> Bookfile
Yet Polyglot book file dialog's browse works fine...
Engine Settings for various UCI -> Polyglot Settings File
Engine Settings for various UCI -> Polyglot Log

I'm sure there are others with other engines. I'm not sure what the commonality is. And it sure isn't a problem with all Browse Buttons.

The only error in terminal is:

Code: Select all

Abort trap: 6
logout

And if it's useful to you here is a whole apple crash report.
https://dl.dropboxusercontent.com/u/504 ... Report.txt

You can of course get around it by typing in a value manually in the box next to browse

[hgm]

OK, I did find a bug there, in the routine BrowseGTK() in xoptions.c. To set up filtering by file extension there, it has to build a string "*.ext" from the information in the options list. It does this in an array declared as

char fileext[10] = "*";

to which it then appends the string found in the option list at the FileName option it is browsing for. This list typically contains things like ".trn".

Problem is that some options should filter multiple filetypes, and have things like ".pgn .game" in the option list. That makes it too long for the fileext array, and will overwrite other stuff, which no doubt causes the crash.

So try to replace the 10 there by 100. This might still not work, because it passes the multiple extensions to the GTK standard file browser in one string "*.pgn .game", while it would have to be taken apart, and added one by one to the fileter as "*.pgn" followed by "*.game". But it should be enough to prevent the crash.

The save game file, load game file and load position file, which crash in the Match dialof, all have such multiple extensions defined. I will have to check it out in the engine settings, as options there are not listed in XBoard, but built from what the engine sent.

I am out of town today, but I will give a more elaborate patch tomorrow.