applies to both drawing mechanisms, and secondly, make sure to paint
the spare pieces of window in the _puzzle's_ background colour
rather than the (sometimes slightly different) system default.
[originally from svn r9021]
[r8997 == 26c669a6b2892b97b4a9bc6842f633291951fdbd]
Debian sid (2.20.1), there's a redraw problem when the window has a
different aspect ratio from the puzzle (due to resizing or
maximising): pieces of the window outside the real puzzle rectangle
don't get redrawn when exposed (e.g. by the drop-down menus).
Introduced code to explicitly redraw the whole exposed area,
including the parts that fall outside the pixmap. This makes the
problem go away in my hasty test install of sid, and doesn't seem to
affect the build on lenny.
[originally from svn r8997]
the drawing API, for use by Loopy. It's optional: drawing.c will
construct an acceptable alternative using a filled polygon if the
front end doesn't provide it.
Net and Netslide previously had static functions called
draw_thick_line(), whose claim to the name is less justified and so
they've been renamed.
[originally from svn r8962]
Cairo rendering library in place of GDK, which provides pretty
antialiased graphics much like we get on MacOS. Inertia and Untangle
are perhaps the two games most obviously improved by this.
[originally from svn r8961]
which I didn't know about, but which is clearly a waste of effort
since we keep our own backing pixmap for the puzzle window.
[originally from svn r8960]
'Yes' and 'No' buttons, which means they get the standard icons that
go on those button types. Also reorders yes/no boxes so that they're
the GNOME standard way round.
[originally from svn r8959]
line with freedesktop.org. (This is relatively simple for Puzzles,
since it only writes to the clipboard and never reads it, so the
question of which selection to use when is most easily dealt with by
always writing to both.)
[originally from svn r8929]
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]
compiling gtk.c with STYLUS_BASED defined: most notably, it provides
a row of numeric 'keys' made of GTK button widgets for puzzles that
want a numeric keypad.
[originally from svn r8783]
notice that there was an _official_ way to have menu items marked as
selected or unselected, which is the GtkRadioMenuItem class. Replace
my ad-hoc use of bullet characters with that.
[originally from svn r8601]
[r7980 == ae6c7381272f84c0fd398f6d3e496f571ba42ec8]
available, which magically seems to eliminate most if not all of the
update lag when dragging a point in a large (say 250-point)
Untangle. I don't fully understand how this works, but it seems to!
[originally from svn r8600]
on labels in tables. The effect is that if you resize (e.g.) Solo's
configuration panel, the labels to the left of the various input
boxes will remain just big enough to fit their text in, and all the
extra space will be taken up by the useful part, i.e. the input
boxes themselves. Previously the labels and input boxes would expand
in a 1:1 ratio, causing lots of space to the right of the label text
that wasn't used for anything.
[originally from svn r8599]
using PANGO_CHECK_VERSION. (Irritatingly, the latter is not
available in all versions of Pango, so we have to be cautious about
using it at all. *sigh*)
[originally from svn r8430]
list of selection targets offered by GTK Puzzles grows an extra copy
of each of the three supported text formats every time the user
makes a selection!
[originally from svn r8365]
generate a thousand saved-game files of randomly generated puzzles.
On the general principle that if I find it useful someone else
conceivably might too, add a --save option to the Unix puzzle
binaries, for use with --generate in much the same way as --print.
[originally from svn r8351]
Ubuntu system. I'm inclined to think the real problem is in his gtk
headers, but this is a harmless enough change to avoid hassle.
[originally from svn r8181]
_conditionally_ able to format the current puzzle as text to be sent
to the clipboard. For instance, if a game were to support playing on
a square grid and on other kinds of grid such as hexagonal, then it
might reasonably feel that only the former could be sensibly
rendered in ASCII art; so it can now arrange for the "Copy" menu
item to be greyed out depending on the game_params.
To do this I've introduced a new backend function
(can_format_as_text_now()), and renamed the existing static backend
field "can_format_as_text" to "can_format_as_text_ever". The latter
will cause compile errors for anyone maintaining a third-party front
end; if any such person is reading this, I apologise to them for the
inconvenience, but I did do it deliberately so that they'd know to
update their front end.
As yet, no checked-in game actually uses this feature; all current
games can still either copy always or copy never.
[originally from svn r8161]
currently selected preset, if any. I've used this in the GTK front
end to have the Type menu mark the currently selected menu item.
(After considerable beating of GTK with sticks, I might add. Grr.)
Currently the same UI feature is not yet supported on Windows or
MacOS, but I hope to do those too at some point if it's feasible.
[originally from svn r7980]
(from Debian bug#379452).
Tested on Gtk 2. I've been unable to find a Gtk+-1.2 installation on which
Puzzles compiles, so not tested there.
[originally from svn r7367]
instead of having the puzzle binary export its window ID to a script
which then runs xwd, we can use the gdk-pixbuf library to have the
puzzle binary _itself_ read its own internal pixmap and save it
straight to a PNG. How handy. And faster, and less timing-sensitive.
[originally from svn r7022]
mkfiles.pl change (I don't seem to be planning ahead very well this
week), this time to provide a list of fallback options for an object
file. That way, I have a no-icon.c which quietly replaces
icons/foo-icon.c if the latter doesn't exist, and so again people
checking straight out from Subversion shouldn't have trouble.
[originally from svn r7021]
the web, which I hope will also end up being extended to generate
both Windows and X icons for each individual puzzle. The mechanism
is: for each puzzle there's a save file in the `icons' subdirectory
showing a game state which I think is a decent illustration of the
puzzle, and then there's a nasty set of scripts which runs each
puzzle binary, loads that save file, grabs a screenshot using xwd,
and munges it into shape.
In order to support this I've added two new options (--redo and
--windowid) to all the GTK puzzles, which I don't expect ever to be
used outside the icons makefile. I've also added two more options
(--load and --id) which force a GTK puzzle to treat its command-line
option as a save file or as a game ID respectively (the previous
behaviour was always to guess, and sometimes it guessed wrong).
[originally from svn r7014]
accelerator key (N/U/R/Q) was pressed -- once for the menu accelerator, and
once more in key_event().
This workaround, while unlovely, should at least not break in future (since the
things it relies on are unlikely to change).
[originally from svn r6745]
[r6711 == 077aa510c78f3273bd0d4ca4f1ca14780822ebf9]
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]
maxflow.c. Also in this checkin, fixes to the OS X and GTK back ends
to get ALIGN_VNORMAL right. This is the first time I've used it! :-)
[originally from svn r6390]
outline polygon with a clipping rectangle active. I don't know or
care whether this is GTK or my X server or what, but I'm working
around it by drawing the lines myself, which seems to sort it out.
[originally from svn r6227]
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]
either a game ID or a save file name. (The former takes priority,
because you can usually find a synonym for the latter, such as by
prepending `./' or `$PWD/'.)
[originally from svn r6135]
encode_params(). This is necessary for cases where generation-time parameters
that are normally omitted from descriptive IDs can place restrictions on other
parameters; in particular, when the default value of a relevant generation-time
parameter is not the one used to generate the descriptive ID, validation could
reject self-generated IDs (e.g., Net `5x2w:56182ae7c2', and some cases in
`Pegs').
[originally from svn r6068]
constraint: because some front ends interpret `draw filled shape' to
mean `including its boundary' while others interpret it to mean `not
including its boundary' (and X seems to vacillate between the two
opinions as it moves around the shape!), you MUST NOT draw a filled
shape only. You can fill in one colour and outline in another, you
can fill or outline in the same colour, or you can just outline, but
just filling is a no-no.
This leads to a _lot_ of double calls to these functions, so I've
changed the interface. draw_circle() and draw_polygon() now each
take two colour arguments, a fill colour (which can be -1 for none)
and an outline colour (which must be valid). This should simplify
code in the game back ends, while also reducing the possibility for
coding error.
[originally from svn r6047]
midend.c. Also I've added an experimental front end in gtk.c only:
`Save' and `Load' options on the Game menu, which don't even show up
unless you define the magic environment variable
PUZZLES_EXPERIMENTAL_SAVE. Once I'm reasonably confident that the
whole edifice is plausibly stable, I'll take that out and turn it
into a supported feature (and also implement it in OS X and Windows
and write documentation).
[originally from svn r6030]
retired, and replaced with a simple string. Most of the games which
use it simply encode the string in the same way that the Solve move
will also be encoded, i.e. solve_game() simply returns
dupstr(aux_info). Again, this is a better approach than writing
separate game_aux_info serialise/deserialise functions because doing
it this way is self-testing (the strings are created and parsed
during the course of any Solve operation at all).
[originally from svn r6029]
