Handling of (custom) anti-features and categories
Anti-Features and categories can now be configured per-repo, which raises some questions on how to deal with that in the client. We were just discussing that in our weekly meeting and collected different ideas:
merging vs. priorities vs. appending
Should those configurations be merged somehow?
The af list could be additive, eg NonFreeNet (Izzy), NonFreeNet (F-Droid), etc and then use the already configured ones to follow the same pattern, eg. If nonfreenet fdroid is on, adding izzy repo nonfreenet is on too
This would make the list in the client rather long and hard to maintain by the user ("bad UX"), and only make sense in edge cases. My proposal would be:
- strongly discourage adjusting standard definitions. Repo maintainers should instead take the definitions from F-Droid (for the categories/antifeatures they use) and only append their custom ones. As custom categories/anti-features can be easily established, there's no longer a need to modify existing ones (my repo will then also stop abusing NonFreeDep and split out the "extra meaning" to NonFreeComp as soon as the stable client supports it properly). We have no way to enforce this, though.
- the client would then just add the custom ones and add them to the list – not merging.
- an open question would be how to deal with this when multiple repos provide their custom AFs/categories, or what makes the list of "standard AFs/categories" (those already known by a previous repo?)
what AF is shown by default, what is opt-in?
Currently, all custom AFs are dealt with the same as NSFW and "Others", i.e. apps carrying them will be invisible by default. Options:
- have the repo defining the default behavior in their config (e.g. new boolean setting: "enabled")
- on first start, bring up a dialog of AFs and let the user choose. Whenever a "new AF" was detected, show a popup to ask for their decision.