There are a couple issues with that… to use Lemur you have to first bootstrap a whole jME window, and hope the settings that you’re going to be adjusting in the settings window are OK and don’t cause a crash. If they are a problem, you’re permanently locked out until you hunt down and manually override the saved settings. You also have hard choices to make between launching a whole new JVM or dealing with having multiple SimpleApplication instances (settings + the main application) in the same JVM (which don’t tend to play nicely).
Lemur is a fantastic toolkit once you have a jME instance up and running, but it’s not really a substitute for desktop-native UI toolkits.
I tend to either go for a custom external settings panel like the javafx one i made, or let the user change it in-game and restart. Neither are better or worse.
On initialize it should create and attach WindowUpdaterState and on clean up it should detach it.
On enable it attaches windows to GUI node and also enables the WindowUpdaterState on disable it detaches windows from GUI node and disables WindowUpdaterState.
Also this way it will be freely available for other app states to add/remove their windows.
I think my original thinking was that it is a WindowManager that has an update loop, and is not necessarily an Application State itself, though I can see how those thought processes can kind of cross over into one another. I also didn’t want people using the StateManager to get the WindowManager. It felt more elegant calling DevKit.getInstance().getWindowManager(). But if the devkit didnt exist, an appstate would have made far more sense.
I guess with programming ethics aside it would make things a lot easier. I mean if it makes it more usable then there’s no harm.