This should make it less annoying for me to do local testing of the JS
output of a build, before I push a change. There's a new
build.out/jstest directory containing .html files suitable for loading
in a local browser, which refer to the JS files via an appropriate
relative path to the existing build.out/js directory.
Commit ef39e6e17 made a goof in which the 'New game' button had no
border on the left and an accidental extra one on the right, which I'm
really not sure how I failed to spot when I tested it yesterday.
The only user to send me a comment today on the new layout said that
that menu item in particular is annoying to have hidden behind more
clicks, so by a vote of one to nothing, it's back out in the open.
This is done by showing a dialog containing an <input type="file">
through which the user can 'upload' a save file - though, of course,
the 'upload' doesn't go to any HTTP server, but only into the mind of
the Javascript running in the same browser.
It would be even nicer to support drag-and-drop as an alternative UI
for getting the save file into the browser, but that isn't critical to
getting the first version of this feature out of the door.
This is done by getting midend_serialise to produce the complete
saved-game file as an in-memory string buffer, and then encoding that
into a data: URI which we provide to the user as a hyperlink in a
dialog box. The hyperlink has the 'download' attribute, which means
clicking on it should automatically offer to save the file, and also
lets me specify a not-too-silly default file name.
I'm about to introduce a few more options, and the button bar is
already a bit wide, so I think I should shrink it horizontally before
putting more stuff on it. So I've organised the options into something
more like the Game and Type submenus that the desktop versions use.
However, I haven't gone quite all the way, on the basis that the web
versions will be at least slightly playable on devices without much
keyboard, which makes it worth keeping the in-play actions (Undo,
Redo, and to a lesser extent Restart and Solve) accessible as
top-level buttons in a single click each.
As part of this change, I've also separated the menu bar into a
drop-down menus section and a top-level buttons section with a gap
between them, and put a signalling "..." on the end of the titles in
the former section.
This change also removes the class="left" on the game-type menu and
its submenus, which were previously there to deal with that menu being
all the way over on the far right of the menu bar. But the CSS for
those classes is still there in jspage.pl, and should still work if I
need it again in future.
The previous control buttons and dropdowns based on form elements were
always a bit ugly: partly in a purely visual sense, and partly because
of the nasty bodge I had to do with splitting the usual 'Custom' game
type menu item into two (to get round the fact that if an element of a
<select> is already selected, browsers won't send an event when it's
re-selected). Also, I'm about to want to introduce hierarchical
submenus in the Type menu, and <select> doesn't support that at all.
So here's a replacement system which does everything by CSS
properties, including the popping-up of menus when the mouse moves
over their parent menu item. (Thanks to the Internet in general for
showing me how that trick is done.)
Based on a web game I saw a few years ago, and dashed off this weekend
after I thought of a way to write a good (though not quite optimal)
heuristic solver, here's a random little thing not quite in the same
line as the most usual kind of Puzzles fare: instead of making you
scratch your head to find any move to make at all, it's easy to find
solutions in principle, and the challenge comes from having to do so
within a move limit.
Rather than design an ersatz 'window frame' surrounding the puzzle
canvas, I've simply overlaid the resize handle on the corner of the
puzzle itself (canvas or status bar, depending on whether the latter
exists), trusting that all games in my collection provide a reasonable
border within their drawing area. (OS X already does this with its
resize handle, so it's not as if there's no precedent.)
Unlike the desktop versions, I control the resize behaviour completely
in this environment, so I can constrain the canvas to only ever be
sensible sizes with no dead space round the edges (and, in particular,
preserve the aspect ratio).
Right-clicking the resize handle will restore the puzzle's default
tile size. I had intended to implement a maximise-to-browser-window
button too, but was annoyingly foiled by scrollbars - if you maximise
to the current window width, and as a result the text below the puzzle
scrolls off the bottom, then a vertical scrollbar appears and eats
into the width you just maximised to. Gah.
[originally from svn r9822]
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]
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]
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]
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]
