container default

[kingokksa]

feat(containers): show Default badge on the default container card
feat(containers): add 'Set as default' to container overflow menu
i18n(containers): translate container-default strings

[maxjivi05]

Nice feature, and the translations are complete across all 23 locales — thanks for that. I built it and tried it on a device. One real problem:

"Set as default" doesn't do anything for ARM64EC containers.getPreferredGameContainer() only reads default_x86_container_id — I checked every caller (UnifiedActivityLaunch, UnifiedActivityDrawer, ShortcutSettingsComposeDialog, ContainerUtils) and the arm64 pref is never consulted on any new-game path. So setting an ARM64EC container as default writes the pref and shows the badge, and the toast says "ARM64EC container set as default for new games" — but new games still use the x86 default. Either teach getPreferredGameContainer to pick by architecture, or don't offer the menu item on arm64 containers so the toast isn't misleading.

Two containers show the "Default" badge at the same time. On a fresh install the wizard sets both prefs, and isDefault = id == defaultX86 || id == defaultArm64 marks both cards. You get two identical "Default" pills with no way to tell which is which. The toast already distinguishes the architecture — the badge probably should too ("Default (x86-64)" / "Default (ARM64EC)").

Smaller things:

• getPreferredGameContainer guards with if (preferredId > 0) because 0 means unset (and RETRO_CONTAINER_ID is 0). The badge check doesn't have that guard — worth matching for consistency.
• runCatching { ... }.getOrDefault(container.getWineVersion().contains("arm64ec", ...)) evaluates the fallback on every call, including when the runCatching succeeds, since Kotlin evaluates the argument eagerly. getOrElse { ... } is probably what you want.
• ContentsManager(ctx).syncContents() runs on the main thread in the click handler and walks every content directory. It's only there to work out one boolean that the fallback already approximates.

Could you post a screenshot showing what happens after setting an ARM64EC container as default and then launching a new game — specifically which container it actually ends up using? That's the part I'd like confirmed before this merges.

[kingokksa]

I believe the default container for new games simply needs to be the most universal and commonly used setting that the user picks for their specific device. Therefore, I only provide a single default container option, rather than strictly differentiating between ARM64 and x86. If future feature changes require improvements, we can always revisit this design and add per-architecture logic at that time.