On Fri, 23 Feb 2024 17:39:44 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
> This changes one of the fundamental aspects of entering and exiting a nested > event loop. This will need a lot more analysis to show why this is the right > approach. Yes, this is right and I also thought about documenting that as soon as we think that this is the right approach. I completely agree that we need to analyse this. This is not a simple change but will affect Dialogs and every custom code that uses nested event loops (e.g. I used it for blocking the UI without freezing it for data loading purposes, where we want to wait until the code returns in a non UI blicking way). Maybe there is a better way as well, I just don't figured out one. As described, right now we rely that `enterNestedEventLoop` returns always, which is not happening immediately for ALL platforms, even though Platform has another implementation. Which makes me think the current approach has a flaw, resulting in this behaviour. > I see the same failure with the most recent patch as I did yesterday. I > looked over the changes, and I'm not convinced that this is the right > approach. Thanks for testing. As soon as my colleague is available, I will debug this issue. I don't get why only MacOS is failing, since the low level code is pretty much the same, we just continue right after we left the nested event loop. I agree that we should find out the root cause why MacOS behaves different. > I don't know of any supported way to run macOS in a VM on a Windows host, but > perhaps others will be able to help. That was also my understanding the last time I checked. AFAIK, think there is no official way from Apple, but VirtualBox may offer that. Will check as soon as I have more time. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1962428672
