Its absence was breaking the icon build on Ubuntu 14.04, because you
ask convert to map an image into a specific 16-colour palette, and it
does so and _then_ nonconsensually maps those colours in turn through
a colourspace transformation you didn't ask for, causing icon.pl to
fail an assertion when it finds an RGB value not in the palette.
I think I did this in GTK2 on the basis that our server-side cache
pixmap was double-buffering enough for us - any puzzle which erased a
big area with a background rectangle and then redrew over the top of
it would do so only on the off-screen pixmap, and the updates would
only be copied to the visible window after it was all done.
In GTK3, I don't think there's any need - this is all the usual way
things are done anyway, as far as I can see. So I've turned this call
back off, at least until I hear of a reason why I need it again.
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 what GTK 3 uses in place of 'expose_event'. Also I've arranged
here for my internal USE_CAIRO_WITHOUT_PIXMAP setting to be enabled in
GTK3, as well as in GTK2 with deprecated functions disabled.
This also involves setting some "hexpand" properties on the widgets
contained in the GtkGrid, to achieve effects which GtkTable did by
setting flags in gtk_table_attach.
When GDK_DISABLE_DEPRECATED is defined, we now don't have fe->pixmap;
instead we just maintain our client-side window contents in fe->image,
and draw from there directly to the window in the expose handler.
We were packing the GtkTable into the dialog's content area using
gtk_box_pack_end, which had the slightly silly effect that resizing
the config box vertically would keep all the controls aligned to the
_bottom_ rather than the top.
Sometimes, we can get a "configure_area" event telling us that the
drawing area has changed size to the same size it already was. This
can happen when we change puzzle presets in a way that doesn't change
the size, and also sometimes seems to happen as a side effect of
changing the text in the status line.
In that situation, it's a waste of effort - and can cause visible
on-screen flicker - to throw away the window's backing image and
pixmap and regenerate them from scratch. So now we detect a non-resize
and avoid doing all that.
The only thing we retain unconditionally in configure_area is the
midend_force_redraw, because that's the place where a puzzle redraw is
forced when changing presets or loading a new game.
At minimum size (3x3) Galaxies can generate a pre-solved single dot
game.
You have to add and remove a line to get the victory flash which is a
bit weird, so just prevent this.
Apple upgraded me to Xcode 7 yesterday, and now [NSString cString]
gives a deprecation warning, which -Werror turns into a full-on build
failure. Explicitly specify an encoding.
(I mention in a comment that there's an alternative piece of API that
I possibly ought to be using instead, but until I make a concrete
decision about where my backwards compatibility threshold is, I'll
leave it as it is for the moment.)
The mouseup listener was calling event.preventDefault(), as part of
the mechanism for making mouse clicks and drags on the puzzle's resize
handle have resizing effects _instead_ of the normal browser
behaviour. However, calling event.preventDefault() on _every_ mouseup,
rather than just the ones associated with the resize handle, was
overkill, and I've recently noticed that it's breaking attempts to
select from the game type dropdown by clicking the mouse. So now I'm
only calling preventDefault() on the mouseups that I have reason to
think are actually relevant to what I'm trying to do.
(I don't know why I've only just noticed this. I suppose a change of
behaviour between Firefox versions is the most likely cause.)
MultiByteToWideChar expects a WCHAR[256] output buffer if you pass it
an output length of 256. TCHAR[256] is entirely the wrong size, though
for some reason Visual Studio seems not to have thrown a compile error
pointing that out.
Thanks to Jason Hood for spotting this.
Keen, Towers and Unequal (and Group) already have this feature in
common: pressing m while no square is selected, causes a full set of
pencil marks to be filled in for every square without a real number/
letter/whatever in it. Solo and Undead share the basic UI principles
(left-click to select a square then type a thing to go in it, vs
right-click to select a square then type things to pencil-mark in it),
but did not have that same feature. Now they do.
The is_hint_stale() function has the side effect of copying a path
hint's new colour-relevant information into the game_drawstate, where
draw_path_hint will then use it. But it returns TRUE early in some
situations, notably !ds->started, which can happen after the actual
game start if the window is resized and a fresh drawstate is created.
This patch, thanks to Chris Boyle, fixes it by eliminating the early
returns from is_hint_stale - the return value is unchanged, but now
the side effects happen reliably.
It's a pain having it in a rule in Makefile.gtk, which isn't even the
recommended makefile these days - it can't be re-run conveniently, and
there's no way to parametrise it. Now it can be run no matter which
makefile you're using, and it lets you narrow down to a subset of
games (though not presets). Other options could easily be added.
