So far uses curl and json-c to send b64-encoded data to new script
which is able to echo the data. Next that script will need to open a
UDP socket to the relay and return results that appear before timeout.
Make face-up tile picker util method return void and add mechanism for
passing in selected tiles asynchronously, as has been done recently with
the rest of the once-blocking util callbacks. Works perfectly in the gtk
case. Likely crashes in curses (if picking face-up option is on.) In
java all the callbacks are there but rather than put up a UI we pretend
the user says "pick 'em for me" each time. Putting up a UI is next.
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.
I think this was related to changing the order in which save operations
happen and that it's no longer valid to insist that there already be a
rowid at this point, but could be wrong....
Fixes problem with list view always being a move behind, since it's
saving not summarizing that was triggering the refresh, but summarizing
that added the data from which refresh/list view drew.
Idea is to have the games list stay in sync, but in fact it stays one
move behind, at least in a typical standalone human-vs-robot game. So
this is incomplete.
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.
Mistaken option to gtk_box_pack_start() meant the scrollbar got
allocated space along with the board when the container expands, not
what you want with a scrollbar.
Trying and failing to get just the content area of the tree view to
scroll, whether by putting it in its own container or hooking into the
scrollable interface tree view allegedly supports.
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.
