Event loop integration without Qode? #1092

Activity

1. sedwards2009 commented on Sep 20, 2026

   

   sedwards2009

   on Sep 20, 2026

   Collaborator

   More actions

   I read through eventloop-graft and it doesn't quite do what you think, and it certainly isn't a drop in replacement. What that package implements is a message passing system between the main node thread (i.e. UI toolkit) and a worker thread (i.e. app logic). But it is not seamless. The key line from eventloop-graft is:

   it's typically the responsibility of the toolkit integration layer to generically pass around all inputs from the UI thread to the application thread, letting the application thread decide what to do with them.

   NodeGui would have to support pushing events and method calls etc cross this message system. That is code which would have to be added all over NodeGui. You don't get it for free.
2. joepie91 commented on Sep 20, 2026

   

   joepie91

   on Sep 20, 2026

   Author

   More actions

   (To be clear, I'm the author of eventloop-graft, I made it because I couldn't find any existing generic solutions for this)

   NodeGui would have to support pushing events and method calls etc cross this message system. That is code which would have to be added all over NodeGui. You don't get it for free.

   This is definitely true, apologies if I made it sound like it was meant to be an easy drop-in change, that was not my intention.

   I'm not entirely clear on how NodeGui's integration is maintained exactly (my brain tends to blank immediately when reading C++, unfortunately); but usually for things like UI toolkits, I've found that code generation is pretty heavily used for generating the bindings, either at runtime or build time. In that sort of setup, integration with something like eventloop-graft would probably look something like "changing the code generation to generate code for either end of the thread boundary, rather than a single direct binding", so most of the work would still be done by the codegen.

   To take the GTK project I've been working on as an example, in GTK I can benefit from GObject introspection and so I'm doing something like this even without having direct control over the underlying bindings; runtime-generating a 'proxied' API on the application side (which sends messages to the UI thread for the requested changes) and then likewise generating code on the UI thread side that receives those messages and applies the changes in question through the 'real' bindings, and sends back messages (processed on the application side) when events are triggered.

   So to clarify on how I see this being beneficial here: there would be (potentially significant) work involved in restructuring NodeGui to work this way, but once that is done, it does not have an ongoing maintenance cost in the way that Qode does. With Qode, a new release is essentially needed every time the Node.js project does a security release (which is very often; and not on NodeGui's release schedule). Whereas if it can work within a standard Node.js installation, Node can just be updated from upstream and wouldn't affect whether NodeGui works or not, so any given NodeGui release would keep working for as long as it remains compatible with the Qt version and the native add-on API.