MacOS support overhaul, Apple M1 and breaking changes

I’m by no means an expert in maintaining libraries, but if I would be asked which behaviour I would prefer as a consumer, it would probably be in line with what Paul says - Silently changing behaviours is not very good. In fact, I would even prefer the nuclear option of forcing the user to specify if he wants the settings dialog or not over that. So that it doesn’t even compile without. Obviously this is a breaking change as well, but it would at least ensure that people choose the correct setting and don’t silently break (or even modify) something that they are unaware of. Usually the first thing after upgrading a library for me is checking if the whole thing still compiles. And if it does, I assume that all behaviours are still the same. But as I said, forcing the user to specify what he wants is the most “nuclear” option I can imagine. Still I personally would prefer it to switching the settings dialog off by default. There I even see the problem of apps not “breaking”, but simply “relying” on the settings dialog to… well, set settings. Otherwise a completely new user is stuck with the default 600x480 resolution or whatever the internal default settings are.
If jME wants breaking changes like these or if it tries to be as backwards-compatible as possible (what would be in line with keeping the major version 3), is up to the Core team. Those are just my opinions on the topic.


We either make a breaking change of some sort or leave the engine Broken By Default in some platforms.


And by the way, for those who care, there is also a “jme-graphics” library that lets you change the app settings at runtime, one can also write a UI for that. For my own game, I would use this approach instead of JME’s SettingsDialog anyway.


…which may never affect some users. And when it does, they can turn off that feature.

While we are on this subject, what is the lwjgl3 solution for embedding a window in a swing app. “Don’t do it?” Or?

How does the SDK do it? Or is it stuck on older lwjgl?

I don’t think we can say to support a platform if the engine is broken by default in said platform

1 Like

Lwjgl3 can’t be embedded in canvas components.
Some solutions that use offscreen rendering were proposed (similar to the javafx embedding), not sure if one was merged.

How does the SDK do it? Or is it stuck on older lwjgl?

the engine is stuck to lwjgl2 afaik

1 Like

SDK is stuck on LWJGL 2 for the time being. But it should be totally doable to have the embedded canvas functionality re-introduced. TestCanvas crashes with LWJGL3 · Issue #1192 · jMonkeyEngine/jmonkeyengine · GitHub, with the help of GitHub - LWJGLX/lwjgl3-awt: AWT support for LWJGL3. LibGDX did this for example.

That would at least in theory let the SDK use LWJGL 3.

1 Like

The engine isn’t broken by default… the user’s particular app setup would be. Then they add a line of code and the problem goes away.

…just like you are talking about making everyone else do.

…but this would not also fix our current problems with AWT?

If i download the engine and start an example, it won’t work on mac

1 Like

So we are already spreading mac-specific code around the engine, why not here, too?

1 Like

We already had worst breaking changes in the past, to name few:

  • Minnaert lighting was removed from the Lighting shader
  • SimpleApplication was refactored and split in LegacyApplication
  • Bullet native was removed from the engine repo

I don’t understand why we are so adamant in keeping the dependency to a 20 years old desktop only half broken library

1 Like

We’d have to remove the error dialog for linux and macos, and the settings dialog for macos, and hope to not have more issues in the future.
And the developer would have to know to expect a setting dialog in windows and linux but not on mac, and an error dialog in windows but not on mac and linux. Doesn’t seem a very good approach.

And apparently affected almost no one.

And affected almost no one. SimpleApplication essentially didn’t change at all. The only ones affected were the ones who extended Application directly and then they had to switch “extends Application” to “extends LegacyApplication”. Otherwise, at worst it was a recompile to pick up new method signatures.

In fact, the whole point of all of that was to allow us to make future changes without breaking users… because we used to care about that more than we do now.

…which is only a dependency change and only affected applications that used bullet native. (My point of view is anecdotal at best but not a single one of my 40+ runnable JME applications used bullet native.)

…but all 40+ of those applications would be affected by removing the settings dialog.

Because Java does not provide a UI alternative and applications sometimes need a UI outside of OpenGL… like for a settings dialog. Swing/AWT is still Java’s answer to a UI in the versions of Java that we support. If JavaFX had actually replaced swing or some OtherNewHotness™ UI… then this would be a different conversation.

I’ve never had a problem with the error dialog on linux. I never ever run full screen so maybe that’s the issue for me.

…but anyway, what you are describing is lowering the quality of the windows version to match deficiencies in other OS’s… which also doesn’t seem like a good approach.

If we have some better features on Windows then why not enable them? We already support more things on desktop than we do on Android, for example.

If the community decides to remove the error dialog (and maybe even if they don’t), I STRONGLY recommend that we start dumping the error information to disk on desktop.

1 Like

All those things you said affected nobody, affected me and required more or the same work needed to adequate to the changes discussed in this thread.

Almost everyone in the world runs games in fullscreen.

I am asking to remove something that doesn’t work in some theoretically supported platforms and has known and possibly unknown bugs and requires to initialize an entire stack of graphical apis just for one window.

So remove it from the platforms where it doesn’t work like we do for other features that don’t work on some platforms.

I disagree, this is chaotic.

Well, I’m apparently speaking for no one so go ahead and do what you want to do or make a poll.

If there are lurker users out there who care about this then now is the time to weigh in because I’ve been around the circular arguments a few too many times already.

Peace out.

1 Like

Yes, since we can’t find a common ground, I think we should make a poll