All the games in this collection have always defined their graphics

in terms of a constant TILE_SIZE (or equivalent). Here's a
surprisingly small patch which switches this constant into a
run-time variable.

The only observable behaviour change should be on Windows, which
physically does not permit the creation of windows larger than the
screen; if you try to create a puzzle (Net makes this plausible)
large enough to encounter this restriction, the Windows front end
should automatically re-adjust the puzzle's tile size so that it
does fit within the available space.

On GTK, I haven't done this, on the grounds that X _does_ permit
windows larger than the screen, and many X window managers already
provide the means to navigate around such a window. Gareth said he'd
rather navigate around a huge Net window than have it shrunk to fit
on one screen. I'm uncertain that this makes sense for all puzzles -
Pattern in particular strikes me as something that might be better
off shrunk to fit - so I may have to change policy later or make it
configurable.

On OS X, I also haven't done automatic shrinkage to fit on one
screen, largely because I didn't have the courage to address the
question of multiple monitors and what that means for the entire
concept :-)

[originally from svn r5913]

osx.m

@@ -470,7 +470,8 @@ struct frontend {
 	frame.origin.y = 0;
     frame.origin.x = 0;
 
-    midend_size(me, &w, &h);
+    w = h = INT_MAX;
+    midend_size(me, &w, &h, FALSE);
     frame.size.width = w;
     frame.size.height = h;
 
@@ -501,7 +502,8 @@ struct frontend {
      * initWithGame: simply call that one and pass it NULL.
      */
     midend_new_game(me);
-    midend_size(me, &w, &h);
+    w = h = INT_MAX;
+    midend_size(me, &w, &h, FALSE);
     rect.size.width = w;
     rect.size.height = h;
 
@@ -771,7 +773,8 @@ struct frontend {
     NSSize size = {0,0};
     int w, h;
 
-    midend_size(me, &w, &h);
+    w = h = INT_MAX;
+    midend_size(me, &w, &h, FALSE);
     size.width = w;
     size.height = h;