buttons in several games if STYLUS_BASED is defined: in games where
you can set a puzzle element to 'on', 'off' or 'not yet set', when
it's hard to mimic a second mouse button, it's better to have the
one 'button' cycle between all three states rather than from 'on'
back to 'unset'.
[originally from svn r8784]
compiling gtk.c with STYLUS_BASED defined: most notably, it provides
a row of numeric 'keys' made of GTK button widgets for puzzles that
want a numeric keypad.
[originally from svn r8783]
in r8414 as a side effect of reorganisation in interpret_move().
Reinstate them.
[originally from svn r8692]
[r8414 == 54801998744a69786a49ebe0688942ae7b57525b]
notice that there was an _official_ way to have menu items marked as
selected or unselected, which is the GtkRadioMenuItem class. Replace
my ad-hoc use of bullet characters with that.
[originally from svn r8601]
[r7980 == ae6c7381272f84c0fd398f6d3e496f571ba42ec8]
available, which magically seems to eliminate most if not all of the
update lag when dragging a point in a large (say 250-point)
Untangle. I don't fully understand how this works, but it seems to!
[originally from svn r8600]
on labels in tables. The effect is that if you resize (e.g.) Solo's
configuration panel, the labels to the left of the various input
boxes will remain just big enough to fit their text in, and all the
extra space will be taken up by the useful part, i.e. the input
boxes themselves. Previously the labels and input boxes would expand
in a 1:1 ratio, causing lots of space to the right of the label text
that wasn't used for anything.
[originally from svn r8599]
Loopy mark LINE_NO grid edges with very faint lines, instead of
leaving them totally undrawn. Helps in complex grid types where the
line layout isn't entirely obvious to a player not already familiar
with it. Disableable by setting LOOPY_FAINT_LINES=n in the
environment, just in case anyone turns out to seriously dislike it.
(You could probably disable it via LOOPY_COLOUR_6 too, but you'd
have to know the exact shade of your background to get that right.)
[originally from svn r8597]
merge_some_cages() was written in the assumption that it would
always be able to do something, in that it returned void on success
and if it couldn't find anything to do it would just loop round
forever trying the same things over and over again.
Now it makes a methodical list of the pairs of cages which are merge
candidates, goes through them in a random order until it finds a
viable one, and returns a boolean indicating whether it succeeded or
ran out of candidates.
A test case which previously hung and now does not is "solo
--generate 1 7jxkdt#12345-10".
[originally from svn r8541]
of each digit, and - perhaps more importantly - the display code
wasn't highlighting violations of that rule as an error. Fix both.
[originally from svn r8540]
the 'Killer Sudoku' puzzle type. As a side effect I've had to
increase the default tile size of Solo, so that the extra numbers
drawn in the squares in Killer mode were still legible.
[originally from svn r8455]
ALIGN_VNORMAL is in use: ALIGN_VNORMAL indicates that the supplied
y-coordinate denotes the _baseline_ of the text, not its top, so
adding on 'asc' to convert to the baseline is wrong.
This only affects Tents, at present.
[originally from svn r8452]
structure in every game_state is terribly wasteful. Move all the
constant bits of it (i.e. everything except the per-square 'blue'
flag) into a ref-counted shared structure.
[originally from svn r8444]
of 'h' and 'm' are treated as digits if a square is selected, and
only treated as special commands otherwise. This renders very large
games (just about) playable.
Idea from Ben Hutchings's collection of Debian patches, although I
had to redo his (trivial) patch myself since the code has changed
recently.
(Addendum after committing: hmm, I see Jacob already applied the
original version of the patch a while back. Looks as if the recent
keyboard control change reintroduced the problem. Still, re-fixed
now.)
[originally from svn r8433]
using PANGO_CHECK_VERSION. (Irritatingly, the latter is not
available in all versions of Pango, so we have to be cautious about
using it at all. *sigh*)
[originally from svn r8430]
