inside the top-level display:none puzzle container as a side effect of
r9809.
Also, while I'm at it, reword the apology to mention typed arrays as
the most likely cause of failure (AFAIK that's the most modern feature
required by the JS front end), and fix indecision between singular and
plural ('this puzzle' doesn't work, perhaps a feature 'they depend on'
is missing).
[originally from svn r9818]
[r9809 == 5dc559c8be1b8f6ed15f560433f25c952c874f93]
the game-type <select>, since IE turns out to ignore display:none on
options. Oh well.
Instead I now do a more transparent thing: when custom game params are
in use, there's a "Custom" option selected in the dropdown, and a
separate 'Re-customise' option which brings the config box back up.
When an ordinary preset is selected, the Custom option is missing, and
there's just a 'Customise'.
In the process I've tinkered a bit to arrange that the custom 'preset'
is always represented by a negative number rather than one past the
last real preset; that seems more consistent overall.
[originally from svn r9811]
Unlike Firefox, IE and Chrome don't generate keypress events at all if
you suppress the default handling of keydowns. Therefore, we have to
figure out everything from the keydown event, because if we unsuppress
the default handling of any keydowns then we'll get annoyances like ^R
going back to meaning reload-page rather than redo-move.
[originally from svn r9810]
added a trivial doctype (IE complained without it), but that caused a
gap to appear between the puzzle and the status bar, so I tinkered a
bit more and ended up removing the <table> completely (no great loss)
as well as adding display:block to the canvas and explicitly setting
the width of not only the status bar div but also its parent div.
Meanwhile, I'm putting the "px" on the end of a lot of properties I
set from JS, because IE complains about that too if I don't.
[originally from svn r9809]
the return value of relative_mouse_coords! I only got away with that
error because the canvas was at offset zero compared to its immediate
parent element.
[originally from svn r9808]
when the user pressed 'n' for a new game, because all the front end
knows is that it passed a keystroke to the puzzle, and it has no way
of hearing back that a particular keypress resulted in a game id
change.
To fix this, I've renamed midend_request_desc_changes to
midend_request_id_changes and expanded its remit to cover _any_ change
to the game ids. So now that callback in the Emscripten front end is
the only place from which update_permalinks is called (apart from
initialising them at setup time), and that should handle everything.
[originally from svn r9805]
didn't like them, which doesn't matter as such since they won't run
these JS puzzles anyway (no TypedArray support) but it hints that
other JS implementations might be picky about this too.
[originally from svn r9804]
mention that the HTML pages generated by html/jspage.pl are also an
integral part of this front end. (The NestedVM frontend is more
self-contained, needing only an appropriate <applet> tag, but this one
expects quite a few components to exist on the page and have the right
ids.)
[originally from svn r9803]
puzzle startup. The puzzle web pages now enclose the whole puzzle
(buttons, canvas, permalinks) in a div set to display:none, and
instead display an apologetic message saying 'sorry, it didn't work';
then, if we get through the whole init function without crashing, we
show the puzzle and hide the apology.
[originally from svn r9802]
The previous version dealt adequately with rectangles _partially_
overlapping the edge of the canvas, but doesn't correctly handle a
rectangle that's completely out of bounds in one direction. Replace
with a complete rewrite which is more easily seen to be correct. Also,
while I'm at it, add a missing condition to draw_update() so that we
don't even bother calling the Javascript half of it on any rectangle
that's been trimmed into nonexistence.
[originally from svn r9800]
with a trailing "..." to hint that it opens a further dialog box.
However, the _invisible_ Custom option is merely indicating what you
_do_ have selected, so we leave that one as it is. (So now they're no
longer exact twins of each other, of course.)
[originally from svn r9796]
rectangle, which showed up on the Javascript front end since the JS
canvas doesn't start out defaulting to COL_BACKGROUND. Fixed it to
draw_update to the edge of its area, and while I'm at it, narrowed the
border (since this proves we didn't really need that much space
anyway).
[originally from svn r9795]
selected. Previously we were leaving the first element on the list
selected, which is _usually_ right, but not right for Slant.
In the process of doing this, I've also reorganised to fix a crash
which shows up with non-configurable games (admittedly currently only
Nullgame :-) when we still try to call js_select_preset in spite of
not having any preset options to select.
[originally from svn r9794]
can trigger a call to a front end notification function. Use this to
update the game ID permalink when Mines supersedes its game ID.
[originally from svn r9793]
as "1" rather than "round". Must have had my Postscript brain in,
and/or been confused by lineWidth = "1" just beforehand. This fixes a
display glitch in Towers, where there's a tiny spike at the top left
corner of each tower due to a very sharp mitred line join.
[originally from svn r9791]
Javascript-side blitter creation function had forgotten to return the
new blitter's id, so the C code was still trying to use blitter #0
after it had been thrown away and replaced.
[originally from svn r9790]
type dropdown, we still get an 'onchange' event if they select it a
second time. Normally this wouldn't happen, because onchange means
what it says and we only get it if a _different_ element is selected.
My solution is to create two list items called Custom, set one of them
as display:none to stop it showing up when the list is dropped down,
and to select it after the configuration box closes.
[originally from svn r9788]
applets, here's an alternative webification in Javascript, using
Emscripten in asm.js mode (so that as browsers incorporate asm.js
optimisation, the game generation should run really fast).
[originally from svn r9781]
web pages for the Java applets. Previously, those have all been
maintained by hand in my website's svn area, which is a bit silly. Now
we have a file per puzzle in the 'html' subdirectory which contains
the puzzle's name, one or two attributes, and the instructions snippet
to go below the puzzle applet; and then there's a Perl script that
builds all the real web pages out of that by adding in the parts
common across all files: the header, footer, and middle fragment with
the <applet> tag and resizing bits and pieces.
One piece _not_ checked in here is the footer text specific to my
hosting at chiark, which I think does still belong in the www area. So
Buildscr doesn't actually build the web pages; it just delivers the
bits and pieces by which my nightly snapshot script will be able to
run the program that _does_ build them, passing that footer as an
extra argument.
[originally from svn r9780]
fix in r9777 when I added documentation of the function it wistfully
imagined might one day exist.
[originally from svn r9779]
[r9777 == 1fdafb6abf2d3ea0d37e79b5dfd9daf8eed28f22]
(If you're going to memset a struct to 0 before filling in the fields
you care about, do use sizeof the struct rather than sizeof the
pointer; but also, if you're filling in _every_ field, there's no need
to bother anyway.)
[originally from svn r9773]
sprintf in both locations (screen and print) that need it. Fixes a bug
in which clues greater than 9 came out as hex digits in printed
puzzles.
[originally from svn r9765]
conditionalised on !ds->started, so that we still do all the looping
over everything even if we know it's all going to be redrawn. This is
because deciding how much needs redrawing is not the only important
thing in those loops - they also set up arrays like ds->clue_error,
which tell the individual redraw functions _what_ to draw.
Fixes a bug in which, if you start a Loopy game and make moves causing
a clue to light up red for an error and then save your game, loading
the same save file at the start of a Loopy run would fail to highlight
the erroneous clue.
(This commit diff looks large, but actually it changes almost nothing
but whitespace.)
[originally from svn r9751]
the 'completed' flag is not reset if you make a new move transforming
a solved game into an unsolved state, so the game won't flash again if
you manually erase and redraw a line segment (though it still will if
you undo and redo past the first solved state in the undo history).
[originally from svn r9750]
The Windows puzzles now accept similar command-line syntax to the GTK
ones, in that you can give them either a game ID (descriptive, random
or just plain params) or the name of a save file. Unlike the GTK ones,
however, the save file interpretation is tried first; this is because
some puzzles (e.g. Black Box) will interpret any old string as a valid
(if boring) game ID, and unlike the GTK puzzles it's not feasible to
require users to disambiguate via a command-line option, because on
Windows a thing that might easily happen is that a user passes a save
file to a puzzle binary via 'Open With' in the GUI shell, where they
don't get the chance to add extra options.
In order to make this work sensibly in the all-in-one Windows app, I
had to get round to another thing I've been planning to do for a
while, which is to write a function to examine a saved game file and
find out which puzzle it's for. So the combined Windows binary will
auto-switch to the right game if you pass a save file on its command
line, and also if you use Load while the program is running.
Another utility function I needed is one to split the WinMain single
command line string into argv. For this I've imported a copy of
split_into_argv() from Windows PuTTY (which doesn't affect this
package's list of copyright holders, since that function was all my
own code anyway).
[originally from svn r9749]
draw_numbers() was considerably confused between the width of the clue
border at the left and the height of the clue border at the top.
Unconfuse it (I think).
[originally from svn r9737]
bombing out due to an option that we don't recognise but GTK will.
Somehow my basically workable plan had been completely nullified by
putting the error check in the wrong place.
[originally from svn r9733]
gtk_widget_get_allocation conditional on GTK being new enough to have
that function.
I'm assuming until someone proves otherwise that if it isn't that new,
then it also isn't one of the versions of GTK which exhibit the bug
which that call was working around (since gtk_widget_get_allocation
came in 2.18, and the problem seems to have arisen since 2.20).
[originally from svn r9712]
Ubuntu 12.04 machine. What seems to happen is that we set up a window
containing a menu bar, a drawing area and a status bar, and set the
size of the drawing area; then the window is displayed _without_ the
menu bar; then we reduce the drawing area's size request to (1,1) to
let the user resize the window smaller; and now GTK gets round to
constructing the menu bar, and the drawing area helpfully shrinks a
bit to make room for it.
My fix is to set a 'shrink pending' flag instead of shrinking the
drawing area's size request, and defer the actual shrink operation
until the menu bar and status bar are both present.
[originally from svn r9711]
