Simulator: split Skins menu, fix Native Theme menu, add regression test#4984
Merged
Merged
Conversation
…ion test The Skin Designer landing moved every shipped skin behind a "Legacy Skins" submenu. That was overreach: the framework default, the desktop pseudo-skins, and any local skin the user picks via Add Skin all belong at the top level. Only the codenameone.com OTA downloads (and the gallery that fetches them) are "legacy." createSkinsMenu now partitions the "skins" preference via a new classifySkin helper that canonicalises paths and checks whether they live under ~/.codenameone/. A single ButtonGroup spans the top-level radios and the Legacy submenu so the active skin shows as selected wherever it lives. Desktop.skin / UWP Desktop.skin are radios in that same group so the active chrome mode is visible at a glance. Add Skin now calls addSkinName immediately so a picked skin shows up at the top level even if the user dismisses the reload before loadSkinFile's own addSkinName runs. While testing the menu, the Native Theme submenu turned out to be silently broken for the modern themes: Ports/JavaSE/build.xml copied iOS7Theme.res and winTheme.res into the JavaSE jar but not iOSModernTheme.res or AndroidMaterialTheme.res, so a menu pick of "iOS Modern" or "Android Material" resolved through getResourceAsStream to null and fell back to the embedded theme. Add the modern themes (plus the Android legacy pair) to the ant copy with failonerror=false, matching the existing maven pom pattern. Cover the menu's reload path with an integration screenshot test. A new currentSimulatorNativeTheme static on JavaSEPort captures the override key that loadSkinFile actually resolved; the SimulatorModeTestApp reads it back and emits a PASS/FAIL line to both stdout and a sentinel file. SimulatorWindowModeVerifier gained --native-theme, which writes the simulatorNativeTheme preference exactly the way the menu does, then asserts the sentinel reports PASS. The runner script invokes scripts/build-native-themes.sh before the ant build so fresh checkouts have the modern .res files ready, and adds four new scenarios (iOSModernTheme, iOS7Theme, AndroidMaterialTheme, android_holo_light) to lock the regression. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Collaborator
Author
|
Compared 11 screenshots: 11 matched. |
Contributor
The test app's init() loaded /theme.res and silently ignored the IOException when it wasn't present. That left UIManager at the bare DefaultLookAndFeel, so every captured screenshot rendered with the same unstyled chrome regardless of which simulatorNativeTheme the verifier was exercising. The PASS assertion fired because JavaSEPort.nativeThemeRes was loaded - the UI just never reflected it. Install the native theme directly when no app theme is bundled, via Display.installNativeTheme() (JavaSEPort.loadSkinFile has already cached nativeThemeRes by the time init() runs, so this is a non-allocating push into UIManager). Now the screenshot for iOS Modern, Android Material, iOS 7 and Android Holo Light each renders with the corresponding chrome - confirmed locally on macOS: rounded blue iOS buttons, Material purple raised buttons, flat iOS 7, and HOLO all-caps respectively. Enrich the test form with the global Toolbar, a CheckBox, and a TextField so the captured screenshot carries enough theme-bearing chrome to make the active theme obvious - a screenshot with only two plain buttons looks nearly identical across themes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Locks the four new javase-single-native-theme-* scenarios to a baseline so the cn1ss compare step has something concrete to diff against. Captured locally on macOS (1470x956); CI's Xvfb run (2200x1400) will produce a diff comment on the first PR build, which is the normal cn1ss flow for adopting fresh baselines into the Linux-rendered canonical set. Each baseline visibly carries the expected native theme: - iOS Modern: rounded blue buttons, modern iOS title bar - iOS 7: flat blue/grey 2014-era chrome - Android Material: raised purple buttons, Material title chrome - Android Holo Light: all-caps button labels in light blue This confirms that the simulatorNativeTheme preference the "Native Theme" menu writes flows all the way through to a visually distinct UI, not just through the static JavaSEPort.getCurrentSimulatorNativeTheme() assertion the test already had. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replace the macOS-captured goldens (1470x956, wrong resolution + unrelated terminal in the background) with the Linux Xvfb captures from CI run 26092505053 on this branch. These reflect the current SimulatorModeTestApp shape: global Toolbar with the hamburger icon, CheckBox + TextField in the body, and the Native Theme menu entry on the simulator menu bar. Includes the four new native-theme baselines for iOS Modern, iOS 7, Android Material, and Android Holo Light - each visually distinct as expected (rounded blue iOS buttons, flat iOS 7 chrome, raised purple Material buttons, all-caps Holo labels). Refreshes the seven pre-existing scenarios too - they shifted because the test app now embeds a Toolbar + extra theme-bearing components. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
ButtonGroupspans both levels so the active skin shows as selected wherever it lives. Add Skin now persists the pick to theskinspreference immediately (it relied onloadSkinFileon the reload path before, so the entry could vanish if the reload was dismissed).iOS ModernandAndroid Material. The antPorts/JavaSE/build.xmlonly copiediOS7Theme.resandwinTheme.resinto the JavaSE jar, so a menu pick of either modern theme hitJavaSEPort.class.getResourceAsStream("/iOSModernTheme.res") == nulland silently fell back to the embedded theme. Added the modern + Android legacy themes to the ant copy withfailonerror=false, matching the existing maven pom pattern.native-theme-*scenarios that drive the same preference + reload mechanism the menu uses and assert the simulator actually loaded the expected.res. A newJavaSEPort.getCurrentSimulatorNativeTheme()exposes the resolved override key;SimulatorModeTestAppreads it back, writes aresult=PASS|FAILline, and the verifier asserts on it. The runner now invokesscripts/build-native-themes.shbefore the ant build so fresh checkouts have the CSS-compiled.resfiles ready.Test plan
Test JavaSE simulator integration scriptsworkflow runs the four newjavase-single-native-theme-*scenarios green.skinvia Add Skin, then dismiss the reload prompt — verify the entry persists in the menu on next open🤖 Generated with Claude Code