AppSettings font color changes but the background color doesn't

[Ledmington]

I am using jMonkeyEngine 3.5.2 on Ubuntu 20.04.4 with Dark Theme. When i create the AppSettings, i cannot see the text because it is rendered white due to the dark theme. The background, however, remains white. If i change the theme to Light or Standard, the text is rendered as black on white.

[stephengold]

Thanks for documenting this issue.

[pavly-gerges]

I think if we want to fix this, we may try to set an explicit look and feel for the jframe SettingsDialog.

[pavly-gerges]

I faced the same problem today, I am using Zorin OS (bionic Ubuntu) a distribution based on Ubuntu, however, if running 2 jme3-apps in synchronicity, the 1st app has the problem and the second one doesn't, I believe its something with Swing UIManager LAF.

[pspeed42]

It may have to do with the fact that we create the settings dialog, root panel, etc... before ever setting the LAF.

Frankly, it's rude for this class to decide to set the LAF but improper to set it after the dialog has already been created anyway. It's quite likely that the children are inheriting the parent LAF settings on some level.

A perhaps more "correct" way would be to set it statically... BUT even though it will ugly up folks programs, maybe just don't set the LAF at all. Let the application decide.

[pavly-gerges]

I cannot reproduce the problem on TestChooser, i guess yeah, it's because it sets the LAF before the start:
https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-examples/src/main/java/jme3test/TestChooser.java#L461-L467

A perhaps more "correct" way would be to set it statically... BUT even though it will ugly up folks programs, maybe just don't set the LAF at all. Let the application decide.

yeah, probably, but who knows the value of swing.defaultlaf at runtime, and if the user sets the look and the feel of their app (supposedly if they use swing as their client), things may go wrong on the SettingsDialog...

A perhaps more "correct" way would be to set it statically

I think this solution is far better, and enable the user to simply change the LAF is very easy to do, so we set a default LAF (System native LAF), but users can set their own too.

From java docs:

Default look and feel
The class used for the default look and feel is chosen in the following manner:
- If the system property swing.defaultlaf is non-null, use its value as the default look and feel class name.
- If the [Properties](https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html) file swing.properties exists and contains the key swing.defaultlaf, use its value as the default look and feel class name. The location that is checked for swing.properties may vary depending upon the implementation of the Java platform. Typically the swing.properties file is located in the lib subdirectory of the Java installation directory. Refer to the release notes of the implementation being used for further details.
- Otherwise use the cross platform look and feel.

[pspeed42]

The problem with how the code is now is that if my app sets a dark theme in main() like most apps that set LAF will do then the settings dialog will wipe it out. (I think the only reason I've avoided this personally is because I don't use the settings dialog for my apps that set a dark theme because they embed a JME canvas window.)

The settings dialog is not doing anything crazy. It should work with whatever LAF the app has selected assuming that LAF is functional in the way that normal controls still work. (Broken LAFs are broken and so will be broken.)

Edit: and swing apps work just fine without a LAF set and JME will work just fine without a LAF set... it just won't look native.

[pavly-gerges]

Yeah, that is right and if the user wants for some reason to change the LAF of jme settings even if they don't use Swing, they can simply use the UIManager#setLookAndFeel(String) in their static initilizers.

Great, so the fix for this is to simply remove callbacks to LAF UIManager.

[pavly-gerges]

But wait a minute, the original problem was that we set the LAF after the start of the SettingsDialog, so before that the LAF was defaulted to the Swing LAF and that comes with the problem above...if that is the case then the correct solution is to set the LAF explicitly to the system native LAF before start.

I mean the problem appears when not setting the LAF explicitly, so we need to correct it to be before the start.

[pavly-gerges]

But wait a minute, the original problem was that we set the LAF after the start of the SettingsDialog, so before that the LAF >was defaulted to the Swing LAF and that comes with the problem above...if that is the case then the correct solution is to set >the LAF explicitly to the system native LAF before start.
I mean the problem appears when not setting the LAF explicitly, so we need to correct it to be before the start.

@pspeed42 , i was wrong, i tested it when removing the UIManager#setLookAndFeel(String) and it defaults to the swing LAF without any problems, seems setting up UIManager#setLookAndFeel(String) after the start breaks up the LAF, so you are right we should remove it and let the swing decide and the user has ability to change it too, so its a win-win situation.

[pspeed42]

Glad to know my Swing experience was useful for something. I was a hardcore Swing app developer since the times when you had to download Swing as a separate library. Been in and out of the Swing source code many many times.

My guess as to the issue is that the JFrame was created with the metal look and feel which I think makes the window background white/gray (metal color I guess, lol). Then the native LAF gets set which has a Label font color that is also white/gray. So new labels get created with that and they don't show up. It's still a little weird, though, because Swing is supposed to be able to handle that... but anything this far out on an edge case is best just avoided.

...with the extra bonus that applications can now set their own LAF if they use Swing for other things.

[pavly-gerges]

Yeah, and it defaults now to the Metal LAF.

[tonihele]

Fixed via #1827