Community Poll: Keep or Drop SettingsDialog and ErrorDialog in future versions of the engine

After the discussion happened here: MacOS support overhaul, Apple M1 and breaking changes
We didn’t manage to agree on whether to keep or drop these two dialogs.
So, here is a poll for the community to vote.

Keep or Drop SettingsDialog and ErrorDialog
  • Drop SettingsDialog and Drop ErrorDialog
  • Keep SettingsDialog and Keep ErrorDialog
  • Drop SettingsDialog and Keep ErrorDialog
  • Keep SettingsDialog and Drop ErrorDialog

0 voters

What will change

If voted to keep, things will stay as they are now.
If voted to drop:

  • the SettingsDialog will be removed from the internal code
  • the ErrorDialog will be replaced by a callback JmeSystem.setErrorMessageHandler((message)->{ /* */ }); that will output to console stderr by default

There will be a migration path to allow devs to add these dialogs back into their apps if they wish to keep using them, with the following code

AppSettings settings=new AppSettings(true);


Reasons to drop

  • Settings Dialog Unsupported in MacOS: the settings dialog causes the app to hang and never start, must be disabled manually with app.setShowSettings(false);
  • ErrorDialog issues with fullscreen in linux: Prevent mouse release on crash in some desktop environments
  • Needs to initialize AWT just for one window
  • New Error Handler callback simplifies integration with error reporting services

Reasons to keep

  • Old apps may rely on SettingsDialog for their configurations: Developers that wish to update to the new engine release will have to implement the migration code in their apps to restore functionality
  • No ErrorDialog by default: Unless the migration code is implemented or the error dialog is replaced with something else, errors will be printed only to the console and thus visible only if the app is launched from the terminal or from an editor debugger

You can read the full discussion here: MacOS support overhaul, Apple M1 and breaking changes