mirror of
git://git.tartarus.org/simon/puzzles.git
synced 2025-04-21 08:01:30 -07:00
4e1cc65701
In GTK 2, we had a big pile of horrible code to deal with the fact that it's very hard to open a window in such a way as to make it easy to resize smaller as well as bigger. Essentially, we'd open the window with the drawing area's minimum size request set to the desired _initial_ window size; then we'd wait until GTK had finished creating other window components (menu bar, status line) and the window's size allocation had settled down, and finally reduce the size request to the real minimum size so that now the window was resizable in both directions. This also involved some deliberate checking of the Ubuntu Unity GTK extension which steals the menu bar and put it elsewhere (see commit 8f8333a35), to avoid us waiting forever for a menu bar that wasn't going to show up. But in GTK3, this has all become actually sensible! All we now have to do is to set the window's geometry hints to indicate the drawing area itself as the base widget (probably a good plan anyway), and then we can set the initial size using gtk_window_set_default_geometry() and resize it later using gtk_window_resize_to_geometry(). So now we can completely condition out all of the previous horrors, and consider them to be legacy GTK2 compatibility code only. Phew.
This is the README accompanying the source code to Simon Tatham's puzzle collection. The collection's web site is at <http://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 Subversion 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. - `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 <http://www.chiark.greenend.org.uk/~sgtatham/halibut/>.