| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The mouseup listener was calling event.preventDefault(), as part of
the mechanism for making mouse clicks and drags on the puzzle's resize
handle have resizing effects _instead_ of the normal browser
behaviour. However, calling event.preventDefault() on _every_ mouseup,
rather than just the ones associated with the resize handle, was
overkill, and I've recently noticed that it's breaking attempts to
select from the game type dropdown by clicking the mouse. So now I'm
only calling preventDefault() on the mouseups that I have reason to
think are actually relevant to what I'm trying to do.
(I don't know why I've only just noticed this. I suppose a change of
behaviour between Firefox versions is the most likely cause.)
|
| |
|
|
|
|
|
|
|
|
|
| |
I've just upgraded to emcc 1.16.0, in which something fiddly has
happened to the semantics of Module.run() vs noInitialRun - now
setting the latter seems to cause the former to do everything except
calling main(), and then refuse to ever do anything again. So now I
have to use Module.callMain() in place of Module.run() when I finally
do get round to wanting to call main().
[originally from svn r10180]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
| |
returns an element's absolute position on the web page is split out
into a subfunction that can be called directly.
[originally from svn r9819]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
| |
click, so manually implement that behaviour. (Without it, it's quite
hard to focus the canvas at all in IE.)
[originally from svn r9806]
|
| |
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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]
|
