2023-09-22 11:54:15 +00:00
|
|
|
#include "putty.h"
|
|
|
|
|
Add ability to specify custom load and save separately.
This allows a couple more settings to be treated automatically on
save, which are more complicated on load because they still honour
older alternative save keywords.
In particular, CONF_proxy_type and CONF_remote_qtitle_action now have
explicit enum mappings. These were needed for the automated save code,
but also, I've rewritten the custom load code to use them too. This
decouples the storage format of those settings from the order of
values in the internal enum, which is generally an advantage of
specifying storage enums explicitly.
Those two settings weren't already tested by test_conf, because I
wasn't changing them in previous commits. Now I've added extra code
that does test them, and verified it works when backported to commit
b567c9b2b5e159f where I introduced test_conf before beginning the main
refactoring.
A setting can also be specified explicitly as not loaded and saved at
all. There were quite a few commented that way, but now there's a
machine-readable indication of it.
test_conf will now check that all these settings make sense together -
things shouldn't have a save keyword unless they use it, and should
have one if they don't, and shouldn't specify combinations of options
that conflict.
(For that reason, test_conf is now also running the consistency check
before the main test, so that a missing keyword will cause an error
message _before_ it causes a segfault, saving some debugging!)
2023-09-22 15:04:25 +00:00
|
|
|
#define CONF_ENUM(name, ...) \
|
|
|
|
static const ConfSaveEnumValue conf_enum_values_##name[] = { \
|
|
|
|
__VA_ARGS__ \
|
|
|
|
}; const ConfSaveEnumType conf_enum_##name = { \
|
|
|
|
.values = conf_enum_values_##name, \
|
|
|
|
.nvalues = lenof(conf_enum_values_##name), \
|
Begin moving saved-setting semantics into conf_key_info.
The new ConfKeyInfo structure now includes some fields indicating how
to load and save each config option: what keyword it's stored under in
the saved settings file, and what its default value should be set to
when loading a session that doesn't mention it. (Including, of course,
loading the null session at program startup.)
So far, this only applies to the saved settings that are sufficiently
simple: a single integer, string or boolean value whose internal
format matches its storage format, or an integer value consisting of a
finite enumeration with a fixed mapping between its internal and
storage formats. Anything more difficult than that - mappings,
variable defaults, config options tied together, options that still
support a legacy save format alongside the up-to-date one, things
under #ifdef - hasn't yet been tampered with.
This allows a large amount of repetitive code in settings.c to be
deleted, and replaced by simple loops over the conf_key_info array
doing all the easy work. The remaining manual load/save code per
option is all there because it's difficult in some way.
The transitional test_conf program still passes after this upheaval.
2023-09-22 12:48:20 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
#define VALUE(eval, sval) { eval, sval, false }
|
|
|
|
#define VALUE_OBSOLETE(eval, sval) { eval, sval, true }
|
|
|
|
|
|
|
|
#include "conf-enums.h"
|
|
|
|
|
|
|
|
bool conf_enum_map_to_storage(const ConfSaveEnumType *etype,
|
|
|
|
int confval, int *storageval_out)
|
|
|
|
{
|
|
|
|
for (size_t i = 0; i < etype->nvalues; i++)
|
|
|
|
if (!etype->values[i].obsolete &&
|
|
|
|
etype->values[i].confval == confval) {
|
|
|
|
*storageval_out = etype->values[i].storageval;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool conf_enum_map_from_storage(const ConfSaveEnumType *etype,
|
|
|
|
int storageval, int *confval_out)
|
|
|
|
{
|
|
|
|
for (size_t i = 0; i < etype->nvalues; i++)
|
|
|
|
if (etype->values[i].storageval == storageval) {
|
|
|
|
*confval_out = etype->values[i].confval;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2023-09-22 11:54:15 +00:00
|
|
|
#define CONF_OPTION(id, ...) { __VA_ARGS__ },
|
|
|
|
#define VALUE_TYPE(x) .value_type = CONF_TYPE_ ## x
|
|
|
|
#define SUBKEY_TYPE(x) .subkey_type = CONF_TYPE_ ## x
|
Begin moving saved-setting semantics into conf_key_info.
The new ConfKeyInfo structure now includes some fields indicating how
to load and save each config option: what keyword it's stored under in
the saved settings file, and what its default value should be set to
when loading a session that doesn't mention it. (Including, of course,
loading the null session at program startup.)
So far, this only applies to the saved settings that are sufficiently
simple: a single integer, string or boolean value whose internal
format matches its storage format, or an integer value consisting of a
finite enumeration with a fixed mapping between its internal and
storage formats. Anything more difficult than that - mappings,
variable defaults, config options tied together, options that still
support a legacy save format alongside the up-to-date one, things
under #ifdef - hasn't yet been tampered with.
This allows a large amount of repetitive code in settings.c to be
deleted, and replaced by simple loops over the conf_key_info array
doing all the easy work. The remaining manual load/save code per
option is all there because it's difficult in some way.
The transitional test_conf program still passes after this upheaval.
2023-09-22 12:48:20 +00:00
|
|
|
#define DEFAULT_INT(x) .default_value.ival = x
|
|
|
|
#define DEFAULT_STR(x) .default_value.sval = x
|
|
|
|
#define DEFAULT_BOOL(x) .default_value.bval = x
|
|
|
|
#define SAVE_KEYWORD(x) .save_keyword = x
|
Add ability to specify custom load and save separately.
This allows a couple more settings to be treated automatically on
save, which are more complicated on load because they still honour
older alternative save keywords.
In particular, CONF_proxy_type and CONF_remote_qtitle_action now have
explicit enum mappings. These were needed for the automated save code,
but also, I've rewritten the custom load code to use them too. This
decouples the storage format of those settings from the order of
values in the internal enum, which is generally an advantage of
specifying storage enums explicitly.
Those two settings weren't already tested by test_conf, because I
wasn't changing them in previous commits. Now I've added extra code
that does test them, and verified it works when backported to commit
b567c9b2b5e159f where I introduced test_conf before beginning the main
refactoring.
A setting can also be specified explicitly as not loaded and saved at
all. There were quite a few commented that way, but now there's a
machine-readable indication of it.
test_conf will now check that all these settings make sense together -
things shouldn't have a save keyword unless they use it, and should
have one if they don't, and shouldn't specify combinations of options
that conflict.
(For that reason, test_conf is now also running the consistency check
before the main test, so that a missing keyword will cause an error
message _before_ it causes a segfault, saving some debugging!)
2023-09-22 15:04:25 +00:00
|
|
|
#define STORAGE_ENUM(x) .storage_enum = &conf_enum_ ## x
|
|
|
|
#define SAVE_CUSTOM .save_custom = true
|
|
|
|
#define LOAD_CUSTOM .load_custom = true
|
|
|
|
#define NOT_SAVED .not_saved = true
|
2023-09-22 11:54:15 +00:00
|
|
|
|
|
|
|
const ConfKeyInfo conf_key_info[] = {
|
|
|
|
#include "conf.h"
|
|
|
|
};
|