WinBoard-TM installer

[hgm]

a) When the trn file is loaded , the contents of the match options dialog box are not automatically updated. If I close the dialogue and open it again , it updates it.

This is because it only loads the tournament file when you 'OK' the dialog (which then also closes it). You would want to see the contents of the tournament file already displayed in the when you entered the filename in the tournament field? (When the file pre-exists.) Logically that is a bit difficult, because you might type the name of the file, and how would it know if you are done typing? It would require some auxiliary 'OK' button for just the tourney-file name, which would then trigger an attempt to open the file.

I am not sure if it is wise, though, to put the info from an existing tourney file in the dialog, though. It would suggest that people can change it before pressing 'OK', and for most tourney parameters this cannot be allowed at all. (The number of tourney cycles might be the only exception; it is harmless to increase that during a tourney.)

So if we want to do that, the entire dialog should really be grayed out until you first OK the tournament-file name. After that, for an existing file, it could put the values in the dialog, but leave them grayed out except for the number of cycles. But that would not really leave the user much to do before he OK's the complete dialog, so one might wonder why OK'ing the tourney file would not already close the dialog. (Unless you want the user to give an opportunity to discover: "hey, this wasn't the tourney I wanted".) If the file did not pre-exist, all controls could be un-grayed.

b) Once the tournament is over and I want to increase the number of games, I can't do it from the dialogue box. Only way is to open the trn file and edit the number of games.

Indeed, this is true. I think I pop up an error dialog now when you try to restart a tourney that has already finished, saying that all games have already been played. But I could change that by giving the nmber of tourney cycles in the dialog precedence over the number of tourney cycles in the tourney file (if it is larger), before making that test. (Currently the dialog settings are completely ignored if the tourney file exists.) Would that be better?

c) Display of tourney participants list gets screwed once the dialogue is closed and open again.

Screwed in what way? Is this a CR+LF problem? This definitely should be fixed. The idea was that it should be easy to start a new tournament with exactly the same parameters when another finishes.

[hgm]

First bug. The result display on the title bar doesn't match what is stored in trn file. I don't think it is storing the results correctly

To be frank, I am not sure what I should display there during a tourney. So I did not touch that part of the code at all; it is simlpy counting the 'score' like it is a two-player match with alternating colors. As the existing code deduces the number of draws by subtracting wins+losses from the total, and I manipulate the total in stragnge ways during a tourney, it leads to reporting phantom draws. But in general (i.e. with more than two players), the displayed numbers have no reality value at all. I just postponed making any changes there until I knew what the desired behavior is.

What would you want displayed in, say, a round-robin? Just the total result of all pairings between the current players? The points they have so far in the entire tourney? The perentage score they have? (They need not have the same number of games, in a tourney that runs concurrently on many WinBoard instances.) And what in a (multi-)gauntlet?

[Daniel Shawul]

This is because it only loads the tournament file when you 'OK' the dialog (which then also closes it). You would want to see the contents of the tournament file already displayed in the when you entered the filename in the tournament field? (When the file pre-exists.) Logically that is a bit difficult, because you might type the name of the file, and how would it know if you are done typing? It would require some auxiliary 'OK' button for just the tourney-file name, which would then trigger an attempt to open the file.

I think it is good to sync it. If I remeber my old MFC coding, you can load
all the controls in the dialogue with the trn info when file edit box looses focus
anytime to anyother control. That happens when pressing enter, tab etc..
For example, the list of engines is blank even when I have loaded the trn, which could be a little confusing.
Then I can edit any other control knowing I have uptodate data of the trn file.
If the file doesn't exist (like when we are creating a new one), load the default.

Edit: ON_EN_UPDATE message may be better than FOCUS message since the former is sent only when user is finished with editing. User can switch focus from one control to the other randomly..

Indeed, this is true. I think I pop up an error dialog now when you try to restart a tourney that has already finished, saying that all games have already been played. But I could change that by giving the nmber of tourney cycles in the dialog precedence over the number of tourney cycles in the tourney file (if it is larger), before making that test. (Currently the dialog settings are completely ignored if the tourney file exists.) Would that be better?

If the contents of the dialog box and trn file are synced as above, would that help ?

Screwed in what way? Is this a CR+LF problem? This definitely should be fixed. The idea was that it should be easy to start a new tournament with exactly the same parameters when another finishes.

Yes, it puts them all in one line which makes it difficult to delete one of the engines f.i.
It is possible to delete an engine from the tourney that way , right ?
Also I think a list box would be better than a large edit box for the participants list. One raw per engine, to select and delete it.

[Daniel Shawul]

To be frank, I am not sure what I should display there during a tourney. So I did not touch that part of the code at all; it is simlpy counting the 'score' like it is a two-player match with alternating colors. As the existing code deduces the number of draws by subtracting wins+losses from the total, and I manipulate the total in stragnge ways during a tourney, it leads to reporting phantom draws. But in general (i.e. with more than two players), the displayed numbers have no reality value at all. I just postponed making any changes there until I knew what the desired behavior is.

What would you want displayed in, say, a round-robin? Just the total result of all pairings between the current players? The points they have so far in the entire tourney? The perentage score they have? (They need not have the same number of games, in a tourney that runs concurrently on many WinBoard instances.) And what in a (multi-)gauntlet?

I think the head-to-head score of the current playing engines (if possible appended with percentage score for the first player ) should be fine. I see it requires extra work to calculate that as the result stored in one series needs interpretation based on order of play.

[hgm]

I think it is good to sync it. If I remeber my old MFC coding, you can load
all the controls in the dialogue with the trn info when file edit box looses focus
anytime to anyother control. That happens when pressing enter, tab etc..

OK, I had not considered using the loss-of-focus event. But doesn't that come too late? Normally, when you select an existing file, you have no business to click anything other than 'OK', which would close the dialog anyway.

For example, the list of engines is blank even when I have loaded the trn, which could be a little confusing.
Then I can edit any other control knowing I have uptodate data of the trn file.

But editing any other control will almost always be fatal. (Changing the number of participants during a round-robin would completely wreck it, changing the number of games perpairing would as well.) In the best case it would make little sense (like switching the file with start positions or opening lines halfway). So it is exactly what I don't want the user to do.

I guess I could gray out all controls, though, when the user tries to click one of them, and give focus to the OK button.

If the file doesn't exist (like when we are creating a new one), load the default.

I load the settings from the previous tournament, if you already openend a tourney file during that session. That seemed more useful than fixed defaults. If no tourney file was opened yet, you will get the compiled-in defaults, as the otions that go into the tournament file are almost all volatile options. (Exception: number of games per pairing is saved in the settings file as -defaultMatchGames.)

Yes, it puts them all in one line which makes it difficult to delete one of the engines f.i.
It is possible to delete an engine from the tourney that way , right ?
Also I think a list box would be better than a large edit box for the participants list. One raw per engine, to select and delete it.

OK, I will have to look at that. Currently I cleanse what I read from the text-edit from all CR. If I didn't, extra CR end up in the tourney file when I write the value of the -participants argument (i.e. the lines end in CR+CR+LF), and then when you edit such a file suddenly it gets all one line.

But apparently it is essential to put back the CR before writing a multi-line string back to a text-edit.

[MrEdCollins]

To make a match into a tournament, you have to specify a tournament file. You can do that with the Tournament Options dialog. In the remainder of that dialog you can specify the contents of that file if it didn't exist yet. With a tournament file, a match will be conducted as a tournament, according to the specifications in it. Without it, it will just be an old-style match. So I guess the problem was that you had not specified a tournament file.

I also was confused by this, initially. Although I was able to figure it out on my own, I can understand how others might not be so patient.

[hgm]

I uploaded an improved version now:

When you try to OK the tournament dialog without having specified a tournament file, WinBoard will refuse to close the dialog, but in stead pop up an error box, informing the user that he has to provide a tournament file first, to store the progress in. I think that should be enough to prevent any confusion.

In a similar way, I pop up an error box when the user (or an existing tourney file) has not given enough participants for the selected tourney type. (E.g. a multi-gauntlet with 2 gauntlet engines should have at least 3 participants, etc.) Just as a safety check to catch nonsense that might lead to undefined behavior otherwise.

I am still wrestling with the idea to show the contents of an existing tourney file just entered by the user in the dialog. (For tournaments that are already running, it would be displayed automatically, as the contents of the tourney file have become the current WinBoard settings.)

The point is that it is very unnatural to open an existing tournament file with the dialog in the first place. The possibility was intended as a means to resume an interrupted tourney, but the normal way to do that would be to just click on the tournament file of the tourney you wanted to resume, from the Windows explorer. Starting up WinBoard, opening the Tournament Options dialog, typing the file name or browsing to it would be a very round-about way to do the same. So normally yo would only use the dialog for creating new tourney files.

My suspicion is that the wish to do see the contents of a newly entered tourney file in that dialog is mainly driven by the desire to alter that content. But allowing the user to do so, is really asking for trouble. (E.g. other WinBoard instances could actually be playing from that tournament file.) The only legitimate application I could think of is to add a new cycle to a finished tournament. All other controls should be locked.

Now there might be better ways to increase the number of cycles. Currently I pop up an error message when you specify a tournament file of a tourney where al games are finished or already playing. I could make an exception for the case were all games are finished (and none currently playing, so that you can be sure no other WinBoard instance is working on it), and in that case just increment the number of cycles by 1 inside the tourney file, and continue playing from it.

Would this be a good way to solve it?

Note that the user always has the option to start a completely new tournament, with newly specified settings, but using the same PGN file as a previous tournament.

[Michel]

When you try to OK the tournament dialog without having specified a tournament file,

I haven't tried the new xboard yet so I am not sure about the precise interface the new xboard-tm is using.

But is the name of the tournament file really so crucial that it should be supplied by the user? Can't xboard just use some sensible default so that users do not have to deal explicitly with tournament files.

[Daniel Shawul]

My suspicion is that the wish to do see the contents of a newly entered tourney file in that dialog is mainly driven by the desire to alter that content. But allowing the user to do so, is really asking for trouble. (E.g. other WinBoard instances could actually be playing from that tournament file.) The only legitimate application I could think of is to add a new cycle to a finished tournament. All other controls should be locked.

My suspicion is that the wish to do see the contents of a newly entered tourney file in that dialog is mainly driven by the desire to alter that content. But allowing the user to do so, is really asking for trouble. (E.g. other WinBoard instances could actually be playing from that tournament file.) The only legitimate application I could think of is to add a new cycle to a finished tournament. All other controls should be locked.

I forgot a tournament could be run in parallel. This is the first GUI to do so In that case yes it is asking for trouble. So when a user opens an existing trn file show the info from the trn file, but gray out all the controls except the cycle number. He can't delete participants list or anything... Also make sure that he can only increase the cycle not decrease it.

Now there might be better ways to increase the number of cycles. Currently I pop up an error message when you specify a tournament file of a tourney where al games are finished or already playing. I could make an exception for the case were all games are finished (and none currently playing, so that you can be sure no other WinBoard instance is working on it), and in that case just increment the number of cycles by 1 inside the tourney file, and continue playing from it.

Would this be a good way to solve it?

I think it is good to save the user from opening the trn file in notepad. Creating new trn file and editing exiting file (i.e incrementing cycle, and maybe other non-damaging changes too) should be done from the dialog box.

Note that the user always has the option to start a completely new tournament, with newly specified settings, but using the same PGN file as a previous tournament.

I usually store my games in one pgn so it is better to initialize the contents of the dialoge box from previous values as you said.

[hgm]

I haven't tried the new xboard yet so I am not sure about the precise interface the new xboard-tm is using.

But is the name of the tournament file really so crucial that it should be supplied by the user? Can't xboard just use some sensible default so that users do not have to deal explicitly with tournament files.

If you want to resume a tourney that is in progress, the user has to specify the name (or recognize it in the file-browse window), because WinBoard cannot guess which tourney the user wants to resume. And if WinBoard would generate the names, how would the user later recognize them?