Game created for rematch was coming up unconnected and without
explanation if recipient of invitation hadn't responded. Don't dismiss
the INVITE alert in that case.
This to prevent the game list item from resizing (and so reflowing the
whole list) when it's reloading game info. Better would be to set a
timer and only show the reloading view if it seems likely to take a
minute.
Toward something that should work with android: pass a potentially
unique draw context into new method that creates a new board just for
the draw and makes its scoreboard and tray disappear.
Done in a way that won't work for Android just to try out the gtk
way. Tweaks and reuses the existing draw context and board, which is
precisely what the android version can't easily do.
Add new "snap" blob to db and pixbuf column to games display table, and
add code to store and retrieve from db. What's stored now is a
hard-coded file, so next up is generating an actual snapshot from the
game.
When a gtk3 window's shutting down it appears we can't get a cairo_t*
for it. This change makes it possible to turn that fact into aborting
the whole draw operation.
Whenver we get the draw signal, invalidate the whole board and draw
it. This is resulting in a lot of wasted effort that might be mitigated
if I figured out how to get the invalid region out of the cairo_t*
that's passed in, but this is a test app and my machine's pleny fast. So
go with it for now.
I'm seeing unreproducible crashes trying to double-dispose jni game
instances and think it's a race condition involving JNIThread. Forcing
it to hold the lock in the constructor, access to which is synchronized,
is an improvement and may well fix it.
Board renders, but only when touched. Tray and scoreboard skipped for
now. Lots of changed still to go, and some asserts added where I didn't
want to stop to solve a compile problem.
When a device is a tablet and not a first-time install, put up an offer
to enable dual-pane mode. Change confirm-alerts to include
do-not-show-again box, and use that. Add menu item, hidden when not in
dual-pane mode, to turn it back off. Exit app after posting a
notification and a toast on changing that preference so it'll take
effect.
When app's launched via a move-made intent that will lead to opening
the board, let the GamesList fragment get fully in place before
opening the board. To open two at the same time confuses my fragment
code (OS kills it with a fatal exception.)
When during onResume() of BoardDelegate we notice an undisplayed chat
message, don't add add a Chat fragment because (perhaps due to a bug
in my code) it'll come up blank. Instead use post() to open it via a
Runnable() that'll run after onResume() and the rest of current
fragment setup have completed.
When loading gamelistitems in dual-pane mode there will often be an
open game. Don't hold up the whole process by first waiting 1 second
to get a lock that's unavailable. Instead check if there's a JNIThread
instance available and if so use its lock to get the summary. Required
fixing JNIThread to not crash trying to save when released too early.
Fixes, or at least makes extremely unlikely, race condition where one
thread makes use of an existing JNIThread instance then releases it
before the thread that created it has had a chance to call configure()
to actually load the game.
Problem was that changes to games didn't show up in the thumbnail
until the game was closed. Simply using existing snapshot didn't work
because it changes the board layout in order to "draw" to
ThumbnailCanvas and that change isn't easily reversed. So copy
existing code to open a new JNI object with just-saved game data
and use it to create a thumbnail bitmap.
