Open qurben opened 2 years ago
So according to the error something should be done from the main thread, but I am not sure if it is possible to do this from Java code.
You'll want to add the -XstartOnFirstThread
argument either to the VM Arguments or the command line, depending on where you're running your code from.
Thanks for the response! With -XstartOnFirstThread
the application doesn't seem to start. (I sadly do not have direct access to a mac where I can do testing on, got someone to test it with this flag)
I did come across this one, where it is mentioned that:
You can’t use Swing with lwjgl3 on OSX. As far as I know, there isn’t a way around that still.
Is that also what is happening here?
I believe so, and if I remember correctly (I may well not), the backend for both Swing and GLFW/GL cannot be used by both at the same time, causing hangups. Someone else would know better though, I am by no means a Mac expert.
The problem is AWT (heavyweight, implemented on top of OS-specific APIs), not Swing (lightweight, implemented in Java on top of AWT).
The GLFW binary bundled with LWJGL does not contain any "Java-awareness" features, it's almost identical to what you'd get when building the upsteam project. It does not know anything about another windowing toolkit competing for the event loop on the main thread. It cannot interoperate with AWT.
However, there is apparently a way to modify GLFW to make it play nice with AWT, see https://github.com/badlogic/glfw/commit/1c213479bdf3e2a5ae68e4200e9d2fcd6ad31e27 and https://github.com/libgdx/libgdx/pull/6673. As always, impressive heroics by @badlogic. Technically, you could grab that binary and make LWJGL use it with Configuration.GLFW_LIBRARY_NAME
(or -Dorg.lwjgl.glfw.libname=
), right now. It is possible that LWJGL will adopt such a solution in the future (maybe by shipping two GLFW binaries on macOS), but I'm waiting to hear how it actually works in practice and seeing how hard it'll be to keep in sync with upstream changes.
We've used this approach in Spine for years (with an outdated GLFW version). It basically just pushes all GLFW ooerations onto the main thread and waits synchronously for completion. Keeping this up-to-date with uostream GLFW is a very low maintenance burden.
On Wed, Nov 17, 2021, 21:24 Ioannis Tsakpinis @.***> wrote:
The problem is AWT (heavyweight, implemented on top of OS-specific APIs), not Swing (lightweight, implemented in Java on top of AWT).
The GLFW binary bundled with LWJGL does not contain any "Java-awareness" features, it's almost identical to what you'd get when building the upsteam project. It does not know anything about another windowing toolkit competing for the event loop on the main thread. It cannot interoperate with AWT.
However, there is apparently a way to modify GLFW to make it play nice with AWT, see @.*** https://github.com/badlogic/glfw/commit/1c213479bdf3e2a5ae68e4200e9d2fcd6ad31e27 and libgdx/libgdx#6673 https://github.com/libgdx/libgdx/pull/6673. As always, impressive heroics by @badlogic https://github.com/badlogic. Technically, you could grab that binary and make LWJGL use it with Configuration.GLFW_LIBRARY_NAME (or -Dorg.lwjgl.glfw.libname=), right now. It is possible that LWJGL will adopt such a solution in the future (maybe by shipping two GLFW binaries on macOS), but I'm waiting to hear how it actually works in practice and seeing how hard it'll be to keep in sync with upstream changes.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LWJGL/lwjgl3/issues/697#issuecomment-971959659, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD5QBHMW3HYX6RTOD546JDUMQFRTANCNFSM5IHPIW5A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Thanks! I'll look into that.
One thing that I not yet completely understand is what the role of glfw is when loading lwjgl-nfd. What I understand is that glfw is used in conjunction with OpenGL, but native file dialog does not interact with OpenGL (from what I've seen). Or am I approaching this the wrong way?
NFD knows nothing about AWT (or GLFW) either. It works with [NSApplication sharedApplication]
, which the NSApplication
created by either AWT or GLFW. However, it's still Cocoa code that needs to run on the main/first thread and a Swing event handler won't run on that.
Why use NFD though? Aren't the existing Java file choosers good enough?
I wanted a native file chooser for my project, with the option to add file filters. NFD and JavaFx seem to be the only ones offering this. Loading JavaFx for just the file chooser is a bit much for my project.
Would TinyFD have the same problems on mac?
JFileChooser
(Swing): Supports file filters, Custom ui, slow for large directories.FileDialog
(AWT): Does not support file filters (on Windows at least). Looks native.FileChooser
(JavaFX): Most complete version, can be plugged into Swing. But JavaFx is quite heavy and multi platform builds are not really an option. (works on mac?)NFD
(LWJGL): Supports file filters. Native file chooser. Can create multi platform jar.TinyFD
(LWJGL): Supports basic file filters. Native file chooser. Can create multi platform jar.I've used tinfd successfully with my Glfw fork on macOS. Didn't try nfd.
On Thu, Nov 18, 2021, 10:39 Gerben Oolbekkink @.***> wrote:
I wanted a native file chooser for my project, with the option to add file filters. NFD and JavaFx seem to be the only ones offering this. Loading JavaFx for just the file chooser is a bit much for my project.
Would TinyFD have the same problems on mac?
- JFileChooser (Swing): Supports file filters, Custom ui, slow for large directories.
- FileDialog (AWT): Does not support file filters (on Windows at leas). Looks native.
- FileChooser (JavaFX): Most complete version, can be plugged into Swing. But JavaFx is quite heavy and multi platform builds are not really an option. (works on mac?)
- NFD(LWJGL): Supports file filters. Native file chooser. Can create multi platform jar.
- TinyFD (LWJGL): Supports basic file filters. Native file chooser. Can create multi platform jar.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LWJGL/lwjgl3/issues/697#issuecomment-972696249, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD5QBFKRYA323677ZBYLXDUMTCW5ANCNFSM5IHPIW5A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
So tinyfd uses applescript instead of cocoa on mac. It spawns a new process to show the filechooser, this circumvents the main thread problems.
Hasn't anyone tried to get this resolved directly upstream?
Version
3.3.0
Platform
macOS x64
JDK
Oracle Java SE 16.0.1+9-24
Module
lwjgl-nfd
Bug description
Using
NFD_OpenDialog
on Mac from an action listener inside the swing dispatcher thread causes aNSInternalInconsistencyException
which crashes the application. On other platforms (Windows/Linux) the code executes as expected.Is this an error in 1) my code, 2)
lwjgl-nfd
or 3)nativefiledialog
?See https://github.com/qurben/lwjgl-nfd-testing for a simple example.
Stacktrace or crash log output