Ben Hutchings writes:
> I think what should happen when you change the type is that the puzzle
> compares the current window size with the desired window size and
> requests a resize only if the current size is too small. Does that seem
> reasonable?
I don't think that's quite right; if a puzzle is (say) 3x3, but the user
then changes to 2x2, this would expand the 2x2 puzzle to fill the space
used by the 3x3 one.
I think a better approach would be for the internal 'tilesize' parameter
to be remembered across game grid size changes, so that the individual
game features stay at the user's requested size.
The attached patch against the upstream version illustrates this, but it
needs some work; as it stands, if the tile size is enlarged and then a
new game grid size is selected, the tile size cannot be reduced again.
(This no-shrinking policy applies to the unpatched upstream version too;
perhaps it shouldn't?)
Index: midend.c
===================================================================
--- midend.c (revision 6776)
+++ midend.c (working copy)
@@ -124,7 +124,7 @@
me->laststatus = NULL;
me->timing = FALSE;
me->elapsed = 0.0F;
- me->tilesize = me->winwidth = me->winheight = 0;
+ me->winwidth = me->winheight = 0;
if (drapi)
me->drawing = drawing_new(drapi, me, drhandle);
else
@@ -149,6 +149,7 @@
if ((e = getenv(buf)) != NULL && sscanf(e, "%d", &ts) == 1 && ts > 0)
me->preferred_tilesize = ts;
}
+ me->tilesize = me->preferred_tilesize;
sfree(randseed);
@@ -241,7 +242,7 @@
me->ourgame->compute_size(me->params, max, &rx, &ry);
} while (rx <= *x && ry <= *y);
} else
- max = me->preferred_tilesize + 1;
+ max = me->tilesize + 1;
min = 1;
/*
