Highlight clues of value n in Towers if its row/column contains an
increasing sequence of length n, the last number of which is not equal
to the number of rows/columns (i.e. such that the sequence will have
to be extended, in violation of the clue).
Commit 8b491946e had a bug: configure_area stopped doing most of its
work if the new size already matched fe->w and fe->h, but in fact the
GTK2 resize_fe() _already_ set up fe->w and fe->h for the new size. I
managed not to notice, because I checked it all worked on GTK 3 but
only tested resizing to a _smaller_ puzzle on GTK 2. Ahem.
Now we don't change fe->w and fe->h at all until configure_area is
called. Also, we initialise them to dummy values at setup time, so
that configure_area won't compare the new size with uninitialised
data.
Draw pencil-mode cursor before corners of thick lines in order to make
the thick lines appear on top of the north-west corner of the pencil
cursor, just like they do with the non-pencil cursor.
Keyboard dragging while holding Control now moves the cursor to the
target square. Shift-Control-arrowkey performs the previous behavior
of Control-arrowkey.
Its absence was breaking the icon build on Ubuntu 14.04, because you
ask convert to map an image into a specific 16-colour palette, and it
does so and _then_ nonconsensually maps those colours in turn through
a colourspace transformation you didn't ask for, causing icon.pl to
fail an assertion when it finds an RGB value not in the palette.
I think I did this in GTK2 on the basis that our server-side cache
pixmap was double-buffering enough for us - any puzzle which erased a
big area with a background rectangle and then redrew over the top of
it would do so only on the off-screen pixmap, and the updates would
only be copied to the visible window after it was all done.
In GTK3, I don't think there's any need - this is all the usual way
things are done anyway, as far as I can see. So I've turned this call
back off, at least until I hear of a reason why I need it again.
In GTK 2, we had a big pile of horrible code to deal with the fact
that it's very hard to open a window in such a way as to make it easy
to resize smaller as well as bigger.
Essentially, we'd open the window with the drawing area's minimum size
request set to the desired _initial_ window size; then we'd wait until
GTK had finished creating other window components (menu bar, status
line) and the window's size allocation had settled down, and finally
reduce the size request to the real minimum size so that now the
window was resizable in both directions. This also involved some
deliberate checking of the Ubuntu Unity GTK extension which steals the
menu bar and put it elsewhere (see commit 8f8333a35), to avoid us
waiting forever for a menu bar that wasn't going to show up.
But in GTK3, this has all become actually sensible! All we now have to
do is to set the window's geometry hints to indicate the drawing area
itself as the base widget (probably a good plan anyway), and then we
can set the initial size using gtk_window_set_default_geometry() and
resize it later using gtk_window_resize_to_geometry(). So now we can
completely condition out all of the previous horrors, and consider
them to be legacy GTK2 compatibility code only. Phew.
