all i know is that everyone want good for JME here.
There are advantages and disadvantages.
Pool is good, but people who voted opposite will be sad.
Hope there is some middleground between solutions. Or maybe some “chaos” between platforms might be exception here…
btw. what is problem with error dialog on linux? i thought its only problem on MAC?
If the dialog is shown when the app is fullscreen and grabbing the mouse, the mouse is not released and the window can’t be closed.
If someone can figure out a way to somehow keep the dialog only for old apps but not for new apps.
I just want to fix things so that new devs can run their code on all the supported platforms and get a working result without knowing anything.
I would tell new BetterSimpleApplication, but it would mean examples would work with old one so for used examples, people would still have issues.
If the dialog is shown when the app is fullscreen and grabbing the mouse, the mouse is not released and the window can’t be closed.
hmm, when i think now, i dont remember that there was some error dialog. only remember getting some from SDK. (or maybe i just disabled it, dont remember now)
Is it needed when there is terminal logs anyway? and for production devs make “crash report” anyway?
You only get terminal logs if you ran from a terminal.
My own apps dump their logs to disk already so this one doesn’t really affect my apps… but it DOES affect my ability to support users on the forum who report some weird error and can capture it in the error dialog but might not have been running from the terminal.
Unfortunately not likely. Just enable this one feature. So yeah, there is a chance that then we would have SDK without Mac support still with LWGL 3 even this feature worked.
This seems like a solvable problem. And it’s probably a good idea if JME re-enables the mouse cursor before popping up errors, anyway.
i think better would be just MAC exception for no setting dialog here and fix fullscreen on linux if thats possible.
but anyway i voted.
damn MAC 
Mhh. Since LWJGL2 works fine with awt, would it make people happier if i were to figure out a way to keep both dialogs only when lwjgl2 is used?
EDIT:
The dialogs are ultimately called by JmeDesktopSystem that already uses reflection to load the lwjgl classes.
This solution would work like this:
The JmeDesktopSystem will try to load a class
ctxClazz = Class.forName("com.jme3.system.lwjgl.LwjglDialogs");
if the LwjglDialogs class exists, then it will call LwjglDialogs.showErrorDialog and LwjglDialogs.showSettingsDialog as needed. If it doesn’t exist it will do nothing.
LwjglDialogs will be implemented only in the lwjgl2 module
In my case, when using LWJGL3, when I click on the Ok button in the error dialog window it closes the app improperly and prints this error:
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 20 (X_GetProperty)
Resource id in failed request: 0x4e0005b
Serial number of failed request: 1332
Current serial number in output stream: 1332
I believe it will be a good thing to move away from the dialogs as long as there’s a convenient alternative and a migration path.
When I upgrade a library I always expect a few things to break.
The library Ali linked with an additional pre-built Lemur (or a simple state with vanilla bitmap text) settings option could be a good replacement I think.
Later on a developer could build their own using that as a reference, still I think there should be a simple drop-in alternative.
Settings dialogs were common in the 3dfx era but most modern games (I think, I usually play old stuff) directly lunch to fullscreen and have a settings menu inside the game, I guess this is what gamers and developers expect from a modern engine.
Another reason is proper macos support seems so close. In my experience as a linux user, I built a game recently and only ever tested on my computer, when I asked friends to test it, the ones with windows and linux were able to run it right away with no issues, but the ones with mac couldn’t (I was expecting it somewhat after reading the forum). Multi platform is imo one of the best jme3 advantages.
Reminds me of that scene of The Simpsons where they cancel a children’s hospital construction because they are missing six bricks.
I find the settings dialog to be extremely convenient, but if I have to end up removing it anyway because platform compatibility (someone mentioned Steam), then is not that useful.
Since I switched to LWJGL3 I noticed that rarely (maybe 1 out of 50 times) the settings dialog simply crashes the app and the error dialog never worked anyway so it seems even the current setup isn’t very reliable.
I dislike voting on technical issues, except as a last resort, so I haven’t seen the poll results.
Could we disable the ErrorDialog and SettingDialog on macOS platforms but leave them as the default on Linux and Windows platforms? To me that seems like a good compromise, improving macOS support without breaking existing Linux/Windows apps.
I’d rather not use a non official hacked version of glfw in the core.
New developers will be led to believe their app is fine, and then discover it is either broken or the settings dialog doesn’t show on mac. Also we should remove at least the error dialog from linux aswell.
IMO Settings Dialog / Error Dialog could be some module? if someone need, just load it, add some magic lines(or even not) and he have it.
Seems like a good idea.
The point is that others are actually trying to fix the issue… it is fixable. And if glfw decides not to fix it then that says a lot about long term Mac support in the core library we rely on.
I believe this is a 100% fixable problem.
So if we are just removing things that don’t work properly everywhere then we can probably remove a lot of things.
What do you think about the solution proposed by @oxplay2 ?
The JmeDesktopSystem will try to look for JmeDialogs.class, jme3-awt-dialogs will implement it with the current awt dialogs. You are going to need to include only this new module in gradle.
This also makes it easier to replace the dialogs with something else in mac. Eg. we can have jme3-jfx-dialogs or jme3-swt-dialogs.
I’m ok with a dependency related fix. I was going to propose adding it anyway.
And here is a prediction…
New users will try writing a JME app.
New users will post to the forum “x or y doesn’t work”
Us: you should try changing this app setting.
Them: how do I do that
Us: edit your Java file and add these lines of code or include this jar so you get a nice settings dialog to play with different options.
Repeat a few hundred times and ultimately we build the “settings dialog” into the gradle starter templates so that all new users get it by default and support for new users becomes easier.
Net result: basically where we are now. Users by default have a settings dialog and have to remove it before shipping on the minority platforms that don’t support it (or Steam). They just get to do it in a build file instead of a java file. (Edit: and this is not necessarily a bad difference as it’s way easier to roll dev builds versus release builds this way.)
This is true… but I submit that this was already true or could be handled invisible to the application at any rate. I admit that it will be easier in the future if it is already broken out that way.
If we get this up
It can just propose alternatives to the jme3-awt-dialogs (or a warning) if mac os is selected as platform