Settings > Apps: make the tab a list of apps, with per-app settings pages

[vishae]

Following your note in #132 about the fork having grown "a massive variety of customizable settings and all kinds of built-in apps", and wanting to step back and simplify — this is one concrete piece of that, and I'd be glad to do the work if you like the shape of it.

The problem. Settings > Apps is one flat list of ~41 rows across 6 sections (Sync Day, Reading Stats, Achievements, Apps, Flashcards, Shortcuts). Reaching any one app's settings means scrolling past every other app's, and it grows each time an app gains an option — so it gets worse rather than settling.

The suggestion. The Apps tab lists apps; selecting one opens that app's own settings page. That's not a new pattern — Settings > System > KOReader Sync and Settings > System > OPDS servers already work exactly this way, each an entry leading to its own page. This would bring the Apps tab in line with that, so the tab becomes a handful of rows and any app's settings are one press away.

Why it might suit the refactor. It reduces the settings surface rather than adding to it, it's mechanical rather than behavioural (same settings, same values, different navigation), and future app settings become additive to one page instead of lengthening a shared list.

Things I'd want your call on first:

• Whether every app block should get a page, or whether the short ones are better left inline
• Whether settings should keep living in the existing SettingsList registry so JSON load/save is untouched, with only presentation changing — my assumption, but it's your structure
• Whether now is simply the wrong moment, given you're mid-refactor and this touches SettingsActivity.cpp

Happy to prototype on my fork first so you can see it on-device before deciding.

[vishae]

I've built this in my fork now, so here's what it turned out to be in practice — including one consequence that's a behaviour change rather than a presentation one.

The Apps tab ends up as five rows — Sync Day, Reading Stats, Achievements, Cover Grid, Shortcuts — each opening that app's own settings page, drawn the same way Settings > System > KOReader Sync and > OPDS servers already draw theirs.

Everything else in the tab turned out to be a second route to something already reachable. The bare launchers (Highlights, Favorites, Screen clean, Sleep, If found), each app's own self-launcher, and Reading stats' Heatmap and Profile rows are all registered shortcuts, so the Apps screen already carries them via getConfiguredShortcuts(SHORTCUT_APPS). Flashcards leaves the tab entirely, since its two settings are already editable inside the app.

The trade-off worth raising: shortcut location and visibility are user-configurable, so an app hidden from the Apps screen — or moved to Home — currently still has a guaranteed way in through Settings. Dropping the launchers removes that fallback. It's reversible from Settings > Shortcuts > Shortcut visibility, so nothing is permanently stranded, but it is a real change in behaviour and I'd rather raise it than have it turn up in a diff. If you'd prefer to keep that fallback, the alternative is to keep launcher rows for the apps whose settings pages exist and drop only the duplicates — a shorter tab, but not as short.

One surprise on cost. I expected the restructure to cost a few hundred bytes of flash. It ends up 280 bytes below where it started, because the Apps tab had its own list renderer to lay out its section headers, and with the tab down to five plain rows that renderer had nothing left to do. Deleting it also fixed something I hadn't noticed until I was testing on device: that renderer drew the selected row differently from GfxRenderer's ordinary list, so the Apps tab had never quite matched the rest of Settings. RAM is +80 bytes.

So: 47 rows to 5, one list renderer fewer, and 280 bytes of flash back.

A question rather than a proposal, since I don't use flashcards and can't judge it: should Study mode and Session size move the other way — out of FlashcardSettingsActivity and into Settings, so every app configures from the same place? My own reasoning ran against it, for what that's worth: both look like things you'd change as you start a session rather than configuration you set once, so moving them would add a trip out to Settings and back for the people who actually use the feature. But that's a guess about a workflow I don't have. How do people use it?

Happy to open a PR if the shape looks right to you, or to adjust the launcher question first.