To make it simple to add a preference, I created a basic framework where you define preferences a descriptors on the Client class; e.g.,
class Client(...):
# ...
my_preference = IntegerPreference(
display_name=lazy_gettext("My Preference"),
description=lazy_gettext("..."),
default=42,
)
The preference can then be used as follows:
assert client.my_preference == 42, "This should work"
client.set_pref("my_preference", 99)
assert client.my_preference == 99, "This works too"
client.my_preference = 81
assert client.my_preference == 81, "This too!"
This works fairly well, but it results in a UX which isn't quite as fluid as we'd like. For example, IntegerPreference exposes a get_prompt() method which returns a prompt like "Enter an integer between %(min_value)s and %(max_value)s.". In the case of the alert_frequency pref, for example, this result in a prompt like Enter an integer between 0 and 24. Note that we don't mention "hours" anywhere. Context is missing.
So this ticket is really just arguing that there should be a clean way to add more nuance to the prompts generated by these prefs' get_prompt() method. We would like to keep adding a new pref simple while allowing this extra flexibility.
To make it simple to add a preference, I created a basic framework where you define preferences a descriptors on the
Clientclass; e.g.,The preference can then be used as follows:
This works fairly well, but it results in a UX which isn't quite as fluid as we'd like. For example,
IntegerPreferenceexposes aget_prompt()method which returns a prompt like "Enter an integer between %(min_value)s and %(max_value)s.". In the case of thealert_frequencypref, for example, this result in a prompt likeEnter an integer between 0 and 24. Note that we don't mention "hours" anywhere. Context is missing.So this ticket is really just arguing that there should be a clean way to add more nuance to the prompts generated by these prefs'
get_prompt()method. We would like to keep adding a new pref simple while allowing this extra flexibility.