[bug] Gtk: events sent through EventLoopProxy do not wake the main thread

[jfaust]

This results in at least one way for to happen.

The gtk implementation of EventLoop manages Tao events in separate crossbeam channels, and then lets gtk do its own event loop/message handling with:
gtk::main_iteration_do(blocking);

However, this means that if the main thread is blocking inside the gtk iteration (and no windowing events have arrived), then if you send an event via EventLoopProxy from another thread, it will not process until there has been some windowing system message (or X11 Device event, as those are handled using glib::MainContext::channel()). In some cases this can be effectively "forever" - I've seen minutes pass without my app receiving the event I've passed, if I'm not actively interacting with the app.

This diff fixes things for me, but knowing very little about gtk I'm not sure it's the best option:

diff --git a/src/platform_impl/linux/event_loop.rs b/src/platform_impl/linux/event_loop.rs
index ab82b954..dfa31bf1 100644
--- a/src/platform_impl/linux/event_loop.rs
+++ b/src/platform_impl/linux/event_loop.rs
@@ -1088,7 +1088,12 @@ impl<T: 'static> EventLoopProxy<T> {
         } else {
           unreachable!();
         }
-      })
+      })?;
+
+      let context = MainContext::default();
+      context.wakeup();
+
+      Ok(())
   }
 }
 

Using glib::MainContext::channel() instead of crossbeam I think would be another option.

See: tauri-apps/tauri#3654

[jfaust]

PS I'm happy to open a PR with the above patch, just want to make sure that's the right approach first.

[wusyong]

@jfaust Yes, I appreciate any help of improving gtk port. Feel free to open one

[jfaust]

@wusyong Done