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.
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.
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.
They're often needed when the fragment isn't frontmost, i.e. when
onPause() has been called. My caching instances fix is feeling a bit
fragile, but I think it's better than nothing. Alternative is probably
to go with DialogFragments, a big change that might not be easy to
make work back to oldest Android.
There's a problem in dual-pane mode where activites outlive
DelegateBase instances that are tied to fragments. AlertDialogs, being
bound to the MainActivity, can sometimes outlive the delegates that
create them, meaning the 'this' referred to from closures bound to
onClick() handlers can come to be invalid (e.g. referencing a removed
fragment). So add a global registry of current DelegateBase instances
by class, and from onClick() handlers fetch and use the current
instance instead of the 'this' that's bound.
Inviting didn't work because it's done by a separate activity whose
onActivityResult() was dropped because DualpaneDelegate was the
recipient. That now handles it by asking MainActivity to sent it to a
contained Delegate. Currently will go only to the top (rightmost) one.
Was opening game in init(), but in dual-pane case there's no
onWindowFocusChanged() call from which to check state, so open it
instead from onResume(), at which point things are already in place to
handle callbacks immediately. That is, post() will work.
use s/getTargetFragment(), but there's still the hack of capturing
state in setResult() and then invoking fragment.onActivityResult()
blindly the next time the backstack is popped.
create queue of Runnables to be run only when Delegate is
visible (onResume() has been called and onPause() hasn't.) When
missing dict finishes downloading, rather than immediately opening its
game, post a Runnable to do it that will be run only after the main
activity is ready to have fragment transactions committing again.
When the game's already opened references must be obtained this
way. This may not be necessary however once game config is opened on
top of games list instead of on top of the game as it should be.
For some reason the 'clean-debug' cycle stopped working because the
file was nuked then not regenerated. Rather than figure out why, just
add a target to generate it every time.
On 4.2 and 4.3 at least, the dimiss comes after the second post
causing that to be dismissed, leaving no alert and the app in some
weird state where not even the back button works. It's been this way
on those older versions since I redid invitations for beta 98.
On 4.2 and 4.3 at least, the dimiss comes after the second post
causing that to be dismissed, leaving no alert and the app in some
weird state where not even the back button works. It's been this way
on those older versions since I redid invitations for beta 98.
Not doing so no longer crashes on when handling notifications, and is
causing runtime exceptions from the OS when board opening chat causes
it to be called recursively.
display problems with GamesList in dual-pane mode, I think because it
prevents stacked activities. Need to figure out if it introduces
problems elsewhere.
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
time to choose between dual-pane and regular mode that doesn't mess
up sending Intents and make it harder to prevent there being
multiple instances of activities that are supposed to be single-top.
in the process of being closed.) If we're successful in getting a
JNIThread object that's already initialized, re-use it, closing only
the JNI part (which probably can't be cleanly re-used with a different
Context.) I worry about the case where the thread's event queue isn't
empty, so there's an assert to catch that case.
