zakarya/puzzles
1
0
Fork 0
mirror of git://git.tartarus.org/simon/puzzles.git synced 2025-04-20 15:41:30 -07:00
Code Issues Packages Projects Releases Wiki Activity

Move per-puzzle ad-hoc getenv preferences into game_ui.

Browse Source 
Environment variables that set specific settings of particular
puzzles, such as SLANT_SWAP_BUTTONS, LIGHTUP_LIT_BLOBS and
LOOPY_AUTOFOLLOW, now all affect the game behaviour via fields in
game_ui instead of being looked up by getenv in the individual
functions that need to know them.

The purpose of this refactoring is to put those config fields in a
place where other more user-friendly configuration systems will also
be able to access them, once I introduce one. However, for the moment,
there's no functional change: I haven't _yet_ changed how the user
sets those options. They're still set by environment variables alone.
All I'm changing here is where the settings are stored inside the
code, and exactly when they're read out of the environment to put into
the game_ui.

Specifically, the getenvs now happen during new_ui(). Or rather, in
all the puzzles I've changed here, they happen in a subroutine
legacy_prefs_override() called from within new_ui(), after it's set up
the default values for the settings, and then gives the environment a
chance to override them. Or rather, legacy_prefs_override() only
actually calls getenv the first time, and after that, it's cached the
answers it got.

In order to make the override functions less wordy, I've altered the
prototype of getenv_bool so that it returns an int rather than a bool,
and takes its default return value in the same form. That way you can
set the default to something other than 0 or 1, and find out whether a
value was present at all.

This commit only touches environment configuration specific to an
individual puzzle. The midend also has some standard environment-based
config options that apply to all puzzles, such as colour scheme and
default presets and preset-menu extension. I haven't handled those
yet.
This commit is contained in:
Simon Tatham
2023-04-21 15:41:18 +01:00
parent a4fca3286f
commit 0d1a1f08ba
11 changed files with 402 additions and 195 deletions
Download Patch File Download Diff File Expand all files Collapse all files

72
range.c
View File

@ -1225,13 +1225,49 @@ static char *game_text_format(const game_state *state)
struct game_ui {
puzzle_size r, c; /* cursor position */
bool cursor_show;
/*
* User preference option to swap the left and right mouse
* buttons.
*
* The original puzzle submitter thought it would be more useful
* to have the left button turn an empty square into a dotted one,
* on the grounds that that was what you did most often; I (SGT)
* felt instinctively that the left button ought to place black
* squares and the right button place dots, on the grounds that
* that was consistent with many other puzzles in which the left
* button fills in the data used by the solution checker while the
* right button places pencil marks for the user's convenience.
*
* My first beta-player wasn't sure either, so I thought I'd
* pre-emptively put in a 'configuration' mechanism just in case.
*/
bool swap_buttons;
};
static void legacy_prefs_override(struct game_ui *ui_out)
{
static int initialised = false;
static int swap_buttons = -1;
if (!initialised) {
initialised = true;
swap_buttons = getenv_bool("RANGE_SWAP_BUTTONS", -1);
}
if (swap_buttons != -1)
ui_out->swap_buttons = swap_buttons;
}
static game_ui *new_ui(const game_state *state)
{
struct game_ui *ui = snew(game_ui);
ui->r = ui->c = 0;
ui->cursor_show = getenv_bool("PUZZLES_SHOW_CURSOR", false);
ui->swap_buttons = false;
legacy_prefs_override(ui);
return ui;
}
@ -1298,36 +1334,12 @@ static char *interpret_move(const game_state *state, game_ui *ui,
}
if (button == LEFT_BUTTON || button == RIGHT_BUTTON) {
/*
* Utterly awful hack, exactly analogous to the one in Slant,
* to configure the left and right mouse buttons the opposite
* way round.
*
* The original puzzle submitter thought it would be more
* useful to have the left button turn an empty square into a
* dotted one, on the grounds that that was what you did most
* often; I (SGT) felt instinctively that the left button
* ought to place black squares and the right button place
* dots, on the grounds that that was consistent with many
* other puzzles in which the left button fills in the data
* used by the solution checker while the right button places
* pencil marks for the user's convenience.
*
* My first beta-player wasn't sure either, so I thought I'd
* pre-emptively put in a 'configuration' mechanism just in
* case.
*/
{
static int swap_buttons = -1;
if (swap_buttons < 0)
swap_buttons = getenv_bool("RANGE_SWAP_BUTTONS", false);
if (swap_buttons) {
if (button == LEFT_BUTTON)
button = RIGHT_BUTTON;
else
button = LEFT_BUTTON;
}
}
if (ui->swap_buttons) {
if (button == LEFT_BUTTON)
button = RIGHT_BUTTON;
else
button = LEFT_BUTTON;
}
}
switch (button) {