cottongin/crosspoint-reader-mod
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
76681201bf9e4e6c5ef16a284fc9fa3747d0f0a4
crosspoint-reader-mod/src/SettingsList.h

137 lines
8.6 KiB
C
Raw Normal View History

feat: A web editor for settings (#667) ## Summary This is an updated version of @itsthisjustin's #346 that builds on current master and also deduplicates the settings list so we don't have two copies of the settings. In the Web UI, it should organize the settings a little closer to what you see on device. ## Additional Context I tested this live on device and it seems to play nicely for me. It's re-based on master since master's settings stuff has moved somewhat since the original PR and addresses the sole review comment #346 - it also means that I don't need to manually key in the URL for my OPDS server. :) --- ### AI Usage My changes were implemented with Claude Opus 4.5 and Claude Code 2.1.25. I don't know if @itsthisjustin's original work used AI assistance. Co-authored-by: Dave Allie <dave@daveallie.com>
2026-02-08 12:46:14 -08:00
#pragma once
feat: User-Interface I18n System (#728) ## Summary **What is the goal of this PR?** This PR introduces Internationalization (i18n) support, enabling users to switch the UI language dynamically. **What changes are included?** - Core Logic: Added I18n class (`lib/I18n/I18n.h/cpp`) to manage language state and string retrieval. - Data Structures: - `lib/I18n/I18nStrings.h/cpp`: Static string arrays for each supported language. - `lib/I18n/I18nKeys.h`: Enum definitions for type-safe string access. - `lib/I18n/translations.csv`: single source of truth. - Documentation: Added `docs/i18n.md` detailing the workflow for developers and translators. - New Settings activity: `src/activities/settings/LanguageSelectActivity.h/cpp` ## Additional Context This implementation (building on concepts from #505) prioritizes performance and memory efficiency. The core approach is to store all localized strings for each language in dedicated arrays and access them via enums. This provides O(1) access with zero runtime overhead, and avoids the heap allocations, hashing, and collision handling required by `std::map` or `std::unordered_map`. The main trade-off is that enums and string arrays must remain perfectly synchronized—any mismatch would result in incorrect strings being displayed in the UI. To eliminate this risk, I added a Python script that automatically generates `I18nStrings.h/.cpp` and `I18nKeys.h` from a CSV file, which will serve as the single source of truth for all translations. The full design and workflow are documented in `docs/i18n.md`. ### Next Steps - [x] Python script `generate_i18n.py` to auto-generate C++ files from CSV - [x] Populate translations.csv with initial translations. Currently available translations: English, Español, Français, Deutsch, Čeština, Português (Brasil), Русский, Svenska. Thanks, community! **Status:** EDIT: ready to be merged. As a proof of concept, the SPANISH strings currently mirror the English ones, but are fully uppercased. --- ### AI Usage Did you use AI tools to help write this code? _**< PARTIALLY >**_ I used AI for the black work of replacing strings with I18n references across the project, and for generating the documentation. EDIT: also some help with merging changes from master. --------- Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> Co-authored-by: yeyeto2788 <juanernestobiondi@gmail.com>
2026-02-16 15:28:42 +02:00
#include <I18n.h>
feat: A web editor for settings (#667) ## Summary This is an updated version of @itsthisjustin's #346 that builds on current master and also deduplicates the settings list so we don't have two copies of the settings. In the Web UI, it should organize the settings a little closer to what you see on device. ## Additional Context I tested this live on device and it seems to play nicely for me. It's re-based on master since master's settings stuff has moved somewhat since the original PR and addresses the sole review comment #346 - it also means that I don't need to manually key in the URL for my OPDS server. :) --- ### AI Usage My changes were implemented with Claude Opus 4.5 and Claude Code 2.1.25. I don't know if @itsthisjustin's original work used AI assistance. Co-authored-by: Dave Allie <dave@daveallie.com>
2026-02-08 12:46:14 -08:00
#include <vector>
#include "CrossPointSettings.h"
#include "KOReaderCredentialStore.h"
#include "activities/settings/SettingsActivity.h"
// Shared settings list used by both the device settings UI and the web settings API.
// Each entry has a key (for JSON API) and category (for grouping).
// ACTION-type entries and entries without a key are device-only.
refactor: Simplify new setting introduction (#1086) ## Summary * **What is the goal of this PR?** Eliminate the 3-file / 4-location overhead for adding a new setting. Previously, every new setting required manually editing JsonSettingsIO.cpp in two places (save + load), duplicating knowledge already present in SettingsList.h. After this PR, JsonSettingsIO.cpp never needs to be touched again for standard settings. * **What changes are included?** * `SettingInfo` (in `SettingsActivity.h`) gains one new field: `bool obfuscated` (base64 save/load for passwords), with a fluent builder method `.withObfuscated()`. The previously proposed `defaultValue`/`withDefault()` approach was dropped in favour of reading the struct field's own initializer value as the fallback (see below). * `SettingsList.h` entries are annotated with `.withObfuscated()` on the OPDS password entry. The list is now returned as a `static const` singleton (`const std::vector<SettingInfo>&`), so it is constructed exactly once. A missing `key`/`category` on the `statusBarProgressBarThickness` entry was also fixed — it was previously skipped by the generic save loop, so changes were silently lost on restart. * `JsonSettingsIO::saveSettings` and `loadSettings` replace their ~90 lines of manual per-field code with a single generic loop over `getSettingsList()`. The loop uses `info.key`, `info.valuePtr`/`info.stringOffset`+`info.stringMaxLen` (for char-array string fields), `info.enumValues.size()` (for enum clamping), and `info.obfuscated`. * **Default values**: instead of a duplicated `defaultValue` field in `SettingInfo`, `loadSettings` reads `s.*(info.valuePtr)` *before* overwriting it. Because `CrossPointSettings` is default-constructed before `loadSettings` is called, this captures each field's struct initializer value as the JSON-absent fallback. The single source of truth for defaults is `CrossPointSettings.h`. * One post-loop special case remains explicitly: the four `frontButton*` remap fields (managed by the RemapFrontButtons sub-activity, not in SettingsList) and `validateFrontButtonMapping()`. * One pre-loop migration guard handles legacy settings files that predate the status bar refactor: if `statusBarChapterPageCount` is absent from the JSON, `applyLegacyStatusBarSettings()` is called first so the generic loop picks up the migrated values as defaults and applies its normal clamping. * OPDS password backward-compat migration (plain `opdsPassword` → obfuscated `opdsPassword_obf`) is preserved inside the generic obfuscated-string path. ## Additional Context Say we want to add a new `bookmarkStyle` enum setting with options `DOT`, `LINE`, `NONE` and a default of `DOT`: 1. `src/CrossPointSettings.h` — add enum and member: ```cpp enum BOOKMARK_STYLE { BOOKMARK_DOT = 0, BOOKMARK_LINE = 1, BOOKMARK_NONE = 2 }; uint8_t bookmarkStyle = BOOKMARK_DOT; ``` 2. `lib/I18n/translations/english.yaml` — add display strings: ```yaml STR_BOOKMARK_STYLE: "Bookmark Style" STR_BOOKMARK_DOT: "Dot" STR_BOOKMARK_LINE: "Line" ``` (Other language files will fall back to English if not translated. Run `gen_i18n.py` to regenerate `I18nKeys.h`.) 3. `src/SettingsList.h` — add one entry in the appropriate category: ```cpp SettingInfo::Enum(StrId::STR_BOOKMARK_STYLE, &CrossPointSettings::bookmarkStyle, {StrId::STR_BOOKMARK_DOT, StrId::STR_BOOKMARK_LINE, StrId::STR_NONE_OPT}, "bookmarkStyle", StrId::STR_CAT_READER), ``` That's it — no default annotation needed anywhere, because `bookmarkStyle = BOOKMARK_DOT` in the struct already provides the fallback. The setting will automatically persist to JSON on save, load with clamping on boot, appear in the device settings UI under the Reader category, and be exposed via the web API — all with no further changes. --- ### AI Usage While CrossPoint doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it helps set the right context for reviewers. Did you use AI tools to help write this code? _**< PARTIALLY>**_
2026-03-01 02:54:58 +01:00
inline const std::vector<SettingInfo>& getSettingsList() {
static const std::vector<SettingInfo> list = {
feat: A web editor for settings (#667) ## Summary This is an updated version of @itsthisjustin's #346 that builds on current master and also deduplicates the settings list so we don't have two copies of the settings. In the Web UI, it should organize the settings a little closer to what you see on device. ## Additional Context I tested this live on device and it seems to play nicely for me. It's re-based on master since master's settings stuff has moved somewhat since the original PR and addresses the sole review comment #346 - it also means that I don't need to manually key in the URL for my OPDS server. :) --- ### AI Usage My changes were implemented with Claude Opus 4.5 and Claude Code 2.1.25. I don't know if @itsthisjustin's original work used AI assistance. Co-authored-by: Dave Allie <dave@daveallie.com>
2026-02-08 12:46:14 -08:00
// --- Display ---
feat: User-Interface I18n System (#728) ## Summary **What is the goal of this PR?** This PR introduces Internationalization (i18n) support, enabling users to switch the UI language dynamically. **What changes are included?** - Core Logic: Added I18n class (`lib/I18n/I18n.h/cpp`) to manage language state and string retrieval. - Data Structures: - `lib/I18n/I18nStrings.h/cpp`: Static string arrays for each supported language. - `lib/I18n/I18nKeys.h`: Enum definitions for type-safe string access. - `lib/I18n/translations.csv`: single source of truth. - Documentation: Added `docs/i18n.md` detailing the workflow for developers and translators. - New Settings activity: `src/activities/settings/LanguageSelectActivity.h/cpp` ## Additional Context This implementation (building on concepts from #505) prioritizes performance and memory efficiency. The core approach is to store all localized strings for each language in dedicated arrays and access them via enums. This provides O(1) access with zero runtime overhead, and avoids the heap allocations, hashing, and collision handling required by `std::map` or `std::unordered_map`. The main trade-off is that enums and string arrays must remain perfectly synchronized—any mismatch would result in incorrect strings being displayed in the UI. To eliminate this risk, I added a Python script that automatically generates `I18nStrings.h/.cpp` and `I18nKeys.h` from a CSV file, which will serve as the single source of truth for all translations. The full design and workflow are documented in `docs/i18n.md`. ### Next Steps - [x] Python script `generate_i18n.py` to auto-generate C++ files from CSV - [x] Populate translations.csv with initial translations. Currently available translations: English, Español, Français, Deutsch, Čeština, Português (Brasil), Русский, Svenska. Thanks, community! **Status:** EDIT: ready to be merged. As a proof of concept, the SPANISH strings currently mirror the English ones, but are fully uppercased. --- ### AI Usage Did you use AI tools to help write this code? _**< PARTIALLY >**_ I used AI for the black work of replacing strings with I18n references across the project, and for generating the documentation. EDIT: also some help with merging changes from master. --------- Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> Co-authored-by: yeyeto2788 <juanernestobiondi@gmail.com>
2026-02-16 15:28:42 +02:00
SettingInfo::Enum(StrId::STR_SLEEP_SCREEN, &CrossPointSettings::sleepScreen,
{StrId::STR_DARK, StrId::STR_LIGHT, StrId::STR_CUSTOM, StrId::STR_COVER, StrId::STR_NONE_OPT,
StrId::STR_COVER_CUSTOM},
"sleepScreen", StrId::STR_CAT_DISPLAY),
SettingInfo::Enum(StrId::STR_SLEEP_COVER_MODE, &CrossPointSettings::sleepScreenCoverMode,
{StrId::STR_FIT, StrId::STR_CROP}, "sleepScreenCoverMode", StrId::STR_CAT_DISPLAY),
SettingInfo::Enum(StrId::STR_SLEEP_COVER_FILTER, &CrossPointSettings::sleepScreenCoverFilter,
{StrId::STR_NONE_OPT, StrId::STR_FILTER_CONTRAST, StrId::STR_INVERTED},
"sleepScreenCoverFilter", StrId::STR_CAT_DISPLAY),
SettingInfo::Enum(StrId::STR_HIDE_BATTERY, &CrossPointSettings::hideBatteryPercentage,
{StrId::STR_NEVER, StrId::STR_IN_READER, StrId::STR_ALWAYS}, "hideBatteryPercentage",
StrId::STR_CAT_DISPLAY),
feat: A web editor for settings (#667) ## Summary This is an updated version of @itsthisjustin's #346 that builds on current master and also deduplicates the settings list so we don't have two copies of the settings. In the Web UI, it should organize the settings a little closer to what you see on device. ## Additional Context I tested this live on device and it seems to play nicely for me. It's re-based on master since master's settings stuff has moved somewhat since the original PR and addresses the sole review comment #346 - it also means that I don't need to manually key in the URL for my OPDS server. :) --- ### AI Usage My changes were implemented with Claude Opus 4.5 and Claude Code 2.1.25. I don't know if @itsthisjustin's original work used AI assistance. Co-authored-by: Dave Allie <dave@daveallie.com>
2026-02-08 12:46:14 -08:00
SettingInfo::Enum(
feat: User-Interface I18n System (#728) ## Summary **What is the goal of this PR?** This PR introduces Internationalization (i18n) support, enabling users to switch the UI language dynamically. **What changes are included?** - Core Logic: Added I18n class (`lib/I18n/I18n.h/cpp`) to manage language state and string retrieval. - Data Structures: - `lib/I18n/I18nStrings.h/cpp`: Static string arrays for each supported language. - `lib/I18n/I18nKeys.h`: Enum definitions for type-safe string access. - `lib/I18n/translations.csv`: single source of truth. - Documentation: Added `docs/i18n.md` detailing the workflow for developers and translators. - New Settings activity: `src/activities/settings/LanguageSelectActivity.h/cpp` ## Additional Context This implementation (building on concepts from #505) prioritizes performance and memory efficiency. The core approach is to store all localized strings for each language in dedicated arrays and access them via enums. This provides O(1) access with zero runtime overhead, and avoids the heap allocations, hashing, and collision handling required by `std::map` or `std::unordered_map`. The main trade-off is that enums and string arrays must remain perfectly synchronized—any mismatch would result in incorrect strings being displayed in the UI. To eliminate this risk, I added a Python script that automatically generates `I18nStrings.h/.cpp` and `I18nKeys.h` from a CSV file, which will serve as the single source of truth for all translations. The full design and workflow are documented in `docs/i18n.md`. ### Next Steps - [x] Python script `generate_i18n.py` to auto-generate C++ files from CSV - [x] Populate translations.csv with initial translations. Currently available translations: English, Español, Français, Deutsch, Čeština, Português (Brasil), Русский, Svenska. Thanks, community! **Status:** EDIT: ready to be merged. As a proof of concept, the SPANISH strings currently mirror the English ones, but are fully uppercased. --- ### AI Usage Did you use AI tools to help write this code? _**< PARTIALLY >**_ I used AI for the black work of replacing strings with I18n references across the project, and for generating the documentation. EDIT: also some help with merging changes from master. --------- Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> Co-authored-by: yeyeto2788 <juanernestobiondi@gmail.com>
2026-02-16 15:28:42 +02:00
StrId::STR_REFRESH_FREQ, &CrossPointSettings::refreshFrequency,
{StrId::STR_PAGES_1, StrId::STR_PAGES_5, StrId::STR_PAGES_10, StrId::STR_PAGES_15, StrId::STR_PAGES_30},
"refreshFrequency", StrId::STR_CAT_DISPLAY),
SettingInfo::Enum(StrId::STR_UI_THEME, &CrossPointSettings::uiTheme,
feat: Lyra screens (#732) ## Summary Implements Lyra theme for some more Crosspoint screens: ![IMG_7960 Medium](https://github.com/user-attachments/assets/5d97d91d-e5eb-4296-bbf4-917e142d9095) ![IMG_7961 Medium](https://github.com/user-attachments/assets/02d61964-2632-45ff-83c7-48b95882eb9c) ![IMG_7962 Medium](https://github.com/user-attachments/assets/cf42d20f-3a85-4669-b497-1cac4653fa5a) ![IMG_7963 Medium](https://github.com/user-attachments/assets/a8f59c37-db70-407c-a06d-3e40613a0f55) ![IMG_7964 Medium](https://github.com/user-attachments/assets/0fdaac72-077a-48f6-a8c5-1cd806a58937) ![IMG_7965 Medium](https://github.com/user-attachments/assets/5169f037-8ba8-4488-9a8a-06f5146ec1d9) ## Additional Context - A bit of refactoring for list scrolling logic --- ### AI Usage While CrossPoint doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it helps set the right context for reviewers. Did you use AI tools to help write this code? _**NO**_ --------- Co-authored-by: Dave Allie <dave@daveallie.com>
2026-02-19 17:16:55 +07:00
{StrId::STR_THEME_CLASSIC, StrId::STR_THEME_LYRA, StrId::STR_THEME_LYRA_EXTENDED}, "uiTheme",
StrId::STR_CAT_DISPLAY),
feat: User-Interface I18n System (#728) ## Summary **What is the goal of this PR?** This PR introduces Internationalization (i18n) support, enabling users to switch the UI language dynamically. **What changes are included?** - Core Logic: Added I18n class (`lib/I18n/I18n.h/cpp`) to manage language state and string retrieval. - Data Structures: - `lib/I18n/I18nStrings.h/cpp`: Static string arrays for each supported language. - `lib/I18n/I18nKeys.h`: Enum definitions for type-safe string access. - `lib/I18n/translations.csv`: single source of truth. - Documentation: Added `docs/i18n.md` detailing the workflow for developers and translators. - New Settings activity: `src/activities/settings/LanguageSelectActivity.h/cpp` ## Additional Context This implementation (building on concepts from #505) prioritizes performance and memory efficiency. The core approach is to store all localized strings for each language in dedicated arrays and access them via enums. This provides O(1) access with zero runtime overhead, and avoids the heap allocations, hashing, and collision handling required by `std::map` or `std::unordered_map`. The main trade-off is that enums and string arrays must remain perfectly synchronized—any mismatch would result in incorrect strings being displayed in the UI. To eliminate this risk, I added a Python script that automatically generates `I18nStrings.h/.cpp` and `I18nKeys.h` from a CSV file, which will serve as the single source of truth for all translations. The full design and workflow are documented in `docs/i18n.md`. ### Next Steps - [x] Python script `generate_i18n.py` to auto-generate C++ files from CSV - [x] Populate translations.csv with initial translations. Currently available translations: English, Español, Français, Deutsch, Čeština, Português (Brasil), Русский, Svenska. Thanks, community! **Status:** EDIT: ready to be merged. As a proof of concept, the SPANISH strings currently mirror the English ones, but are fully uppercased. --- ### AI Usage Did you use AI tools to help write this code? _**< PARTIALLY >**_ I used AI for the black work of replacing strings with I18n references across the project, and for generating the documentation. EDIT: also some help with merging changes from master. --------- Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> Co-authored-by: yeyeto2788 <juanernestobiondi@gmail.com>
2026-02-16 15:28:42 +02:00
SettingInfo::Toggle(StrId::STR_SUNLIGHT_FADING_FIX, &CrossPointSettings::fadingFix, "fadingFix",
StrId::STR_CAT_DISPLAY),
feat: A web editor for settings (#667) ## Summary This is an updated version of @itsthisjustin's #346 that builds on current master and also deduplicates the settings list so we don't have two copies of the settings. In the Web UI, it should organize the settings a little closer to what you see on device. ## Additional Context I tested this live on device and it seems to play nicely for me. It's re-based on master since master's settings stuff has moved somewhat since the original PR and addresses the sole review comment #346 - it also means that I don't need to manually key in the URL for my OPDS server. :) --- ### AI Usage My changes were implemented with Claude Opus 4.5 and Claude Code 2.1.25. I don't know if @itsthisjustin's original work used AI assistance. Co-authored-by: Dave Allie <dave@daveallie.com>
2026-02-08 12:46:14 -08:00
// --- Reader ---
feat: User-Interface I18n System (#728) ## Summary **What is the goal of this PR?** This PR introduces Internationalization (i18n) support, enabling users to switch the UI language dynamically. **What changes are included?** - Core Logic: Added I18n class (`lib/I18n/I18n.h/cpp`) to manage language state and string retrieval. - Data Structures: - `lib/I18n/I18nStrings.h/cpp`: Static string arrays for each supported language. - `lib/I18n/I18nKeys.h`: Enum definitions for type-safe string access. - `lib/I18n/translations.csv`: single source of truth. - Documentation: Added `docs/i18n.md` detailing the workflow for developers and translators. - New Settings activity: `src/activities/settings/LanguageSelectActivity.h/cpp` ## Additional Context This implementation (building on concepts from #505) prioritizes performance and memory efficiency. The core approach is to store all localized strings for each language in dedicated arrays and access them via enums. This provides O(1) access with zero runtime overhead, and avoids the heap allocations, hashing, and collision handling required by `std::map` or `std::unordered_map`. The main trade-off is that enums and string arrays must remain perfectly synchronized—any mismatch would result in incorrect strings being displayed in the UI. To eliminate this risk, I added a Python script that automatically generates `I18nStrings.h/.cpp` and `I18nKeys.h` from a CSV file, which will serve as the single source of truth for all translations. The full design and workflow are documented in `docs/i18n.md`. ### Next Steps - [x] Python script `generate_i18n.py` to auto-generate C++ files from CSV - [x] Populate translations.csv with initial translations. Currently available translations: English, Español, Français, Deutsch, Čeština, Português (Brasil), Русский, Svenska. Thanks, community! **Status:** EDIT: ready to be merged. As a proof of concept, the SPANISH strings currently mirror the English ones, but are fully uppercased. --- ### AI Usage Did you use AI tools to help write this code? _**< PARTIALLY >**_ I used AI for the black work of replacing strings with I18n references across the project, and for generating the documentation. EDIT: also some help with merging changes from master. --------- Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> Co-authored-by: yeyeto2788 <juanernestobiondi@gmail.com>
2026-02-16 15:28:42 +02:00
SettingInfo::Enum(StrId::STR_FONT_FAMILY, &CrossPointSettings::fontFamily,
{StrId::STR_BOOKERLY, StrId::STR_NOTO_SANS, StrId::STR_OPEN_DYSLEXIC}, "fontFamily",
StrId::STR_CAT_READER),
SettingInfo::Enum(StrId::STR_FONT_SIZE, &CrossPointSettings::fontSize,
{StrId::STR_SMALL, StrId::STR_MEDIUM, StrId::STR_LARGE, StrId::STR_X_LARGE}, "fontSize",
StrId::STR_CAT_READER),
SettingInfo::Enum(StrId::STR_LINE_SPACING, &CrossPointSettings::lineSpacing,
{StrId::STR_TIGHT, StrId::STR_NORMAL, StrId::STR_WIDE}, "lineSpacing", StrId::STR_CAT_READER),
SettingInfo::Value(StrId::STR_SCREEN_MARGIN, &CrossPointSettings::screenMargin, {5, 40, 5}, "screenMargin",
StrId::STR_CAT_READER),
SettingInfo::Enum(StrId::STR_PARA_ALIGNMENT, &CrossPointSettings::paragraphAlignment,
{StrId::STR_JUSTIFY, StrId::STR_ALIGN_LEFT, StrId::STR_CENTER, StrId::STR_ALIGN_RIGHT,
StrId::STR_BOOK_S_STYLE},
"paragraphAlignment", StrId::STR_CAT_READER),
SettingInfo::Toggle(StrId::STR_EMBEDDED_STYLE, &CrossPointSettings::embeddedStyle, "embeddedStyle",
StrId::STR_CAT_READER),
SettingInfo::Toggle(StrId::STR_HYPHENATION, &CrossPointSettings::hyphenationEnabled, "hyphenationEnabled",
StrId::STR_CAT_READER),
SettingInfo::Enum(StrId::STR_ORIENTATION, &CrossPointSettings::orientation,
{StrId::STR_PORTRAIT, StrId::STR_LANDSCAPE_CW, StrId::STR_INVERTED, StrId::STR_LANDSCAPE_CCW},
"orientation", StrId::STR_CAT_READER),
SettingInfo::Toggle(StrId::STR_EXTRA_SPACING, &CrossPointSettings::extraParagraphSpacing, "extraParagraphSpacing",
StrId::STR_CAT_READER),
SettingInfo::Toggle(StrId::STR_TEXT_AA, &CrossPointSettings::textAntiAliasing, "textAntiAliasing",
StrId::STR_CAT_READER),
feat: A web editor for settings (#667) ## Summary This is an updated version of @itsthisjustin's #346 that builds on current master and also deduplicates the settings list so we don't have two copies of the settings. In the Web UI, it should organize the settings a little closer to what you see on device. ## Additional Context I tested this live on device and it seems to play nicely for me. It's re-based on master since master's settings stuff has moved somewhat since the original PR and addresses the sole review comment #346 - it also means that I don't need to manually key in the URL for my OPDS server. :) --- ### AI Usage My changes were implemented with Claude Opus 4.5 and Claude Code 2.1.25. I don't know if @itsthisjustin's original work used AI assistance. Co-authored-by: Dave Allie <dave@daveallie.com>
2026-02-08 12:46:14 -08:00
// --- Controls ---
feat: User-Interface I18n System (#728) ## Summary **What is the goal of this PR?** This PR introduces Internationalization (i18n) support, enabling users to switch the UI language dynamically. **What changes are included?** - Core Logic: Added I18n class (`lib/I18n/I18n.h/cpp`) to manage language state and string retrieval. - Data Structures: - `lib/I18n/I18nStrings.h/cpp`: Static string arrays for each supported language. - `lib/I18n/I18nKeys.h`: Enum definitions for type-safe string access. - `lib/I18n/translations.csv`: single source of truth. - Documentation: Added `docs/i18n.md` detailing the workflow for developers and translators. - New Settings activity: `src/activities/settings/LanguageSelectActivity.h/cpp` ## Additional Context This implementation (building on concepts from #505) prioritizes performance and memory efficiency. The core approach is to store all localized strings for each language in dedicated arrays and access them via enums. This provides O(1) access with zero runtime overhead, and avoids the heap allocations, hashing, and collision handling required by `std::map` or `std::unordered_map`. The main trade-off is that enums and string arrays must remain perfectly synchronized—any mismatch would result in incorrect strings being displayed in the UI. To eliminate this risk, I added a Python script that automatically generates `I18nStrings.h/.cpp` and `I18nKeys.h` from a CSV file, which will serve as the single source of truth for all translations. The full design and workflow are documented in `docs/i18n.md`. ### Next Steps - [x] Python script `generate_i18n.py` to auto-generate C++ files from CSV - [x] Populate translations.csv with initial translations. Currently available translations: English, Español, Français, Deutsch, Čeština, Português (Brasil), Русский, Svenska. Thanks, community! **Status:** EDIT: ready to be merged. As a proof of concept, the SPANISH strings currently mirror the English ones, but are fully uppercased. --- ### AI Usage Did you use AI tools to help write this code? _**< PARTIALLY >**_ I used AI for the black work of replacing strings with I18n references across the project, and for generating the documentation. EDIT: also some help with merging changes from master. --------- Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> Co-authored-by: yeyeto2788 <juanernestobiondi@gmail.com>
2026-02-16 15:28:42 +02:00
SettingInfo::Enum(StrId::STR_SIDE_BTN_LAYOUT, &CrossPointSettings::sideButtonLayout,
{StrId::STR_PREV_NEXT, StrId::STR_NEXT_PREV}, "sideButtonLayout", StrId::STR_CAT_CONTROLS),
SettingInfo::Toggle(StrId::STR_LONG_PRESS_SKIP, &CrossPointSettings::longPressChapterSkip, "longPressChapterSkip",
StrId::STR_CAT_CONTROLS),
SettingInfo::Enum(StrId::STR_SHORT_PWR_BTN, &CrossPointSettings::shortPwrBtn,
{StrId::STR_IGNORE, StrId::STR_SLEEP, StrId::STR_PAGE_TURN}, "shortPwrBtn",
StrId::STR_CAT_CONTROLS),
feat: A web editor for settings (#667) ## Summary This is an updated version of @itsthisjustin's #346 that builds on current master and also deduplicates the settings list so we don't have two copies of the settings. In the Web UI, it should organize the settings a little closer to what you see on device. ## Additional Context I tested this live on device and it seems to play nicely for me. It's re-based on master since master's settings stuff has moved somewhat since the original PR and addresses the sole review comment #346 - it also means that I don't need to manually key in the URL for my OPDS server. :) --- ### AI Usage My changes were implemented with Claude Opus 4.5 and Claude Code 2.1.25. I don't know if @itsthisjustin's original work used AI assistance. Co-authored-by: Dave Allie <dave@daveallie.com>
2026-02-08 12:46:14 -08:00
// --- System ---
feat: User-Interface I18n System (#728) ## Summary **What is the goal of this PR?** This PR introduces Internationalization (i18n) support, enabling users to switch the UI language dynamically. **What changes are included?** - Core Logic: Added I18n class (`lib/I18n/I18n.h/cpp`) to manage language state and string retrieval. - Data Structures: - `lib/I18n/I18nStrings.h/cpp`: Static string arrays for each supported language. - `lib/I18n/I18nKeys.h`: Enum definitions for type-safe string access. - `lib/I18n/translations.csv`: single source of truth. - Documentation: Added `docs/i18n.md` detailing the workflow for developers and translators. - New Settings activity: `src/activities/settings/LanguageSelectActivity.h/cpp` ## Additional Context This implementation (building on concepts from #505) prioritizes performance and memory efficiency. The core approach is to store all localized strings for each language in dedicated arrays and access them via enums. This provides O(1) access with zero runtime overhead, and avoids the heap allocations, hashing, and collision handling required by `std::map` or `std::unordered_map`. The main trade-off is that enums and string arrays must remain perfectly synchronized—any mismatch would result in incorrect strings being displayed in the UI. To eliminate this risk, I added a Python script that automatically generates `I18nStrings.h/.cpp` and `I18nKeys.h` from a CSV file, which will serve as the single source of truth for all translations. The full design and workflow are documented in `docs/i18n.md`. ### Next Steps - [x] Python script `generate_i18n.py` to auto-generate C++ files from CSV - [x] Populate translations.csv with initial translations. Currently available translations: English, Español, Français, Deutsch, Čeština, Português (Brasil), Русский, Svenska. Thanks, community! **Status:** EDIT: ready to be merged. As a proof of concept, the SPANISH strings currently mirror the English ones, but are fully uppercased. --- ### AI Usage Did you use AI tools to help write this code? _**< PARTIALLY >**_ I used AI for the black work of replacing strings with I18n references across the project, and for generating the documentation. EDIT: also some help with merging changes from master. --------- Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> Co-authored-by: yeyeto2788 <juanernestobiondi@gmail.com>
2026-02-16 15:28:42 +02:00
SettingInfo::Enum(StrId::STR_TIME_TO_SLEEP, &CrossPointSettings::sleepTimeout,
{StrId::STR_MIN_1, StrId::STR_MIN_5, StrId::STR_MIN_10, StrId::STR_MIN_15, StrId::STR_MIN_30},
"sleepTimeout", StrId::STR_CAT_SYSTEM),
feat: A web editor for settings (#667) ## Summary This is an updated version of @itsthisjustin's #346 that builds on current master and also deduplicates the settings list so we don't have two copies of the settings. In the Web UI, it should organize the settings a little closer to what you see on device. ## Additional Context I tested this live on device and it seems to play nicely for me. It's re-based on master since master's settings stuff has moved somewhat since the original PR and addresses the sole review comment #346 - it also means that I don't need to manually key in the URL for my OPDS server. :) --- ### AI Usage My changes were implemented with Claude Opus 4.5 and Claude Code 2.1.25. I don't know if @itsthisjustin's original work used AI assistance. Co-authored-by: Dave Allie <dave@daveallie.com>
2026-02-08 12:46:14 -08:00
// --- KOReader Sync (web-only, uses KOReaderCredentialStore) ---
SettingInfo::DynamicString(
feat: User-Interface I18n System (#728) ## Summary **What is the goal of this PR?** This PR introduces Internationalization (i18n) support, enabling users to switch the UI language dynamically. **What changes are included?** - Core Logic: Added I18n class (`lib/I18n/I18n.h/cpp`) to manage language state and string retrieval. - Data Structures: - `lib/I18n/I18nStrings.h/cpp`: Static string arrays for each supported language. - `lib/I18n/I18nKeys.h`: Enum definitions for type-safe string access. - `lib/I18n/translations.csv`: single source of truth. - Documentation: Added `docs/i18n.md` detailing the workflow for developers and translators. - New Settings activity: `src/activities/settings/LanguageSelectActivity.h/cpp` ## Additional Context This implementation (building on concepts from #505) prioritizes performance and memory efficiency. The core approach is to store all localized strings for each language in dedicated arrays and access them via enums. This provides O(1) access with zero runtime overhead, and avoids the heap allocations, hashing, and collision handling required by `std::map` or `std::unordered_map`. The main trade-off is that enums and string arrays must remain perfectly synchronized—any mismatch would result in incorrect strings being displayed in the UI. To eliminate this risk, I added a Python script that automatically generates `I18nStrings.h/.cpp` and `I18nKeys.h` from a CSV file, which will serve as the single source of truth for all translations. The full design and workflow are documented in `docs/i18n.md`. ### Next Steps - [x] Python script `generate_i18n.py` to auto-generate C++ files from CSV - [x] Populate translations.csv with initial translations. Currently available translations: English, Español, Français, Deutsch, Čeština, Português (Brasil), Русский, Svenska. Thanks, community! **Status:** EDIT: ready to be merged. As a proof of concept, the SPANISH strings currently mirror the English ones, but are fully uppercased. --- ### AI Usage Did you use AI tools to help write this code? _**< PARTIALLY >**_ I used AI for the black work of replacing strings with I18n references across the project, and for generating the documentation. EDIT: also some help with merging changes from master. --------- Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> Co-authored-by: yeyeto2788 <juanernestobiondi@gmail.com>
2026-02-16 15:28:42 +02:00
StrId::STR_KOREADER_USERNAME, [] { return KOREADER_STORE.getUsername(); },
feat: A web editor for settings (#667) ## Summary This is an updated version of @itsthisjustin's #346 that builds on current master and also deduplicates the settings list so we don't have two copies of the settings. In the Web UI, it should organize the settings a little closer to what you see on device. ## Additional Context I tested this live on device and it seems to play nicely for me. It's re-based on master since master's settings stuff has moved somewhat since the original PR and addresses the sole review comment #346 - it also means that I don't need to manually key in the URL for my OPDS server. :) --- ### AI Usage My changes were implemented with Claude Opus 4.5 and Claude Code 2.1.25. I don't know if @itsthisjustin's original work used AI assistance. Co-authored-by: Dave Allie <dave@daveallie.com>
2026-02-08 12:46:14 -08:00
[](const std::string& v) {
KOREADER_STORE.setCredentials(v, KOREADER_STORE.getPassword());
KOREADER_STORE.saveToFile();
},
feat: User-Interface I18n System (#728) ## Summary **What is the goal of this PR?** This PR introduces Internationalization (i18n) support, enabling users to switch the UI language dynamically. **What changes are included?** - Core Logic: Added I18n class (`lib/I18n/I18n.h/cpp`) to manage language state and string retrieval. - Data Structures: - `lib/I18n/I18nStrings.h/cpp`: Static string arrays for each supported language. - `lib/I18n/I18nKeys.h`: Enum definitions for type-safe string access. - `lib/I18n/translations.csv`: single source of truth. - Documentation: Added `docs/i18n.md` detailing the workflow for developers and translators. - New Settings activity: `src/activities/settings/LanguageSelectActivity.h/cpp` ## Additional Context This implementation (building on concepts from #505) prioritizes performance and memory efficiency. The core approach is to store all localized strings for each language in dedicated arrays and access them via enums. This provides O(1) access with zero runtime overhead, and avoids the heap allocations, hashing, and collision handling required by `std::map` or `std::unordered_map`. The main trade-off is that enums and string arrays must remain perfectly synchronized—any mismatch would result in incorrect strings being displayed in the UI. To eliminate this risk, I added a Python script that automatically generates `I18nStrings.h/.cpp` and `I18nKeys.h` from a CSV file, which will serve as the single source of truth for all translations. The full design and workflow are documented in `docs/i18n.md`. ### Next Steps - [x] Python script `generate_i18n.py` to auto-generate C++ files from CSV - [x] Populate translations.csv with initial translations. Currently available translations: English, Español, Français, Deutsch, Čeština, Português (Brasil), Русский, Svenska. Thanks, community! **Status:** EDIT: ready to be merged. As a proof of concept, the SPANISH strings currently mirror the English ones, but are fully uppercased. --- ### AI Usage Did you use AI tools to help write this code? _**< PARTIALLY >**_ I used AI for the black work of replacing strings with I18n references across the project, and for generating the documentation. EDIT: also some help with merging changes from master. --------- Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> Co-authored-by: yeyeto2788 <juanernestobiondi@gmail.com>
2026-02-16 15:28:42 +02:00
"koUsername", StrId::STR_KOREADER_SYNC),
feat: A web editor for settings (#667) ## Summary This is an updated version of @itsthisjustin's #346 that builds on current master and also deduplicates the settings list so we don't have two copies of the settings. In the Web UI, it should organize the settings a little closer to what you see on device. ## Additional Context I tested this live on device and it seems to play nicely for me. It's re-based on master since master's settings stuff has moved somewhat since the original PR and addresses the sole review comment #346 - it also means that I don't need to manually key in the URL for my OPDS server. :) --- ### AI Usage My changes were implemented with Claude Opus 4.5 and Claude Code 2.1.25. I don't know if @itsthisjustin's original work used AI assistance. Co-authored-by: Dave Allie <dave@daveallie.com>
2026-02-08 12:46:14 -08:00
SettingInfo::DynamicString(
feat: User-Interface I18n System (#728) ## Summary **What is the goal of this PR?** This PR introduces Internationalization (i18n) support, enabling users to switch the UI language dynamically. **What changes are included?** - Core Logic: Added I18n class (`lib/I18n/I18n.h/cpp`) to manage language state and string retrieval. - Data Structures: - `lib/I18n/I18nStrings.h/cpp`: Static string arrays for each supported language. - `lib/I18n/I18nKeys.h`: Enum definitions for type-safe string access. - `lib/I18n/translations.csv`: single source of truth. - Documentation: Added `docs/i18n.md` detailing the workflow for developers and translators. - New Settings activity: `src/activities/settings/LanguageSelectActivity.h/cpp` ## Additional Context This implementation (building on concepts from #505) prioritizes performance and memory efficiency. The core approach is to store all localized strings for each language in dedicated arrays and access them via enums. This provides O(1) access with zero runtime overhead, and avoids the heap allocations, hashing, and collision handling required by `std::map` or `std::unordered_map`. The main trade-off is that enums and string arrays must remain perfectly synchronized—any mismatch would result in incorrect strings being displayed in the UI. To eliminate this risk, I added a Python script that automatically generates `I18nStrings.h/.cpp` and `I18nKeys.h` from a CSV file, which will serve as the single source of truth for all translations. The full design and workflow are documented in `docs/i18n.md`. ### Next Steps - [x] Python script `generate_i18n.py` to auto-generate C++ files from CSV - [x] Populate translations.csv with initial translations. Currently available translations: English, Español, Français, Deutsch, Čeština, Português (Brasil), Русский, Svenska. Thanks, community! **Status:** EDIT: ready to be merged. As a proof of concept, the SPANISH strings currently mirror the English ones, but are fully uppercased. --- ### AI Usage Did you use AI tools to help write this code? _**< PARTIALLY >**_ I used AI for the black work of replacing strings with I18n references across the project, and for generating the documentation. EDIT: also some help with merging changes from master. --------- Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> Co-authored-by: yeyeto2788 <juanernestobiondi@gmail.com>
2026-02-16 15:28:42 +02:00
StrId::STR_KOREADER_PASSWORD, [] { return KOREADER_STORE.getPassword(); },
feat: A web editor for settings (#667) ## Summary This is an updated version of @itsthisjustin's #346 that builds on current master and also deduplicates the settings list so we don't have two copies of the settings. In the Web UI, it should organize the settings a little closer to what you see on device. ## Additional Context I tested this live on device and it seems to play nicely for me. It's re-based on master since master's settings stuff has moved somewhat since the original PR and addresses the sole review comment #346 - it also means that I don't need to manually key in the URL for my OPDS server. :) --- ### AI Usage My changes were implemented with Claude Opus 4.5 and Claude Code 2.1.25. I don't know if @itsthisjustin's original work used AI assistance. Co-authored-by: Dave Allie <dave@daveallie.com>
2026-02-08 12:46:14 -08:00
[](const std::string& v) {
KOREADER_STORE.setCredentials(KOREADER_STORE.getUsername(), v);
KOREADER_STORE.saveToFile();
},
feat: User-Interface I18n System (#728) ## Summary **What is the goal of this PR?** This PR introduces Internationalization (i18n) support, enabling users to switch the UI language dynamically. **What changes are included?** - Core Logic: Added I18n class (`lib/I18n/I18n.h/cpp`) to manage language state and string retrieval. - Data Structures: - `lib/I18n/I18nStrings.h/cpp`: Static string arrays for each supported language. - `lib/I18n/I18nKeys.h`: Enum definitions for type-safe string access. - `lib/I18n/translations.csv`: single source of truth. - Documentation: Added `docs/i18n.md` detailing the workflow for developers and translators. - New Settings activity: `src/activities/settings/LanguageSelectActivity.h/cpp` ## Additional Context This implementation (building on concepts from #505) prioritizes performance and memory efficiency. The core approach is to store all localized strings for each language in dedicated arrays and access them via enums. This provides O(1) access with zero runtime overhead, and avoids the heap allocations, hashing, and collision handling required by `std::map` or `std::unordered_map`. The main trade-off is that enums and string arrays must remain perfectly synchronized—any mismatch would result in incorrect strings being displayed in the UI. To eliminate this risk, I added a Python script that automatically generates `I18nStrings.h/.cpp` and `I18nKeys.h` from a CSV file, which will serve as the single source of truth for all translations. The full design and workflow are documented in `docs/i18n.md`. ### Next Steps - [x] Python script `generate_i18n.py` to auto-generate C++ files from CSV - [x] Populate translations.csv with initial translations. Currently available translations: English, Español, Français, Deutsch, Čeština, Português (Brasil), Русский, Svenska. Thanks, community! **Status:** EDIT: ready to be merged. As a proof of concept, the SPANISH strings currently mirror the English ones, but are fully uppercased. --- ### AI Usage Did you use AI tools to help write this code? _**< PARTIALLY >**_ I used AI for the black work of replacing strings with I18n references across the project, and for generating the documentation. EDIT: also some help with merging changes from master. --------- Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> Co-authored-by: yeyeto2788 <juanernestobiondi@gmail.com>
2026-02-16 15:28:42 +02:00
"koPassword", StrId::STR_KOREADER_SYNC),
feat: A web editor for settings (#667) ## Summary This is an updated version of @itsthisjustin's #346 that builds on current master and also deduplicates the settings list so we don't have two copies of the settings. In the Web UI, it should organize the settings a little closer to what you see on device. ## Additional Context I tested this live on device and it seems to play nicely for me. It's re-based on master since master's settings stuff has moved somewhat since the original PR and addresses the sole review comment #346 - it also means that I don't need to manually key in the URL for my OPDS server. :) --- ### AI Usage My changes were implemented with Claude Opus 4.5 and Claude Code 2.1.25. I don't know if @itsthisjustin's original work used AI assistance. Co-authored-by: Dave Allie <dave@daveallie.com>
2026-02-08 12:46:14 -08:00
SettingInfo::DynamicString(
feat: User-Interface I18n System (#728) ## Summary **What is the goal of this PR?** This PR introduces Internationalization (i18n) support, enabling users to switch the UI language dynamically. **What changes are included?** - Core Logic: Added I18n class (`lib/I18n/I18n.h/cpp`) to manage language state and string retrieval. - Data Structures: - `lib/I18n/I18nStrings.h/cpp`: Static string arrays for each supported language. - `lib/I18n/I18nKeys.h`: Enum definitions for type-safe string access. - `lib/I18n/translations.csv`: single source of truth. - Documentation: Added `docs/i18n.md` detailing the workflow for developers and translators. - New Settings activity: `src/activities/settings/LanguageSelectActivity.h/cpp` ## Additional Context This implementation (building on concepts from #505) prioritizes performance and memory efficiency. The core approach is to store all localized strings for each language in dedicated arrays and access them via enums. This provides O(1) access with zero runtime overhead, and avoids the heap allocations, hashing, and collision handling required by `std::map` or `std::unordered_map`. The main trade-off is that enums and string arrays must remain perfectly synchronized—any mismatch would result in incorrect strings being displayed in the UI. To eliminate this risk, I added a Python script that automatically generates `I18nStrings.h/.cpp` and `I18nKeys.h` from a CSV file, which will serve as the single source of truth for all translations. The full design and workflow are documented in `docs/i18n.md`. ### Next Steps - [x] Python script `generate_i18n.py` to auto-generate C++ files from CSV - [x] Populate translations.csv with initial translations. Currently available translations: English, Español, Français, Deutsch, Čeština, Português (Brasil), Русский, Svenska. Thanks, community! **Status:** EDIT: ready to be merged. As a proof of concept, the SPANISH strings currently mirror the English ones, but are fully uppercased. --- ### AI Usage Did you use AI tools to help write this code? _**< PARTIALLY >**_ I used AI for the black work of replacing strings with I18n references across the project, and for generating the documentation. EDIT: also some help with merging changes from master. --------- Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> Co-authored-by: yeyeto2788 <juanernestobiondi@gmail.com>
2026-02-16 15:28:42 +02:00
StrId::STR_SYNC_SERVER_URL, [] { return KOREADER_STORE.getServerUrl(); },
feat: A web editor for settings (#667) ## Summary This is an updated version of @itsthisjustin's #346 that builds on current master and also deduplicates the settings list so we don't have two copies of the settings. In the Web UI, it should organize the settings a little closer to what you see on device. ## Additional Context I tested this live on device and it seems to play nicely for me. It's re-based on master since master's settings stuff has moved somewhat since the original PR and addresses the sole review comment #346 - it also means that I don't need to manually key in the URL for my OPDS server. :) --- ### AI Usage My changes were implemented with Claude Opus 4.5 and Claude Code 2.1.25. I don't know if @itsthisjustin's original work used AI assistance. Co-authored-by: Dave Allie <dave@daveallie.com>
2026-02-08 12:46:14 -08:00
[](const std::string& v) {
KOREADER_STORE.setServerUrl(v);
KOREADER_STORE.saveToFile();
},
feat: User-Interface I18n System (#728) ## Summary **What is the goal of this PR?** This PR introduces Internationalization (i18n) support, enabling users to switch the UI language dynamically. **What changes are included?** - Core Logic: Added I18n class (`lib/I18n/I18n.h/cpp`) to manage language state and string retrieval. - Data Structures: - `lib/I18n/I18nStrings.h/cpp`: Static string arrays for each supported language. - `lib/I18n/I18nKeys.h`: Enum definitions for type-safe string access. - `lib/I18n/translations.csv`: single source of truth. - Documentation: Added `docs/i18n.md` detailing the workflow for developers and translators. - New Settings activity: `src/activities/settings/LanguageSelectActivity.h/cpp` ## Additional Context This implementation (building on concepts from #505) prioritizes performance and memory efficiency. The core approach is to store all localized strings for each language in dedicated arrays and access them via enums. This provides O(1) access with zero runtime overhead, and avoids the heap allocations, hashing, and collision handling required by `std::map` or `std::unordered_map`. The main trade-off is that enums and string arrays must remain perfectly synchronized—any mismatch would result in incorrect strings being displayed in the UI. To eliminate this risk, I added a Python script that automatically generates `I18nStrings.h/.cpp` and `I18nKeys.h` from a CSV file, which will serve as the single source of truth for all translations. The full design and workflow are documented in `docs/i18n.md`. ### Next Steps - [x] Python script `generate_i18n.py` to auto-generate C++ files from CSV - [x] Populate translations.csv with initial translations. Currently available translations: English, Español, Français, Deutsch, Čeština, Português (Brasil), Русский, Svenska. Thanks, community! **Status:** EDIT: ready to be merged. As a proof of concept, the SPANISH strings currently mirror the English ones, but are fully uppercased. --- ### AI Usage Did you use AI tools to help write this code? _**< PARTIALLY >**_ I used AI for the black work of replacing strings with I18n references across the project, and for generating the documentation. EDIT: also some help with merging changes from master. --------- Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> Co-authored-by: yeyeto2788 <juanernestobiondi@gmail.com>
2026-02-16 15:28:42 +02:00
"koServerUrl", StrId::STR_KOREADER_SYNC),
feat: A web editor for settings (#667) ## Summary This is an updated version of @itsthisjustin's #346 that builds on current master and also deduplicates the settings list so we don't have two copies of the settings. In the Web UI, it should organize the settings a little closer to what you see on device. ## Additional Context I tested this live on device and it seems to play nicely for me. It's re-based on master since master's settings stuff has moved somewhat since the original PR and addresses the sole review comment #346 - it also means that I don't need to manually key in the URL for my OPDS server. :) --- ### AI Usage My changes were implemented with Claude Opus 4.5 and Claude Code 2.1.25. I don't know if @itsthisjustin's original work used AI assistance. Co-authored-by: Dave Allie <dave@daveallie.com>
2026-02-08 12:46:14 -08:00
SettingInfo::DynamicEnum(
feat: User-Interface I18n System (#728) ## Summary **What is the goal of this PR?** This PR introduces Internationalization (i18n) support, enabling users to switch the UI language dynamically. **What changes are included?** - Core Logic: Added I18n class (`lib/I18n/I18n.h/cpp`) to manage language state and string retrieval. - Data Structures: - `lib/I18n/I18nStrings.h/cpp`: Static string arrays for each supported language. - `lib/I18n/I18nKeys.h`: Enum definitions for type-safe string access. - `lib/I18n/translations.csv`: single source of truth. - Documentation: Added `docs/i18n.md` detailing the workflow for developers and translators. - New Settings activity: `src/activities/settings/LanguageSelectActivity.h/cpp` ## Additional Context This implementation (building on concepts from #505) prioritizes performance and memory efficiency. The core approach is to store all localized strings for each language in dedicated arrays and access them via enums. This provides O(1) access with zero runtime overhead, and avoids the heap allocations, hashing, and collision handling required by `std::map` or `std::unordered_map`. The main trade-off is that enums and string arrays must remain perfectly synchronized—any mismatch would result in incorrect strings being displayed in the UI. To eliminate this risk, I added a Python script that automatically generates `I18nStrings.h/.cpp` and `I18nKeys.h` from a CSV file, which will serve as the single source of truth for all translations. The full design and workflow are documented in `docs/i18n.md`. ### Next Steps - [x] Python script `generate_i18n.py` to auto-generate C++ files from CSV - [x] Populate translations.csv with initial translations. Currently available translations: English, Español, Français, Deutsch, Čeština, Português (Brasil), Русский, Svenska. Thanks, community! **Status:** EDIT: ready to be merged. As a proof of concept, the SPANISH strings currently mirror the English ones, but are fully uppercased. --- ### AI Usage Did you use AI tools to help write this code? _**< PARTIALLY >**_ I used AI for the black work of replacing strings with I18n references across the project, and for generating the documentation. EDIT: also some help with merging changes from master. --------- Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> Co-authored-by: yeyeto2788 <juanernestobiondi@gmail.com>
2026-02-16 15:28:42 +02:00
StrId::STR_DOCUMENT_MATCHING, {StrId::STR_FILENAME, StrId::STR_BINARY},
feat: A web editor for settings (#667) ## Summary This is an updated version of @itsthisjustin's #346 that builds on current master and also deduplicates the settings list so we don't have two copies of the settings. In the Web UI, it should organize the settings a little closer to what you see on device. ## Additional Context I tested this live on device and it seems to play nicely for me. It's re-based on master since master's settings stuff has moved somewhat since the original PR and addresses the sole review comment #346 - it also means that I don't need to manually key in the URL for my OPDS server. :) --- ### AI Usage My changes were implemented with Claude Opus 4.5 and Claude Code 2.1.25. I don't know if @itsthisjustin's original work used AI assistance. Co-authored-by: Dave Allie <dave@daveallie.com>
2026-02-08 12:46:14 -08:00
[] { return static_cast<uint8_t>(KOREADER_STORE.getMatchMethod()); },
[](uint8_t v) {
KOREADER_STORE.setMatchMethod(static_cast<DocumentMatchMethod>(v));
KOREADER_STORE.saveToFile();
},
feat: User-Interface I18n System (#728) ## Summary **What is the goal of this PR?** This PR introduces Internationalization (i18n) support, enabling users to switch the UI language dynamically. **What changes are included?** - Core Logic: Added I18n class (`lib/I18n/I18n.h/cpp`) to manage language state and string retrieval. - Data Structures: - `lib/I18n/I18nStrings.h/cpp`: Static string arrays for each supported language. - `lib/I18n/I18nKeys.h`: Enum definitions for type-safe string access. - `lib/I18n/translations.csv`: single source of truth. - Documentation: Added `docs/i18n.md` detailing the workflow for developers and translators. - New Settings activity: `src/activities/settings/LanguageSelectActivity.h/cpp` ## Additional Context This implementation (building on concepts from #505) prioritizes performance and memory efficiency. The core approach is to store all localized strings for each language in dedicated arrays and access them via enums. This provides O(1) access with zero runtime overhead, and avoids the heap allocations, hashing, and collision handling required by `std::map` or `std::unordered_map`. The main trade-off is that enums and string arrays must remain perfectly synchronized—any mismatch would result in incorrect strings being displayed in the UI. To eliminate this risk, I added a Python script that automatically generates `I18nStrings.h/.cpp` and `I18nKeys.h` from a CSV file, which will serve as the single source of truth for all translations. The full design and workflow are documented in `docs/i18n.md`. ### Next Steps - [x] Python script `generate_i18n.py` to auto-generate C++ files from CSV - [x] Populate translations.csv with initial translations. Currently available translations: English, Español, Français, Deutsch, Čeština, Português (Brasil), Русский, Svenska. Thanks, community! **Status:** EDIT: ready to be merged. As a proof of concept, the SPANISH strings currently mirror the English ones, but are fully uppercased. --- ### AI Usage Did you use AI tools to help write this code? _**< PARTIALLY >**_ I used AI for the black work of replacing strings with I18n references across the project, and for generating the documentation. EDIT: also some help with merging changes from master. --------- Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> Co-authored-by: yeyeto2788 <juanernestobiondi@gmail.com>
2026-02-16 15:28:42 +02:00
"koMatchMethod", StrId::STR_KOREADER_SYNC),
feat: A web editor for settings (#667) ## Summary This is an updated version of @itsthisjustin's #346 that builds on current master and also deduplicates the settings list so we don't have two copies of the settings. In the Web UI, it should organize the settings a little closer to what you see on device. ## Additional Context I tested this live on device and it seems to play nicely for me. It's re-based on master since master's settings stuff has moved somewhat since the original PR and addresses the sole review comment #346 - it also means that I don't need to manually key in the URL for my OPDS server. :) --- ### AI Usage My changes were implemented with Claude Opus 4.5 and Claude Code 2.1.25. I don't know if @itsthisjustin's original work used AI assistance. Co-authored-by: Dave Allie <dave@daveallie.com>
2026-02-08 12:46:14 -08:00
// --- OPDS Browser (web-only, uses CrossPointSettings char arrays) ---
feat: User-Interface I18n System (#728) ## Summary **What is the goal of this PR?** This PR introduces Internationalization (i18n) support, enabling users to switch the UI language dynamically. **What changes are included?** - Core Logic: Added I18n class (`lib/I18n/I18n.h/cpp`) to manage language state and string retrieval. - Data Structures: - `lib/I18n/I18nStrings.h/cpp`: Static string arrays for each supported language. - `lib/I18n/I18nKeys.h`: Enum definitions for type-safe string access. - `lib/I18n/translations.csv`: single source of truth. - Documentation: Added `docs/i18n.md` detailing the workflow for developers and translators. - New Settings activity: `src/activities/settings/LanguageSelectActivity.h/cpp` ## Additional Context This implementation (building on concepts from #505) prioritizes performance and memory efficiency. The core approach is to store all localized strings for each language in dedicated arrays and access them via enums. This provides O(1) access with zero runtime overhead, and avoids the heap allocations, hashing, and collision handling required by `std::map` or `std::unordered_map`. The main trade-off is that enums and string arrays must remain perfectly synchronized—any mismatch would result in incorrect strings being displayed in the UI. To eliminate this risk, I added a Python script that automatically generates `I18nStrings.h/.cpp` and `I18nKeys.h` from a CSV file, which will serve as the single source of truth for all translations. The full design and workflow are documented in `docs/i18n.md`. ### Next Steps - [x] Python script `generate_i18n.py` to auto-generate C++ files from CSV - [x] Populate translations.csv with initial translations. Currently available translations: English, Español, Français, Deutsch, Čeština, Português (Brasil), Русский, Svenska. Thanks, community! **Status:** EDIT: ready to be merged. As a proof of concept, the SPANISH strings currently mirror the English ones, but are fully uppercased. --- ### AI Usage Did you use AI tools to help write this code? _**< PARTIALLY >**_ I used AI for the black work of replacing strings with I18n references across the project, and for generating the documentation. EDIT: also some help with merging changes from master. --------- Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> Co-authored-by: yeyeto2788 <juanernestobiondi@gmail.com>
2026-02-16 15:28:42 +02:00
SettingInfo::String(StrId::STR_OPDS_SERVER_URL, SETTINGS.opdsServerUrl, sizeof(SETTINGS.opdsServerUrl),
"opdsServerUrl", StrId::STR_OPDS_BROWSER),
SettingInfo::String(StrId::STR_USERNAME, SETTINGS.opdsUsername, sizeof(SETTINGS.opdsUsername), "opdsUsername",
StrId::STR_OPDS_BROWSER),
SettingInfo::String(StrId::STR_PASSWORD, SETTINGS.opdsPassword, sizeof(SETTINGS.opdsPassword), "opdsPassword",
refactor: Simplify new setting introduction (#1086) ## Summary * **What is the goal of this PR?** Eliminate the 3-file / 4-location overhead for adding a new setting. Previously, every new setting required manually editing JsonSettingsIO.cpp in two places (save + load), duplicating knowledge already present in SettingsList.h. After this PR, JsonSettingsIO.cpp never needs to be touched again for standard settings. * **What changes are included?** * `SettingInfo` (in `SettingsActivity.h`) gains one new field: `bool obfuscated` (base64 save/load for passwords), with a fluent builder method `.withObfuscated()`. The previously proposed `defaultValue`/`withDefault()` approach was dropped in favour of reading the struct field's own initializer value as the fallback (see below). * `SettingsList.h` entries are annotated with `.withObfuscated()` on the OPDS password entry. The list is now returned as a `static const` singleton (`const std::vector<SettingInfo>&`), so it is constructed exactly once. A missing `key`/`category` on the `statusBarProgressBarThickness` entry was also fixed — it was previously skipped by the generic save loop, so changes were silently lost on restart. * `JsonSettingsIO::saveSettings` and `loadSettings` replace their ~90 lines of manual per-field code with a single generic loop over `getSettingsList()`. The loop uses `info.key`, `info.valuePtr`/`info.stringOffset`+`info.stringMaxLen` (for char-array string fields), `info.enumValues.size()` (for enum clamping), and `info.obfuscated`. * **Default values**: instead of a duplicated `defaultValue` field in `SettingInfo`, `loadSettings` reads `s.*(info.valuePtr)` *before* overwriting it. Because `CrossPointSettings` is default-constructed before `loadSettings` is called, this captures each field's struct initializer value as the JSON-absent fallback. The single source of truth for defaults is `CrossPointSettings.h`. * One post-loop special case remains explicitly: the four `frontButton*` remap fields (managed by the RemapFrontButtons sub-activity, not in SettingsList) and `validateFrontButtonMapping()`. * One pre-loop migration guard handles legacy settings files that predate the status bar refactor: if `statusBarChapterPageCount` is absent from the JSON, `applyLegacyStatusBarSettings()` is called first so the generic loop picks up the migrated values as defaults and applies its normal clamping. * OPDS password backward-compat migration (plain `opdsPassword` → obfuscated `opdsPassword_obf`) is preserved inside the generic obfuscated-string path. ## Additional Context Say we want to add a new `bookmarkStyle` enum setting with options `DOT`, `LINE`, `NONE` and a default of `DOT`: 1. `src/CrossPointSettings.h` — add enum and member: ```cpp enum BOOKMARK_STYLE { BOOKMARK_DOT = 0, BOOKMARK_LINE = 1, BOOKMARK_NONE = 2 }; uint8_t bookmarkStyle = BOOKMARK_DOT; ``` 2. `lib/I18n/translations/english.yaml` — add display strings: ```yaml STR_BOOKMARK_STYLE: "Bookmark Style" STR_BOOKMARK_DOT: "Dot" STR_BOOKMARK_LINE: "Line" ``` (Other language files will fall back to English if not translated. Run `gen_i18n.py` to regenerate `I18nKeys.h`.) 3. `src/SettingsList.h` — add one entry in the appropriate category: ```cpp SettingInfo::Enum(StrId::STR_BOOKMARK_STYLE, &CrossPointSettings::bookmarkStyle, {StrId::STR_BOOKMARK_DOT, StrId::STR_BOOKMARK_LINE, StrId::STR_NONE_OPT}, "bookmarkStyle", StrId::STR_CAT_READER), ``` That's it — no default annotation needed anywhere, because `bookmarkStyle = BOOKMARK_DOT` in the struct already provides the fallback. The setting will automatically persist to JSON on save, load with clamping on boot, appear in the device settings UI under the Reader category, and be exposed via the web API — all with no further changes. --- ### AI Usage While CrossPoint doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it helps set the right context for reviewers. Did you use AI tools to help write this code? _**< PARTIALLY>**_
2026-03-01 02:54:58 +01:00
StrId::STR_OPDS_BROWSER)
.withObfuscated(),
feat: split status bar setting (#733) ## Summary This PR aims to reduce the complexity of the status bar by splitting the setting into 5: - Chapter Page Count - Book Progress % - Progress Bar - Chapter Title - Battery Indicator These are located within the new StausBarSettings activity, which also shows a preview of the bar the user has created <img width="513" height="806" alt="image" src="https://github.com/user-attachments/assets/cdf852fb-15d8-4da2-a74f-fd69294d7b05" /> <img width="483" height="797" alt="image" src="https://github.com/user-attachments/assets/66fc0c0d-ee51-4d31-b70d-e2bc043205d1" /> When updating from a previous version, the user's past settings are honoured. ## Additional Context The PR aims to remove any duplication of status bar code where possible, and extracts the status bar rendering into a new component - StatusBar It also adds a new (optional) padding option to the progress bar to allow the status bar to be shifted upwards - this is only intended for use in the settings. --- ### AI Usage While CrossPoint doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it helps set the right context for reviewers. Did you use AI tools to help write this code? No - although did help to decode some C++ errors --------- Co-authored-by: Arthur Tazhitdinov <lisnake@gmail.com>
2026-02-25 10:06:38 +00:00
// --- Status Bar Settings (web-only, uses StatusBarSettingsActivity) ---
SettingInfo::Toggle(StrId::STR_CHAPTER_PAGE_COUNT, &CrossPointSettings::statusBarChapterPageCount,
"statusBarChapterPageCount", StrId::STR_CUSTOMISE_STATUS_BAR),
SettingInfo::Toggle(StrId::STR_BOOK_PROGRESS_PERCENTAGE, &CrossPointSettings::statusBarBookProgressPercentage,
"statusBarBookProgressPercentage", StrId::STR_CUSTOMISE_STATUS_BAR),
SettingInfo::Enum(StrId::STR_PROGRESS_BAR, &CrossPointSettings::statusBarProgressBar,
{StrId::STR_BOOK, StrId::STR_CHAPTER, StrId::STR_HIDE}, "statusBarProgressBar",
StrId::STR_CUSTOMISE_STATUS_BAR),
SettingInfo::Enum(StrId::STR_PROGRESS_BAR_THICKNESS, &CrossPointSettings::statusBarProgressBarThickness,
refactor: Simplify new setting introduction (#1086) ## Summary * **What is the goal of this PR?** Eliminate the 3-file / 4-location overhead for adding a new setting. Previously, every new setting required manually editing JsonSettingsIO.cpp in two places (save + load), duplicating knowledge already present in SettingsList.h. After this PR, JsonSettingsIO.cpp never needs to be touched again for standard settings. * **What changes are included?** * `SettingInfo` (in `SettingsActivity.h`) gains one new field: `bool obfuscated` (base64 save/load for passwords), with a fluent builder method `.withObfuscated()`. The previously proposed `defaultValue`/`withDefault()` approach was dropped in favour of reading the struct field's own initializer value as the fallback (see below). * `SettingsList.h` entries are annotated with `.withObfuscated()` on the OPDS password entry. The list is now returned as a `static const` singleton (`const std::vector<SettingInfo>&`), so it is constructed exactly once. A missing `key`/`category` on the `statusBarProgressBarThickness` entry was also fixed — it was previously skipped by the generic save loop, so changes were silently lost on restart. * `JsonSettingsIO::saveSettings` and `loadSettings` replace their ~90 lines of manual per-field code with a single generic loop over `getSettingsList()`. The loop uses `info.key`, `info.valuePtr`/`info.stringOffset`+`info.stringMaxLen` (for char-array string fields), `info.enumValues.size()` (for enum clamping), and `info.obfuscated`. * **Default values**: instead of a duplicated `defaultValue` field in `SettingInfo`, `loadSettings` reads `s.*(info.valuePtr)` *before* overwriting it. Because `CrossPointSettings` is default-constructed before `loadSettings` is called, this captures each field's struct initializer value as the JSON-absent fallback. The single source of truth for defaults is `CrossPointSettings.h`. * One post-loop special case remains explicitly: the four `frontButton*` remap fields (managed by the RemapFrontButtons sub-activity, not in SettingsList) and `validateFrontButtonMapping()`. * One pre-loop migration guard handles legacy settings files that predate the status bar refactor: if `statusBarChapterPageCount` is absent from the JSON, `applyLegacyStatusBarSettings()` is called first so the generic loop picks up the migrated values as defaults and applies its normal clamping. * OPDS password backward-compat migration (plain `opdsPassword` → obfuscated `opdsPassword_obf`) is preserved inside the generic obfuscated-string path. ## Additional Context Say we want to add a new `bookmarkStyle` enum setting with options `DOT`, `LINE`, `NONE` and a default of `DOT`: 1. `src/CrossPointSettings.h` — add enum and member: ```cpp enum BOOKMARK_STYLE { BOOKMARK_DOT = 0, BOOKMARK_LINE = 1, BOOKMARK_NONE = 2 }; uint8_t bookmarkStyle = BOOKMARK_DOT; ``` 2. `lib/I18n/translations/english.yaml` — add display strings: ```yaml STR_BOOKMARK_STYLE: "Bookmark Style" STR_BOOKMARK_DOT: "Dot" STR_BOOKMARK_LINE: "Line" ``` (Other language files will fall back to English if not translated. Run `gen_i18n.py` to regenerate `I18nKeys.h`.) 3. `src/SettingsList.h` — add one entry in the appropriate category: ```cpp SettingInfo::Enum(StrId::STR_BOOKMARK_STYLE, &CrossPointSettings::bookmarkStyle, {StrId::STR_BOOKMARK_DOT, StrId::STR_BOOKMARK_LINE, StrId::STR_NONE_OPT}, "bookmarkStyle", StrId::STR_CAT_READER), ``` That's it — no default annotation needed anywhere, because `bookmarkStyle = BOOKMARK_DOT` in the struct already provides the fallback. The setting will automatically persist to JSON on save, load with clamping on boot, appear in the device settings UI under the Reader category, and be exposed via the web API — all with no further changes. --- ### AI Usage While CrossPoint doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it helps set the right context for reviewers. Did you use AI tools to help write this code? _**< PARTIALLY>**_
2026-03-01 02:54:58 +01:00
{StrId::STR_PROGRESS_BAR_THIN, StrId::STR_PROGRESS_BAR_MEDIUM, StrId::STR_PROGRESS_BAR_THICK},
"statusBarProgressBarThickness", StrId::STR_CUSTOMISE_STATUS_BAR),
feat: split status bar setting (#733) ## Summary This PR aims to reduce the complexity of the status bar by splitting the setting into 5: - Chapter Page Count - Book Progress % - Progress Bar - Chapter Title - Battery Indicator These are located within the new StausBarSettings activity, which also shows a preview of the bar the user has created <img width="513" height="806" alt="image" src="https://github.com/user-attachments/assets/cdf852fb-15d8-4da2-a74f-fd69294d7b05" /> <img width="483" height="797" alt="image" src="https://github.com/user-attachments/assets/66fc0c0d-ee51-4d31-b70d-e2bc043205d1" /> When updating from a previous version, the user's past settings are honoured. ## Additional Context The PR aims to remove any duplication of status bar code where possible, and extracts the status bar rendering into a new component - StatusBar It also adds a new (optional) padding option to the progress bar to allow the status bar to be shifted upwards - this is only intended for use in the settings. --- ### AI Usage While CrossPoint doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it helps set the right context for reviewers. Did you use AI tools to help write this code? No - although did help to decode some C++ errors --------- Co-authored-by: Arthur Tazhitdinov <lisnake@gmail.com>
2026-02-25 10:06:38 +00:00
SettingInfo::Enum(StrId::STR_TITLE, &CrossPointSettings::statusBarTitle,
{StrId::STR_BOOK, StrId::STR_CHAPTER, StrId::STR_HIDE}, "statusBarTitle",
StrId::STR_CUSTOMISE_STATUS_BAR),
SettingInfo::Toggle(StrId::STR_BATTERY, &CrossPointSettings::statusBarBattery, "statusBarBattery",
StrId::STR_CUSTOMISE_STATUS_BAR),
feat: A web editor for settings (#667) ## Summary This is an updated version of @itsthisjustin's #346 that builds on current master and also deduplicates the settings list so we don't have two copies of the settings. In the Web UI, it should organize the settings a little closer to what you see on device. ## Additional Context I tested this live on device and it seems to play nicely for me. It's re-based on master since master's settings stuff has moved somewhat since the original PR and addresses the sole review comment #346 - it also means that I don't need to manually key in the URL for my OPDS server. :) --- ### AI Usage My changes were implemented with Claude Opus 4.5 and Claude Code 2.1.25. I don't know if @itsthisjustin's original work used AI assistance. Co-authored-by: Dave Allie <dave@daveallie.com>
2026-02-08 12:46:14 -08:00
};
refactor: Simplify new setting introduction (#1086) ## Summary * **What is the goal of this PR?** Eliminate the 3-file / 4-location overhead for adding a new setting. Previously, every new setting required manually editing JsonSettingsIO.cpp in two places (save + load), duplicating knowledge already present in SettingsList.h. After this PR, JsonSettingsIO.cpp never needs to be touched again for standard settings. * **What changes are included?** * `SettingInfo` (in `SettingsActivity.h`) gains one new field: `bool obfuscated` (base64 save/load for passwords), with a fluent builder method `.withObfuscated()`. The previously proposed `defaultValue`/`withDefault()` approach was dropped in favour of reading the struct field's own initializer value as the fallback (see below). * `SettingsList.h` entries are annotated with `.withObfuscated()` on the OPDS password entry. The list is now returned as a `static const` singleton (`const std::vector<SettingInfo>&`), so it is constructed exactly once. A missing `key`/`category` on the `statusBarProgressBarThickness` entry was also fixed — it was previously skipped by the generic save loop, so changes were silently lost on restart. * `JsonSettingsIO::saveSettings` and `loadSettings` replace their ~90 lines of manual per-field code with a single generic loop over `getSettingsList()`. The loop uses `info.key`, `info.valuePtr`/`info.stringOffset`+`info.stringMaxLen` (for char-array string fields), `info.enumValues.size()` (for enum clamping), and `info.obfuscated`. * **Default values**: instead of a duplicated `defaultValue` field in `SettingInfo`, `loadSettings` reads `s.*(info.valuePtr)` *before* overwriting it. Because `CrossPointSettings` is default-constructed before `loadSettings` is called, this captures each field's struct initializer value as the JSON-absent fallback. The single source of truth for defaults is `CrossPointSettings.h`. * One post-loop special case remains explicitly: the four `frontButton*` remap fields (managed by the RemapFrontButtons sub-activity, not in SettingsList) and `validateFrontButtonMapping()`. * One pre-loop migration guard handles legacy settings files that predate the status bar refactor: if `statusBarChapterPageCount` is absent from the JSON, `applyLegacyStatusBarSettings()` is called first so the generic loop picks up the migrated values as defaults and applies its normal clamping. * OPDS password backward-compat migration (plain `opdsPassword` → obfuscated `opdsPassword_obf`) is preserved inside the generic obfuscated-string path. ## Additional Context Say we want to add a new `bookmarkStyle` enum setting with options `DOT`, `LINE`, `NONE` and a default of `DOT`: 1. `src/CrossPointSettings.h` — add enum and member: ```cpp enum BOOKMARK_STYLE { BOOKMARK_DOT = 0, BOOKMARK_LINE = 1, BOOKMARK_NONE = 2 }; uint8_t bookmarkStyle = BOOKMARK_DOT; ``` 2. `lib/I18n/translations/english.yaml` — add display strings: ```yaml STR_BOOKMARK_STYLE: "Bookmark Style" STR_BOOKMARK_DOT: "Dot" STR_BOOKMARK_LINE: "Line" ``` (Other language files will fall back to English if not translated. Run `gen_i18n.py` to regenerate `I18nKeys.h`.) 3. `src/SettingsList.h` — add one entry in the appropriate category: ```cpp SettingInfo::Enum(StrId::STR_BOOKMARK_STYLE, &CrossPointSettings::bookmarkStyle, {StrId::STR_BOOKMARK_DOT, StrId::STR_BOOKMARK_LINE, StrId::STR_NONE_OPT}, "bookmarkStyle", StrId::STR_CAT_READER), ``` That's it — no default annotation needed anywhere, because `bookmarkStyle = BOOKMARK_DOT` in the struct already provides the fallback. The setting will automatically persist to JSON on save, load with clamping on boot, appear in the device settings UI under the Reader category, and be exposed via the web API — all with no further changes. --- ### AI Usage While CrossPoint doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it helps set the right context for reviewers. Did you use AI tools to help write this code? _**< PARTIALLY>**_
2026-03-01 02:54:58 +01:00
return list;
feat: split status bar setting (#733) ## Summary This PR aims to reduce the complexity of the status bar by splitting the setting into 5: - Chapter Page Count - Book Progress % - Progress Bar - Chapter Title - Battery Indicator These are located within the new StausBarSettings activity, which also shows a preview of the bar the user has created <img width="513" height="806" alt="image" src="https://github.com/user-attachments/assets/cdf852fb-15d8-4da2-a74f-fd69294d7b05" /> <img width="483" height="797" alt="image" src="https://github.com/user-attachments/assets/66fc0c0d-ee51-4d31-b70d-e2bc043205d1" /> When updating from a previous version, the user's past settings are honoured. ## Additional Context The PR aims to remove any duplication of status bar code where possible, and extracts the status bar rendering into a new component - StatusBar It also adds a new (optional) padding option to the progress bar to allow the status bar to be shifted upwards - this is only intended for use in the settings. --- ### AI Usage While CrossPoint doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it helps set the right context for reviewers. Did you use AI tools to help write this code? No - although did help to decode some C++ errors --------- Co-authored-by: Arthur Tazhitdinov <lisnake@gmail.com>
2026-02-25 10:06:38 +00:00
}
Reference in New Issue Copy Permalink