desktop: Add "Advanced Open..." dialog

[Dinnerbone]

The exact settings inside is definitely going to change over time, but I think it's more than good enough for now. Some of them will likely move to being global settings, or stuff you change on a whim perhaps.

I've also made it default to opening this dialog straight away (if no movie has been specified on the CLI) just for quality of life, though in the future I'd like to investigate a much better "title screen" that has recent games ready to click

All values default to what's set on the CLI.

[Toad06]

Very nice improvement, thanks. Just two things I noticed:

• Ruffle hangs a few seconds after the OS file selector is open, displaying "not responding" near the application name (Windows 10). No crash occurs though.

• rollOver events on buttons run even if the "Open File or URL" box is displayed in front of them. However, clicking doesn't run their "press" or "release" events. For instance, the behavior can be observed in DTunnel 3D (https://uploads.ungrounded.net/174000/174308_nhsdtunnel3d.swf?1086971709): a sound is played when one of the buttons is hovered.

[Dinnerbone]

Ruffle hangs a few seconds after the OS file selector is open, displaying "not responding" near the application name (Windows 10). No crash occurs though.

Hmm I don't think I can reproduce. Is it only in "Open", or "Browse", or both? Are you using release or debug?

rollOver events on buttons run even if the "Open File or URL" box is displayed in front of them. However, clicking doesn't run their "press" or "release" events.

I think this might already be an issue with the context menu and help screen, I think Mike encountered that before. I need to find a solution for egui but I don't think I can solve it for this PR.

[Toad06]

Hmm I don't think I can reproduce. Is it only in "Open", or "Browse", or both? Are you using release or debug?

This happens in both cases. I compile using cargo run --release --package=ruffle_desktop, so release but the same issue appears in debug. It can also be worth mentioning that I'm not compiling from a suitable git worktree.

hang.mp4

[Dinnerbone]

Does it happen on current master (/latest nightly) or is it exclusive to this PR? That's so strange.

[Dinnerbone]

Okay I figured it out, it's our workaround for rust-windowing/winit#2291

If we make the dialog on another thread, it doesn't reuse our event loop and that makes windows realize our event loop is stalled
If we don't do that, it reuses our event loop and panics

The reason we didn't experience the panic before was because we used Wait and immediately blocked the app to open the dialog, but that's not the case with the GUI.

[torokati44]

I'm wondering whether the "horrible hack" added here1 for rust-windowing/winit#2291 is still necessary: iced-rs/winit#14 (comment)