Martin wrote:
> > > Open issues:
> > > - No visual feed-back to the user that the engine is scoring. Opening a
> > > small dialog box would be nice, as it may take some seconds.
> >
> > I will delay this patch until after 0.1.5 anyway. You have time to
> > improve ;)
>
> Good. I haven't worked with Gtk too much yet, so I wanted to report in
> before I get lost in it for too long.
Well, there doesn't seem to be lot's of GTK+ in your patch yet.
> >
> > > - If Quarry is used to have two gtp clients play against each other,
> > > only black is asked to score.
> >
> > This should be fixed, yes.
>
> Proposed behaviour:
> If there are two gtp clients, have them both score. If they agree,
> that's the final score, no user interaction needed (not even possible?).
> If they disagree, inform user about which stones/strings are disputed
> and have him decide.
>
> Agree?
In the long run I think it will look like this: whenever a game is finished,
a dialog with results appear. In the dialog there will be several buttons
for instance to save the game. Also, for Go games there should be a button
to rescore the game. If the two engines disagree, the user is notified and
scoring mode is turned on. If they agree, results are reported, but the
user can still rescore if he wants to, by pressing the button.
But don't bother with this now. If you unconditionally force the goban
window into scoring mode after automatic score is finished, that's fine.
We'll improve later.
> > > +static int
> > > +parse_final_status_list(GtpClient *client, int successful,
> > > + GtpClientUserCallbackData *callback_data)
> > > +{
> > > + StringListItem *this_item;
> > > + int idx = 0;
> > > +
> > > + GtpClientFinalStatusListCallback final_status_list_callback
> > > + = (GtpClientFinalStatusListCallback)
> > > callback_data->response_callback;
> > > +
> > > + BoardPositionList *stones
> > > + =
> > > board_position_list_new_empty(string_list_count(&client->response));
> >
> > I believe output of `final_status_list' can come with several stones
> > per line. Unless I missed something, your code expects only one stone
> > per line. This must be fixed. The easiest way is probably to allocate
> > large `PositionList' from the start.
>
> Ah, after reading the GTP specification on final_status_list the n'th
> time, I finally got it. In each line, there is a list of stones
> belonging to one string. Right now, engine_has_scored marks entire
> strings - that's why it works, but it's admittedly not very nice and
> I'll change it.
I reread the specification and it seems you are correct. However, I
think in this case you can leave the things as they are (dropping a
`FIXME' there of course). Detecting engine's bugs is not of high
priority and we can assume that marking full strings by whatever stone
comes first in a line will give the same result as proper parsing.
Paul
