vlsi commented on PR #5715: URL: https://github.com/apache/jmeter/pull/5715#issuecomment-1595117111
@weisJ , the workaround with "putting all the custom bundle values to defaults" works for cases like `Actions.cut`, however, it does not heal `JOptionPane.YES_NO_CANCEL_OPTION`. I believe the reason is that: * Darklaf uses `putAll` instead of delegation in https://github.com/weisJ/darklaf/blob/0622af33ba287b33f415e062158dfe4cc7b0d763/core/src/main/java/com/github/weisj/darklaf/DarkLaf.java#L164 In other words, in the ideal case, darklaf should use delegation to the defaults like "try searching the element locally, or delegate to the other UIDefaults if not found". * Java uses custom scheme for resolving `OptionPane.yesButtonText`. It detects that resource bundle does not have exact `OptionPane.yesButtonText` property, however, it attempts loading `OptionPane.yesButtonTextAndMnemonics` instead: https://github.com/openjdk/jdk/blob/197d0cc6031cb470f1bd7678796593ff1bf440ca/src/java.desktop/share/classes/javax/swing/UIDefaults.java#L1351 unfortunately, the automatic attempt for `yesButtonText` -> `yesButtonTextAndMnemonics` happens only for resource ids loaded **from resource bundle**, which, as you know, are loaded only from the system classloader. I would suggest: 1) Stop re-distributing "jdk" bundles in Darklaf 2) Replace `defaults.putAll(baseDefaults);` with something like `MultiUIDefaults` so you delegate to `baseDefaults` rather than get raw values from there I believe it would fix `JOptionPane.YES_NO_CANCEL_OPTION` behaviour and it would simplify Darklaf code as you will no longer need to re-distribute labels for Java default bundles. WDYT? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jmeter.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
