Congrats on a very nice program.
I installed it under SuSe 10.1 and Debian etch and it performs quite well although there are a few minor issues:
1. Printing is broken. The postscript produced by the program is not considered valid by ghostscript consequently gv does not work nor does direct printing of the .ps files. FWIW, the generated PDFs are ok.
2. Autosave does not work. Games should be automatically saved when they have entered the complete state (1-0, 0-1, 1/2-1/2, or player requests new game). At present games are queued up and are only committed after user answers dialog question. This is *very* annoying.
3. User settings do not go into effect immediately. As soon as the user confirms a change the new setting should be active.
4. I won a game on time, but Jose declared the computer the winner! Cmon, it really is possible for master strength players to win at a reasonable time control. :-)
5. There are some minor GUI issues too: a. please don't grey out the clock digits for the side not on the move (very annoying), and b. Is there any way to make the board squares bigger in proportion to the pieces? I find that with all the piece sets the pieces are too big in proportion to the squares (I find this hard on the eyes). The Fritz GUI has a nice proportion.
6. It seems that opening moves are not played at a frequency corresponding to their probability. By default opening moves should have reasonable weighting assigned to them.
Overall a very good program which I will gladly recommend.
Unfortunately I just discovered a very serious bug: with the Fischer time control and Toga engine Jose will let the clock run out!
The problem with the clock running out seems to be related to the "move now" capability, i.e. the computer makes an opening move you don't want and in the process of correcting this you use "move now":
1. Engine chooses undesired opening move.
2. You step back half a ply via left arrow in gui.
3. You enter desired opening move.
4. At this point the Jose gui prompts the engine to make a move for the other side (which it shouldn't because the other side is still the human player).
5. The human player deletes the erroneously engine generated move from step 4. and substitutes his move instead.
6. At this point we should be back on track. The human was last to move and executing "move now" should result in the gui inducing the engine to produce a move for the computer's side.
7. But this is where things get screwed up. After "move now" sometimes you get an instant move (presumably because still in book), but at other times the clock may or may not just run out. And when the clock runs out for its side jose declares itself the winner!!
So it seems to have difficulty keeping straight which side the engine is calculating for. The problem is exacerbated when the human is black, but it is repeatable for either color.
Sorry, but this is a show stopper which effectively renders the program unusable. There may be a workaround, but there shouldn't need to be. Correcting an undesired opening move on part of the engine (or human for that matter) and having the gui properly keep track of players' colors should be flawless and intuitive.
Sorry, the showstopper problem I reported is nothing new. It seems to already have been reported as the "taking back moves" bug. Instead of crashing though the gui just goes braindead and lets the clock run out. Incidentally I have seen this strange bug in the Shredder Linux Demo as well. I'm being to wonder if this is Java specific rather than just a design/coding bug. Unfortunately since I have no access to the source for either program there is nothing I can do to try debugging this.