6 Commits

Author SHA1 Message Date
a7dc17c425 Rework the preset menu system to permit submenus.
To do this, I've completely replaced the API between mid-end and front
end, so any downstream front end maintainers will have to do some
rewriting of their own (sorry). I've done the necessary work in all
five of the front ends I keep in-tree here - Windows, GTK, OS X,
Javascript/Emscripten, and Java/NestedVM - and I've done it in various
different styles (as each front end found most convenient), so that
should provide a variety of sample code to show downstreams how, if
they should need it.

I've left in the old puzzle back-end API function to return a flat
list of presets, so for the moment, all the puzzle backends are
unchanged apart from an extra null pointer appearing in their
top-level game structure. In a future commit I'll actually use the new
feature in a puzzle; perhaps in the further future it might make sense
to migrate all the puzzles to the new API and stop providing back ends
with two alternative ways of doing things, but this seemed like enough
upheaval for one day.
2017-04-26 21:51:23 +01:00
9cfc61c5f7 In the Java front end, don't try to guess the puzzle rectangle's
width and height by assuming mirror symmetry within the containing
applet area. Instead, use the proper width and height as given back
by the C sizing function.

(In particular, this fixes a bug where the non-blanked puzzle area
appeared too tall by the height of the menu bar, probably as a
result of confusing PuzzleApplet.getHeight() with
PuzzlePanel.getHeight(). But the mirroring approach was conceptually
wrong anyway.)

[originally from svn r9022]
2010-11-06 18:14:41 +00:00
9fbb365684 Introduce, and implement as usefully as I can in all front ends, a
new function in the drawing API which permits the display of text
from outside basic ASCII. A fallback mechanism is provided so that
puzzles can give a list of strings they'd like to display in order
of preference and the system will return the best one it can manage;
puzzles are required to cope with ASCII-only front ends.

[originally from svn r8793]
2009-12-27 10:01:16 +00:00
407f29c46f Introduce some infrastructure to permit games' print functions to
draw dotted lines. No puzzle yet uses this, but one's about to.

[originally from svn r8453]
2009-02-22 12:05:38 +00:00
0c88256a22 Handle a <param name="game_id"> by passing it in to the C side as
argv[1], which in turn feeds it into the midend as a game ID. This
can of course take any of the forms supported by the native C
puzzles: a pure game parameter string, a params:description specific
game ID, or a params#seed random game ID.

[originally from svn r8095]
2008-06-26 19:09:07 +00:00
dd85394bf6 Michael Schierl's patch to compile the puzzles as Java applets using
NestedVM. Wow!

[originally from svn r8064]
2008-06-10 20:35:17 +00:00