Re: [Bug-gnubg] Tutor mode patches for gnubg

[Jim Segrave]

On Wed 24 Jul 2002 (16:23 +0000), Joern Thyssen wrote:
> On Tue, Jul 23, 2002 at 09:29:50PM +0200, Jim Segrave wrote
> 
> > I originally included a gdk_beep as well, but removed it, because, as a
> > matter of personal taste, I dislike noisy programs.
> 
> We can introduce a fBeepTutor (similar to fBeepIllegal).
> 
> > Evaluations are done using the same code as hint, so a user who has a
> > significant difference between their analysis and evaluation settings
> > may get warnings which don't show up in a post-mortem or not get
> > warnings for play which is flagged in post-mortems.
> 
> I think it's vice-versa: tutor-mode uses AnalyseMove which uses
> esAnalysisCube and esAnalysisChequer, whereas hint and eval uses esEval.

You're right.
 
> So tutor mode may flag a move as bad, but the hint dialog may say that
> you're making the correct move (that actually happened to me).

And me as well. And, before I fixed it to not evaluate gnubg's
doubling decisions, gnubg itself got a popup query for a drop :-)

> I see no problem in that. Although it might be better to use the
> evaluation settings instead of the analysis settings?
 
Maybe that should be a choice - if I (or someone) adds some frills to
selecting this mode, then one option could be to select which one to
use. I ended up using AnalyzeMove because it was easy for me to see
what I needed to hook this code in. I assume that I should be able to
find what I need in CommandHint or the routines it calls as well.

> > Another possibility, again less intrusive than a pop-up window, would
> > be to add a region to the board itself for the response buttons (in
> > the same way that the take/pass buttons only appear when the player is
> > doubled). 
> 
> Personally, I think the pop-up is fine. Of course, I play
> near-perfect, so it doesn't seem that intrusive *cough cough* :-)

I can do that if I adjust the Skill thresholds settings far enough :-)
Doubtful=>.2 does wonders for reducing the nagging.

> > This might be better, but a) I did not fancy playing with
> > the code in gtkboard.c and b) I admit that I'm still not clear how the
> > board makes the buttons appear and disappear (gtk_widget_hide () of
> > the button box is not it, the board would be re-sizing if you do
> > that).
> 
> It uses some GtkHButtons: takedrop, rolldouble, agreedecline, and
> play. Check board_size_allocate, I think it does the magic. 
> 
> I think you could add a new GtkHButtons tutormodechequer, tutormodecube
> etc, and just copy the magic in board_size_allocate and update_buttons.

I'm open to suggestions as to whether or not it should be on the
board, but the more I think about it, the more I prefer a popup. I use
a laptop with a 1024x768 screen. I lke to get the board as large as
possible, so any border area reserved for buttons etc. is a
limitation. I was surprised to find that I missed fewer obvious plays
when I maximise the display. But I guess it would reuse the area that
the Take/Drop buttons use, so maybe this is a non-issue.

> > Perhaps it should allow the user to select the level at which it
> > issues warnings (so that it wouldn't interrupt play for a 'doubtful
> > move', only a 'bad' or 'very bad' play.
> 
> I agree.

It's easy to do, it mostly complicates the Settings menu itself. But
there's lots of samples of what's needed I can use.

> > It might be desireable to allow separate selection of which types of
> > play get watched - chequer or cube, possibly chequer, doubling and
> > responses to doubling.
> 
> I agree.

OK - I'll look at what I can do to allow setting the skill level and
which types of play to evaluate. It may be a week or two though. So if
anyone else wants to do it, feel free.
 
> I've only a played a few games with tutor mode, and I must admit I
> really like it.  Thank you very much for the patch! I'll take the
> liberty to commit the code to the CVS repository (and remove the auto
> analysis).

It's hardly taking a liberty.  Also please look at the other report
about DestroyHint() doing frees of NULL pointers - this is not an
artefact of the tutor mode changes.


-- 
Jim Segrave           address@hidden