mirror of
git://git.tartarus.org/simon/puzzles.git
synced 2025-04-20 23:51:29 -07:00
e4d05c36d9
This fixes an amusing UI bug that I think can currently only come up in the unpublished puzzle 'Group', but there's no reason why other puzzles _couldn't_ do the thing that triggers the bug, if they wanted to. Group has unusual keyboard handling, in that sometimes (when a cell is selected for input and the key in question is valid for the current puzzle size) the game's interpret_move function will eat keystrokes like 'n' and 'u' that would otherwise trigger special UI events like New Game or Undo. The bug is that fake keypress events generated from the GUI menus looked enough like those keystrokes that interpret_move would eat those too. So if you start, say, a 16x16 Group puzzle, select an empty cell, and then choose 'new game' from the menu, Group will enter 'n' into the cell instead of starting a new game! I've fixed this by inventing a new set of special keystroke values called things like UI_NEWGAME and UI_UNDO, and having the GUI menus in all my front ends generate those in place of 'n' and 'u'. So now the midend can tell the difference between 'n' on the keyboard and New Game from the menu, and so Group can treat them differently too. In fact, out of sheer overcaution, midend.c will spot keystrokes in this range and not even _pass_ them to the game back end, so Group shouldn't be able to override these special events even by mistake. One fiddly consequence is that in gtk.c I've had to rethink the menu accelerator system. I was adding visible menu accelerators to a few menu items, so that (for example) 'U' and 'R' showed up to the right of Undo and Redo in the menu. Of course this had the side effect of making them real functioning accelerators from GTK's point of view, which activate the menu item in the same way as usual, causing it to send whatever keystroke the menu item generates. In other words, whenever I entered 'n' into a cell in a large Group game, this was the route followed by even a normal 'n' originated from a real keystroke - it activated the New Game menu item by mistake, which would then send 'n' by mistake instead of starting a new game! Those mistakes cancelled each other out, but now I've fixed the latter, I've had to fix the former too or else the GTK front end would now undo all of this good work, by _always_ translating 'n' on the keyboard to UI_NEWGAME, even if the puzzle would have wanted to treat a real press of 'n' differently. So I've fixed _that_ in turn by putting those menu accelerators in a GtkAccelGroup that is never actually enabled on the main window, so the accelerator keys will be displayed in the menu but not processed by GTK's keyboard handling. (Also, while I was redoing this code, I've removed the logic in add_menu_item_with_key that reverse-engineered an ASCII value into Control and Shift modifiers plus a base key, because the only arguments to that function were fixed at compile time anyway so it's easier to just write the results of that conversion directly into the call sites; and I've added the GTK_ACCEL_LOCKED flag, in recognition of the fact that _because_ these accelerators are processed by a weird mechanism, they cannot be dynamically reconfigured by users and actually work afterwards.)
This is the README accompanying the source code to Simon Tatham's puzzle collection. The collection's web site is at <https://www.chiark.greenend.org.uk/~sgtatham/puzzles/>. If you've obtained the source code by downloading a .tar.gz archive from the Puzzles web site, you should find several Makefiles in the source code. However, if you've checked the source code out from the Puzzles git repository, you won't find the Makefiles: they're automatically generated by `mkfiles.pl', so run that to create them. The Makefiles include: - `Makefile.am', together with the static `configure.ac', is intended as input to automake. Run `mkauto.sh' to turn these into a configure script and Makefile.in, after which you can then run `./configure' to create an actual Unix Makefile. - `Makefile.vc' should work under MS Visual C++ on Windows. Run 'nmake /f Makefile.vc' in a Visual Studio command prompt. - `Makefile.cyg' should work under Cygwin / MinGW. With appropriate tweaks and setting of TOOLPATH, it should work for both compiling on Windows and cross-compiling on Unix. - `Makefile.osx' should work under Mac OS X, provided the Xcode tools are installed. It builds a single monolithic OS X application capable of running any of the puzzles, or even more than one of them at a time. - `Makefile.wce' should work under MS eMbedded Visual C++ on Windows and the Pocket PC SDK; it builds Pocket PC binaries. Many of these Makefiles build a program called `nullgame' in addition to the actual game binaries. This program doesn't do anything; it's just a template for people to start from when adding a new game to the collection, and it's compiled every time to ensure that it _does_ compile and link successfully (because otherwise it wouldn't be much use as a template). Once it's built, you can run it if you really want to (but it's very boring), and then you should ignore it. DO NOT EDIT THE MAKEFILES DIRECTLY, if you plan to send any changes back to the maintainer. The makefiles are generated automatically by the Perl script `mkfiles.pl' from the file `Recipe' and the various .R files. If you need to change the makefiles as part of a patch, you should change Recipe, *.R, and/or mkfiles.pl. The manual is provided in Windows Help format for the Windows build; in text format for anyone who needs it; and in HTML for the Mac OS X application and for the web site. It is generated from a Halibut source file (puzzles.but), which is the preferred form for modification. To generate the manual in other formats, rebuild it, or learn about Halibut, visit the Halibut website at <https://www.chiark.greenend.org.uk/~sgtatham/halibut/>.