Continue conversion of alerts that required blocking the JNI thread. Now
board_commitTurn() takes a second boolean indicating whether phonies
found have been approved by user. Common code informs user, and if he
approves client code calls board_commitTurn() again. In case where
turn's lost there's no call to make back, but there's the undesirable
change that if a robot moves next its move will be reported on top of
the turn-lost alert. Ideally new alerts would appear under, not on top
of, those that have not yet been dismissed.
Next step in converting util_ methods that required blocking: blank tile
assignment. Now post a query and add a method that the client code can
call when the user's decided. Include enough state (col, row, and
playerNum) so that it's probably pretty safe.
Probably breaks curses build, but for gtk and Android
turn move and trade confirmation into a two-step process, making
board_commitTurn() non-interactive when called with a second
parameter. The old blocking util methods now return void and it's up to
the client code to interact (on the main thread) then re-call
board_commitTurn() if appropriate.
First attempt to stop blocking the jni thread: instead of returning a
password from a util_ method, have it include enough state that the UI
can return, put up a dialog, and then pass that state and the password
back and have them matched up again. I think this will work for the
remaining blocking Alerts too.
An edge case, but: doing "new from" on a game without any connection
types crashed because of an assertion in comms that assumed
addr_setType() was being called on zero-initialized flags, which
shouldn't have been a requirement. Pulled that as well as java code that
added RELAY-type connectivity to any game that had none. If a game has
none, leave it that way.
Grab and store the local device's mac address. Add p2p as a type of
address, represented by the mac address of the recipient. Include the
local device's address in invitations sent when specified by user. Now
the WifiDirectService class is being passed a packet and the address of
the recipient; it will next need to set up sockets with every device it
encounters and map them to their mac addresses so that it can do a send.
commented-out logging of drawCell, with flags; debug-build checks that
static rects passed to java draw code aren't being used by multiple
threads at once.
There are some screen dimensions, especially with dual-pane mode, where
the board is just bit narrower than the screen. Rather than have narrow
white borders, allow the cells to take up the slack. The API takes an
upper bound on the ratio of width to height so things shouldn't get too
odd looking.
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.
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.
only) mpool. I'm getting assertions about failure to free now that
multiple threads are accessing open games, but I think they're bogus:
due to multiple threads modifying the leak-detection counters. This
seems to fix the assertions I was seeing in mpool_destroy().
left of tray divider (without moving divider) it may still be included
in hinted moves. Fix is to reset engine whenever the set of tiles left
of divider changes.
treatment of the final 8 bits. I'll need to release a version that
still produces the incorrect hash for compatibility with existing
clients that expect it, but that also looks for the correct hash. When
that's out there I can do a new release that sends the correct hash.
stack, go down the stack looking for a match. If it's found, pop down
to that point then apply the move. This fixes stalls in the test
engine when undo is enabled, and so I assume that undos and turns are
somehow coming in out-of-order. Should be rare that this happens.
can happen when somebody does an undo, since the ordering of undos and
moves is not assured. The result is a temporary (I think) stall, where
a move is rejected because the hash doesn't match, but that will be
accepted later when the undo's been processed and the hash will now
match.
that's real data. This fixes assertions that after popping a move off
the move stack the hash is the same as before it was pushed. It may or
may not be sufficient to fix reported stalls, but it's certainly
necessary.
count them, and do so based on new msgNo passed from comms that's
concatenation of channelNo and msgID so that duplicates (over multiple
transports) aren't counted twice.
# 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.
