Jacob Nevins wrote: > 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.
Yes, I did experiment with this and it didn't seem quite right. However
I thought I'd wait a bit more before updating the bug.
> 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.
I also considered this, but it has the drawback that the window can then
unnecessarily become larger than the screen.
> 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.
Right now I can't understand what this is doing; I'll try to find time
for it later.
> (This no-shrinking policy applies to the unpatched upstream version too;
> perhaps it shouldn't?)
Not sure what you mean by this?
Ben.
--
Ben Hutchings -- [EMAIL PROTECTED] shortened to [EMAIL PROTECTED]
If you've signed my GPG key, please send a signature on and to the new uid.
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.
signature.asc
Description: This is a digitally signed message part
