The cursor keys navigate amongst the points. CURSOR_SELECT toggles dragging; CURSOR_SELECT2 and the Tab key cycle through the points. The cursor navigation scheme jumps to the nearest point within the quadrant of the cursor direction; this seems to yield fairly intuitive gameplay. Unfortunately, the "quadrant-nearest-neighbors" digraph produced by this scheme is not necessarily fully reciprocal; that is, pressing opposite cursor keys in sequence does not always return to the original point. There doesn't seem to be any immediately obvious way around this. As for connectivity (i.e. whether all points are reachable from any given point), I could not find a counterexample, but I don't yet have a formal proof that this is the case in general. Hence, I've added the ability to cycle through all the points with Tab. (This will probably also be useful in conjunction with the "Numbers" point drawing preference.)
This compile-time definition switches the game into showing a distinct non-negative integer for each vertex, instead of indistinguishable blobs. Its main use to me in the past has been when I'm trying to planarise 'real' graphs, that is, graphs I got from outside the game and wanted a planar embedding of. Having made one in Untangle's UI I could then read off which vertex was which. That's an unusual use of the game, but _might_ be useful to someone else. Perhaps a more interesting use of this feature would be to direct someone else's play verbally - it would be much easier to tell them which vertex to click on that way!
I just found this #define in the Untangle source code, which I'd completely forgotten was there. It causes each graph edge to be highlighted in red if another edge crosses it, so that when you only have a small number of crossings left to sort out, it's obvious where they are. Now we have a preferences system, there's no need to make this a compile-time option! We can make it run-time selectable, for users who want the extra help.
In grid-snapping mode, Untangle was still recording vertex positions in increments of one pixel. This meant that if you positioned vertices on a small window, then enlarged the window and positioned more vertices, the two sets of vertices generally wouldn't line up with one another. This was annoying, and obviously silly when Untangle has a resolution-independent co-ordinate system. So now the snapped positions are recorded in a form that doesn't depend on the tilesize.
All the other constants named UI_* are special key names that can be passed to midend_process_key(), but UI_UPDATE is a special return value from the back-end interpret_move() function instead. This renaming makes the distinction clear and provides a naming convention for future special return values from interpret_move().
Requested by a user who otherwise found themself spending too much time struggling to get lines nicely horizontal or vertical. The implementation is easy, but the question is what size of grid is appropriate. Untangle's own generated games are constructed by making a planar graph drawn on an extremely coarse grid - but snapping to _that_ grid would give away information about the puzzle solution, and also, Untangle wouldn't know any similar information about graphs generated by any other method. So a better approach is to choose a size of grid that guarantees that _any_ graph with n vertices can be drawn on it with nonintersecting straight edges. That sounds like a tricky maths problem - but happily, the solution is given in a book I already had a copy of. References in a comment (plus a proof of a pedantic followup detail about multiple planar embeddings).
Where possible, that is. If our compilation environment has provided int64_t, we can just make our int64 type be that, and not have to mess around with multi-word arithmetic at all.
These are similar to the existing pair configure() and custom_params() in that get_prefs() returns an array of config_item describing a set of dialog-box controls to present to the user, and set_prefs() receives the same array with answers filled in and implements the answers. But where configure() and custom_params() operate on a game_params structure, the new pair operate on a game_ui, and are intended to permit GUI configuration of all the settings I just moved into that structure. However, nothing actually _calls_ these routines yet. All I've done in this commit is to add them to 'struct game' and implement them for the functions that need them. Also, config_item has new fields, permitting each config option to define a machine-readable identifying keyword as well as the user-facing description. For options of type C_CHOICES, each choice also has a keyword. These keyword fields are only defined at all by the new get_prefs() function - they're left uninitialised in existing uses of the dialog system. The idea is to use them when writing out the user's preferences into a configuration file on disk, although I haven't actually done any of that work in this commit.
I'm about to move some of the bodgy getenv-based options so that they become fields in game_ui. So these functions, which could previously access those options directly via getenv, will now need to be given a game_ui where they can look them up.