aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* kaios/manifest.pl: canonicalise the JSON output.Simon Tatham2023-01-21
| | | | | | | | | | | The default behaviour of JSON::PP's encode_json output is to write the keys of a hash in Perl's natural hash order, which isn't consistent between runs of the same script due to hash function randomisation. This causes my build system to complain when successive builds from the same source revision don't produce the same output. Easily fixed: JSON::PP already has a switch to ensure consistent ordering, it's just a matter of finding it and turning it on.
* Install KaiOS app docs even without HalibutBen Harris2023-01-20
| | | | | | | Rather than installing the documentation only when Halibut is available, install the documentation whenever it exists. This allows for the way that Buildscr injects the documentation into official KaiOS builds.
* Use the main Web site version of the docs for KaiOS appsBen Harris2023-01-19
| | | | | | | | | | | | | | Simon's build infrastructure doesn't have Halibut available on the same system as Emscripten, which means that the normal KaiOS build can't build the documentation. At present, though, the version of the documentation that's built for the Web page is perfectly acceptable for KaiOS as well, so we may as well seed the KaiOS build directory with that. This is slightly unfortunate because it means that it's difficult to make changes only to the KaiOS documentation, and I'd like to be able to do that eventually. We can cross that bridge once Halibut has the features I want.
* kaios: Add hooks for the KaiAds APIBen Harris2023-01-19
| | | | | | | | | | | The Kai Store makes display of advertisements provided by the KaiAds API mandatory. I don't want such adverts to be inconvenient for the users, so I've just gone for adding a menu item that will display one. This is probably a little too crude, but it's good for testing things. The actual KaiAds API code is not free software, so it's not included here. My intention is to add it by hand to the Zip files for Kai Store uploads. Without it, the advertising code does nothing.
* js: Quicker keyboard access to menu itemsBen Harris2023-01-19
| | | | | | Now pressing "1" to "9" or "0" activate the first ten items of the current menu, to save so much pressing of the arrow keys. There isn't any visible indication of this, so it's a bit of an Easter egg.
* kaios: Make F10 open and close the menuBen Harris2023-01-19
| | | | | | This is no use on KaiOS itself, but provides a way to open the menu from the keyboard on desktop browsers for testing (and for keyboard-accessibility in general).
* Correct type of "locales" in KaiOS manifestBen Harris2023-01-19
| | | | It should be an object, not an array.
* Deliver banner images from build scriptBen Harris2023-01-19
|
* Generate a possibly suitable marketing banner for the KaiStoreBen Harris2023-01-19
| | | | | | | | It wants a 240x130 pixel JPEG. I've gone for rotating the screenshot a bit because the store overlays text on the picture and I don't want horizontal lines in the picture confusing the text. I think the store handles dimming the image, so the picture we produce is at full brightness.
* kaios: Provide a populated "locales" field in the manifestBen Harris2023-01-19
| | | | | | The documentation says it's only needed to override values in the main manifest, but it's apparently required even if you only support one locale.
* kaios: Turn off :hover highlighting in menusBen Harris2023-01-19
| | | | | | Even when the virtual pointer is hidden in KaiOS, it still causes :hover on whatever element is nominally under it, which is confusing. Disable all the :hover effects as a workaround.
* Buildscr bits for making KaiOS buildsBen Harris2023-01-19
| | | | | These are currently treated as just another JavaScript build, so they don't have their own variable to turn them off.
* kaios: Put version numbers in manifest filesBen Harris2023-01-19
| | | | | | | | | This only happens if something edits manifest.pl to provide a version number, but Buildscr can do that. KaiOS manifests are documented as requiring dotted-decimal version numbers. In fact, the restrictions are much stricter than that, and unacceptable version numbers can break the KaiStore developer portal. YY.MM.DD version numbers seem to be acceptable.
* kaios: Hack out everything that needs dialogue boxesBen Harris2023-01-19
| | | | | | | | | | | | | They're proving to be a right nuisance and will probably require a substantial overhaul to how they work across the entire JavaScript front-end. I don't think any of the functionality provided by the dialogue boxes is critical, so in the interests of getting a minimum viable product actually released I've disabled those features. In most cases, this just involves commenting out bits of HTML. The "Custom..." menu item is added by C code, though, so there I've fallen back to the standard Puzzles way to implement a nasty hack: an environment variable.
* js: Remove an outdated reference to the "invisible Custom option"Ben Harris2023-01-19
|
* js: Tolerate the absence of various UI elements from the HTMLBen Harris2023-01-19
| | | | | To make things more consistent, the static buttons now all have their own variables.
* js: Look up elements in the DOM as early as possibleBen Harris2023-01-19
| | | | | | | | | | | | Now that our script is loaded using <script defer>, we can rely on the DOM's being complete as soon as it starts running. So when we declare a variable to point to a DOM element, we can initialise it with that element. This saves having these odd initialisations scattered around the code, usually but not always at the site of first use. I'd like to be able to do the same thing with the variables that point to C functions, but the Module.cwrap() call isn't entirely safe before Emscripten has finished loading the C code.
* js: Simpler and more robust startup procedureBen Harris2023-01-19
| | | | | | | | | | | | | | | Previously, we initialised all of the JavaScript event handlers as soon at the DOM was loaded, and then called main() ourselves once the Emscripten runtime was ready. This was slightly dangerous since it depended on none of those event handlers' being called before main(). In practice this was difficult because most of the elements the event handlers were attached to were invisible, but it did limit what event handlers could safely be used. Now, the event handlers are initialised from main(). This makes things work in a sufficiently conventional way that we can just let the Emscripten run-time call main() in its usual way, rather than involving ourselves in the minutiae of Emscripten's startup.
* js: Use current_key_label() to label feature phone softkeysBen Harris2023-01-19
|
* js: Rename update_undo_redo() as post_move()Ben Harris2023-01-19
| | | | I want to do more things with it.
* js: Make soft-key labels generate key events when clickedBen Harris2023-01-19
| | | | | This makes the app page a little easier to test on desktop browsers that don't have SoftLeft and SoftRight keys.
* kaios: Major parts of a build for KaiOSBen Harris2023-01-19
| | | | | | | | | | | | | | | | | | | | | | | | | | KaiOS (which is based on Firefox OS, formerly Boot to Gecko) runs its "native" apps in a Web browser, so this is essentially a rather specialised version of the JavaScript front-end. Indeed, the JavaScript and C parts are the same as the Web version. There are three major parts that are specific to the KaiOS build. First, there's manifest.pl, which generates a KaiOS-specific JSON manifest describing each puzzle. Second, there's a new HTML page generator, apppage.pl, that generates an HTML page that is much less like a Web page, and much more like an application, than the one generated by jspage.pl. It expects to build a single HTML page at a time and gets all its limited knowledge of the environment from its command line. This makes it gratuitously different from jspage.pl and javapage.pl, but makes it easier to run from the build system. And finally, there's the CMake glue that assembles the necessary parts for each application in a directory. This includes the manifest, the HTML, the JavaScript, the KaiOS-specific icons (generated as part of the GTK build) and a copy of the HTML documentation. The directory is assembled using CMake's install() function, and can be installed on a KaiOS device using the developer tools.
* Properly-styled icons for KaiOSBen Harris2023-01-19
| | | | | | | These are built alongside other icons as part of the GTK build. It builds new icon sizes of 44 and 88 pixels and then uses ImageMagick to round off the corners and add a shadow in accordance with the KaiOS design guide.
* js: Have the "SoftRight" key open the menu by focussing itBen Harris2023-01-19
|
* Allow repeated "solve" operations in GuessBen Harris2023-01-19
| | | | | | | | | | | | Since using the "solve" option doesn't consume a guess, it's safe to allow it to occur multiple times. Without this, selecting "solve" a second time causes an assertion failure because solve() returns a move string that's rejected by execute_move(). Possible solve() could instead refuse to solve an already-solved puzzle, but that seems needlessly pedantic. [fixes c84af670b52f09e9e47587584c0559c508d4a37d]
* Tracks: tighten up the 'illegal solve submoves' fix.Simon Tatham2023-01-19
| | | | | | | | | | Chris mentioned in the commit message that there was a risk that illegal moves might be permitted when playing on after a solve. So I've changed the condition so that it depends only on whether the move _currently being executed_ is a solve, rather than whether there was a solve action anywhere in the undo history. (Also, wrapped overlong lines while I was here.)
* Tracks: let solve make illegal movesChris Boyle2023-01-19
| | | | | | | | | | | | | | | | | Not only does it set the outer edges to NOTRACK, but it may also overwrite any mistakes the user has previously made elsewhere. Otherwise, the entire solve is rejected ("Solve unavailable" error on Android) if the user has made a single mistake, which is inconsistent with the other games. This may be giving a free pass to corrupted moves that occur after a solve, so this may still want tightening up in some way, but it's still limited to squares within the grid, so I agree with Ben's assessment that this is likely not to be exploitable. Fixes #584 (cherry picked from Android port, commit 33bd14fb6f7cd760e7218fffd90f3a266b1f4123)
* Fix mosaic's validate_desc: 9 is validChris Boyle2023-01-17
| | | | | | This rejected valid games that include a '9' clue. Fixes Android issue #582.
* Avoid unnecessary timestamp bumps on generated-games.h.Simon Tatham2023-01-17
| | | | | | | | | | | | | | | | | | | | | If I re-run cmake in a Unix build directory, it unconditionally rewrites generated-games.h, which causes fuzzpuzz to be rebuilt. This is a waste of effort in the extremely common case where the rewritten generated-games.h is identical to the old one. Now we write the data to a temporary file first, and use cmake's 'configure_file' command to copy that to generated-games.h, because it so happens that configure_file checks if the two files are identical and avoids updating the timestamp on the destination file if so. (This will presumably also be a beneficial change on any other platform that uses generated_games.h in the build, such as OS X. I just hadn't noticed until it hit the build I most often re-run in an existing build directory.) cmake 3.21 has a more intuitively spelled command I could have used, called 'file(COPY_FILE src dst ONLY_IF_DIFFERENT)'. But we currently permit cmake all the way back to 3.5, so I can't use that.
* Fix memory leak in convert_tilesizeBen Hutchings2023-01-16
| | | | | | If old_dpr == new_dpr, convert_tilesize returns early without freeing defaults. Move the initialisation of defaults after this special case.
* Fix use-after-free in fuzzpuzzBen Harris2023-01-16
| | | | | | | | | | | | When reporting that the game name in a save file isn't recognised, don't include the name from the save file in the error message, partly to avoid the complexity of freeing it properly on two different code paths and partly because including unsanitized data from a fuzzer-supplied save file in the error message just seems dangerous. And properly sanitising it would waste the fuzzer's time exploring the sanitising code. Thanks to Ben Hutchings for reporting the bug.
* Correct syntax of fuzzpuzz.dictBen Harris2023-01-15
|
* Tracks: make sure moves are valid in execute_move()Ben Harris2023-01-15
| | | | | | | | | | Tracks allowed moves in execute_move() that shouldn't have been allowed, like changing the state of the edges of the board. This moves couldn't be generated by interpret_move(), but could be loaded from a save file. Now execute_move() uses the same ui_can_flip_*() functions as interpret_move() to decide whether a particular move is allowed. This should prevent some assertion failures when loading corrupted save files.
* Towers: reject descriptions with odd characters at the endBen Harris2023-01-15
| | | | | | | | | Towers' new_game() causes an assertion failure on game description strings that contain spurious characters after a valid description, so validate_desc() should also refuse such a description. The problem could be demonstrated by editing the game description in the "Specific" dialogue box to add a '!' at the end, which caused "new_game: Assertion `!*p' failed.".
* Mines: No moving once you're dead!Ben Harris2023-01-15
| | | | | | | If a Mines save file contains a move after the player has already died, this can lead to an assertion failure once there are more mines that covered squares. Better to just reject any move after the player's died.
* Untangle: forbid descriptions that connect a node to itselfBen Harris2023-01-15
| | | | | These cause an assertion failure in new_game(), so they should be rejected by validate_desc().
* Tighten Bridges' validate_desc()Ben Harris2023-01-15
| | | | | | | | It allowed V, W, X, Y, H, I, J, and K to appear in game descriptions even though new_game() didn't ascribe any meaning to those letters and would fail an assertion if they ever occurred. As far as I can tell, those letters have never done anything, so I've just removed the checks for them from validate_desc().
* Filling: validate length of auto-solve move stringsBen Harris2023-01-15
| | | | | | | Without this, execute_move() can end up reading off the end of the move string, which isn't very friendly. Also remove the comment saying that the move string doesn't have to be null-terminated, because now it does.
* Explain what decode_ui() should do with invalid inputBen Harris2023-01-15
| | | | | | | | It can't signal an error, but it's worth documenting that it can receive invalid input and should do what it can with it. I assume that failing to decode game_ui data from a newer version generally won't be disastrous the way failing to decode a description or move string would be.
* Same Game: reject moves with unexpected characters inBen Harris2023-01-15
| | | | | | Previously if a move string starting with "M" contained anything else other than a digit or a comma, execute_move() would spin trying to parse it. Now it returns NULL.
* Palisade: remove assertion from decode_ui()Ben Harris2023-01-15
| | | | | | | Other games tolerate receiving an encoded game_ui even if they can never generate one. This is sensible, since it means that if a new version starts saving UI state, old versions can load save files generated by those newer versions.
* Mosaic: fault out-of-bounds moves in execute_move()Ben Harris2023-01-15
| | | | Returning NULL in this case is better than dereferencing it.
* When loading, don't decode_ui unless we have a UIBen Harris2023-01-15
| | | | | If the save file doesn't have a UI line, it's not sensible to try to decode it.
* Don't allow negative clues in PatternBen Harris2023-01-15
|
* Palisade: don't leak memory on a bad moveBen Harris2023-01-15
| | | | | Invalid moves can turn up in corrupted save files, and puzzles shouldn't leak memory when failing to load a corrupted save file.
* Black Box: correct order of validation checks for "F" commandsBen Harris2023-01-15
| | | | | It doesn't do much good to range-check an argument after using it as an array index.
* Last-ditch point-count limit for UntangleBen Harris2023-01-15
| | | | | Anything over INT_MAX/3 will cause an integer overflow, so put the limit there for now.
* Adjust Undead upper grid-size limit to avoid overflowBen Harris2023-01-15
|
* Last-ditch maximum size limit for TwiddleBen Harris2023-01-15
| | | | | This makes sure that width * height <= INT_MAX, which it rather needs to be.
* Last-ditch maximum size limit for TracksBen Harris2023-01-15
| | | | | This makes sure that width * height <= INT_MAX, which it rather needs to be.
generated by cgit v1.1 at 2026-04-27 20:19:36 +0000