Re: [Bug-gnubg] Tutor mode for resignations?

[Christian Anthon]

On Mon, Dec 15, 2008 at 7:05 PM, Joseph Heled <address@hidden> wrote:
> Since I do a lot of resigning when playing against the damn lucky son
> of of the gun, I find the resign functionally only a shade above
> 'fail'.
>

There are some things that you just get used to, but I guess you are right.

> First - the button disable/enable is highly annoying. I have to move
> the cursor out and in again of the button if I moved too quickly.  It
> would be heaps better if gnubg could allow a press any time - but wait
> with the response until the appropriate time if in the middle of a
> move etc (It might be hard, but it is only a GUI problem).
>

If I'm following you correctly here, I believe your complaint is that
the gui is sort of locked during computer moves. The problem was that
we had some possible race conditions if people did gui things out of
turn/order. The problem here is a missing clean separation of the gui,
the essentially underlying text interface, and the "game as such". It
would take a lot of work to get really right in the code, but perhaps
we are errering on the side of precaution in locking the interface as
we do now.

> Second, gnubg should automatically offer the "right" level of resign
> as a default, and an appropriate warning if you resign at a level
> higher than necessary.
>

That is not a bad idea. We could simply check if a resign at some
level is correct and auto-resign or pop a dialog as appropriate.

> Third, I should not have to click throu popups if I don't want to.
> This should be user configurable.
>

The messages in gnubg are like shit spread with a shovel. We have two
normal ways to generate output in the text interface (stdout and
stderr), and in particular those that go to stdout are ranging from
below debug to above error level. In the gui we display the stderr
messages immediately, while the stdout messages are collected and
displayed sometime between the current and the next move. And to add
to the problem, short messages go the status bar where they may be
overwritten before the user ever sees them, and they are not very
visible when they are really important.

And that is the underlying reason for these sometimes silly dialogs we
get. So again at least some work to get right, but perhaps we should
fix the more common messages.

> There might be more but if we improve those it will be heaps nicer to
> play against.
>

I'm sure there is :) and in this regard I wish that people used
savannah more for well defined wishes, as the mailing list isn't
exactly the easiest way for us to keep track of things.

Christian.