feat: multi-window support

[derezzedex]

This PR roughly implements multi-window support, as described in the RFC: iced-rs/rfcs#8.

The multi_window example showcases a multi-window version of the pane_grid example.

Note: This is still work-in-progress, and will remain a draft while the RFC hasn't been merged.

[timjrd]

I found a bug on the multi_window example on Linux/X11: when you open two windows, close the original one, wait for a bit, then close the remaining window, you get This shouldn't be possible! and the app freezes. Conversely, if you close the second one, then the original one, the process doesn't exit. On Linux/Wayland those two issues are non-existent and the example is working fine. 🙂

[timjrd]

Another bug on both Linux/X11 and Linux/Wayland: if you modify the multi_window example to spawn two windows at startup, only one shows up, and the other one only shows up later when you click Split *.

Here is the modified example:

diff --git a/examples/multi_window/src/main.rs b/examples/multi_window/src/main.rs
index 88ddf46f..717bcc9c 100644
--- a/examples/multi_window/src/main.rs
+++ b/examples/multi_window/src/main.rs
@@ -60,18 +60,32 @@ impl Application for Example {
     type Flags = ();
 
     fn new(_flags: ()) -> (Self, Command<Message>) {
-        let (panes, _) =
-            pane_grid::State::new(Pane::new(0, pane_grid::Axis::Horizontal));
-        let window = Window {
-            panes,
+        let window_0 = Window {
+            panes: pane_grid::State::new(Pane::new(
+                0,
+                pane_grid::Axis::Horizontal,
+            ))
+            .0,
             focus: None,
-            title: String::from("Default window"),
+            title: String::from("Window 1"),
+        };
+        let window_1 = Window {
+            panes: pane_grid::State::new(Pane::new(
+                1,
+                pane_grid::Axis::Horizontal,
+            ))
+            .0,
+            focus: None,
+            title: String::from("Window 2"),
         };
 
         (
             Example {
-                windows: HashMap::from([(window::Id::new(0usize), window)]),
-                panes_created: 1,
+                windows: HashMap::from([
+                    (window::Id::new(0usize), window_0),
+                    (window::Id::new(1usize), window_1),
+                ]),
+                panes_created: 2,
                 _focused: window::Id::new(0usize),
             },
             Command::none(),

[ids1024]

Instead of hashing an arbitrary hashable as a u64, it might be better to define this more like iced_native::widget::Id? Which is either a usize that is made unique by auto-incrementing, or a string.

Generating unique IDs with an incrementing integer makes sense for dynamic spawning of windows, where IDs can be stored in the model. Should be more collision resistant than hashes.