Add short randomized delay to problem widget type (possible enhancement)

[dormerod]

Existing software for solving go problems usually responds to the user's moves instantly. I think this can be demoralizing for the user, especially newbies, and can make some people feel rushed to click more quickly.

Consider adding a short randomized delay when displaying the response from the problem file, to make the experience more similar to playing a human. While humans feeling insulted or pressured by computers may be irrational, that doesn't mean it doesn't happen.

[sartak]

Even just a few hundred milliseconds of delay would really improve the feedback. Having no delay (and no audible feedback) means that problems involving capture (especially throw-in) can be confusing, as the instant response makes it seem like you played in the wrong spot... with the wrong color... :)

[artasparks]

I'm not sure I want to add in a default delay, but it seems reasonable. The question is about the right way to do this.

I could easily add in a delay option, but perhaps a bettor way is a general catalogue of handlers? if you hand handlers for pre-problem-load and post-problem-load then you could solve this problem generally.

Another similar case that you bring up: What about adding sounds?

I still may end up adding the delay option since it's easy, but it's worth spending some time to think about this. I don't want the options in Glift to grow unbounded.

[sartak]

I was able to hack in playing a sound on play by passing a copy/paste of the default implementation of stoneClick, but adding a few lines for dealing with Audio. Another hook there or somewhere nearby for "played stone" would eliminate that ugliness.

If there's a straightforward way to add a delay with an existing (or new) hook, I'm certainly willing to use it instead of asking for a delay option, but I struggled with how to implement it in the code as it exists today.