6 Commits

Author SHA1 Message Date
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
1d661ec46b Patch from James H providing lots more paranoid casting. Also one
actual behaviour change: Untangle now permits dragging with the
right mouse button, which has exactly the same effect as it does
with the left. (Harmless on desktop platforms, but helpful when
"right-click" is achieved by press-and-hold; now the drag takes
place even if you hesitate first.)

[originally from svn r8177]
2008-09-13 18:29:20 +00:00
0564211167 Revise the printing colour framework so that we can explicitly
request either of hatching or halftoning, and also choose which to
supply as a fallback when printing in colour.

[originally from svn r7976]
2008-04-07 17:13:29 +00:00
240b6cab8c Cleanup: relieve frontends of the duty to call
midend_rewrite_statusbar() and check the result against the last
string returned. This is now done centrally in drawing.c, and the
front end status bar function need only do what it says on the tin.

While I'm modifying the prototype of drawing_init(), I've also
renamed it drawing_new() for the same reason as random_new() (it
_allocates_ a drawing object, rather than just initialising one
passed in).

[originally from svn r6420]
2005-10-22 17:23:55 +00:00
af59dcf685 Substantial infrastructure upheaval. I've separated the drawing API
as seen by the back ends from the one implemented by the front end,
and shoved a piece of middleware (drawing.c) in between to permit
interchange of multiple kinds of the latter. I've also added a
number of functions to the drawing API to permit printing as well as
on-screen drawing, and retired print.py in favour of integrated
printing done by means of that API.

The immediate visible change is that print.py is dead, and each
puzzle now does its own printing: where you would previously have
typed `print.py solo 2x3', you now type `solo --print 2x3' and it
should work in much the same way.

Advantages of the new mechanism available right now:
 - Map is now printable, because the new print function can make use
   of the output from the existing game ID decoder rather than me
   having to replicate all those fiddly algorithms in Python.
 - the new print functions can cope with non-initial game states,
   which means each puzzle supporting --print also supports
   --with-solutions.
 - there's also a --scale option permitting users to adjust the size
   of the printed puzzles.

Advantages which will be available at some point:
 - the new API should permit me to implement native printing
   mechanisms on Windows and OS X.

[originally from svn r6190]
2005-08-18 17:50:14 +00:00