| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
[originally from svn r9147]
|
| |
|
|
|
|
|
| |
causing complete mis-draws - but only when the window was exactly the
right size!
[originally from svn r9146]
|
| |
|
|
|
|
|
|
|
| |
Use the puzzle background colour, like the GTK front end does.
(I know that renders the effect of the previous commit invisible,
but it's the principle of the thing! :-)
[originally from svn r9023]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
| |
ALIGN_VNORMAL is in use: ALIGN_VNORMAL indicates that the supplied
y-coordinate denotes the _baseline_ of the text, not its top, so
adding on 'asc' to convert to the baseline is wrong.
This only affects Tents, at present.
[originally from svn r8452]
|
| |
|
|
|
|
| |
custom game configuration code from working in the Java applets.
[originally from svn r8192]
|
| |
|
|
| |
[originally from svn r8106]
|
| |
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
| |
to resize the puzzle to zero size. Ignore all such requests, in the
assumption that a more sensible resize will be along soon enough
(which does seem to happen, though I haven't debugged the NestedVM
front end hard enough to figure out why the bogus resizes happen in
the first place).
[originally from svn r8094]
|
|
|
NestedVM. Wow!
[originally from svn r8064]
|
