SDL Events & Modal Dialogs: Handling Active States

Hey guys! Let's dive into a fascinating discussion about how SDL events behave when modal dialogs pop up, especially concerning an issue related to fixing #272. This is crucial for ensuring our applications behave predictably and smoothly across different operating systems. So, grab your coding hats, and let’s get started!

The Linux Situation: SDL Events in Limbo

When we talk about the Linux environment, particularly with the planned fix involving Gtk modal dialogs, things get a bit peculiar. The core issue is that when a Gtk modal dialog becomes active, any SDL events that come along are essentially thrown into the void. Poof! Gone. This might seem like a straightforward solution on the surface, but it has some significant implications that we need to consider. Let's break down what doesn't work in this scenario and why it matters.

What Doesn't Work on Linux with Active Modal Dialogs?

• Window Title Updates: While this isn’t a massive concern in this specific context (since the emulator isn't running when these dialogs are active), it highlights a general problem. If we were relying on SDL events to update the window title, that functionality would be temporarily suspended.
• New Window Creation: Similar to the window title, the creation of new windows via SDL events would also be blocked. Again, not a direct issue here due to the modal dialog's app-modal nature (it freezes all windows), but something to keep in mind for other use cases.
• Launch Events: This is where things start to get a bit more interesting. Ideally, we'd want launch events to still function even when a modal dialog is active. Imagine a user trying to launch a specific process or action while a dialog is open; we wouldn’t want that request to simply disappear.
• HTTP Requests (via Function Messages): Now we're talking! HTTP requests, especially the ones used for debugging, are pretty important. If SDL events are being discarded, our debugging requests might just vanish into thin air. At the very least, we'd want these to return an error message, so we know something went wrong.
• ThreadStopCopy (via Function Message): Thankfully, this isn’t a direct problem in this scenario since the emulator isn't running. However, it serves as another example of how crucial SDL event handling can be, particularly when dealing with inter-thread communication and control.

In essence, the Linux implementation, while seemingly simple, raises some serious questions about the user experience. Just throwing away events can lead to unexpected behavior and make it difficult to diagnose issues. We need a more robust solution that provides feedback and ensures critical operations don't simply vanish.

Windows and macOS: The Unknown SDL Event Fate

Now, let's shift our focus to the other major operating systems: Windows and macOS. Unlike Linux, where we have a clear picture of what's happening (events are discarded), the situation on Windows and macOS is a bit murkier. We're not entirely sure what happens to SDL events when a modal dialog is visible.

The Big Question: Event Pile-Up?

The primary concern here is whether SDL events might be piling up in the background while the modal dialog is active. Imagine a scenario where a user is frantically clicking buttons or triggering events, and all those actions are being queued up, waiting for the dialog to close. Once the dialog disappears, BAM! A flood of events could suddenly be processed, leading to chaotic and unpredictable behavior. This is definitely something we want to avoid.

Why Event Pile-Up Is a Problem

• Unpredictable Application State: If events are processed in a delayed manner, the application could end up in a state that the user didn't intend. This can lead to data corruption, crashes, or simply a confusing user experience.
• Resource Overload: A massive influx of queued events could potentially overwhelm the system, leading to performance issues or even application crashes.
• Debugging Nightmares: Trying to debug issues caused by delayed event processing can be incredibly challenging. It's hard to trace the root cause when events are happening out of order or long after the user initiated them.

A Call for Investigation

To properly address this, we need to investigate how Windows and macOS handle SDL events during modal dialog activity. Are the events queued? Are they discarded? Are they processed in some other way? Understanding this behavior is the first step in ensuring our application behaves consistently across all platforms.

Ensuring Sensible Behavior: A Path Forward

So, what's the game plan? How do we ensure that SDL event handling is sensible, regardless of the operating system or the presence of modal dialogs? Let's explore some potential strategies.

Worst-Case Scenario: Unsupported Messages

One approach, which could be considered a