Open Treeki opened 5 years ago
libui explicitly states you can call
uiQueueMain
from any thread
This is problem on our side, then, for sure. I think an API whereby we hand out a queuing token which is Send
from UI
and then provide queue_main
on that token is the way to go here.
queue_main
doesn't actually use the self
argument.
I have a branch at https://github.com/quickdudley/libui-rs/tree/55-async-queue-main which might address this; but I'm still figuring out how to test it. Will submit a pull request if I can do so.
Hey there,
I'm experimenting with iui as a new Rust programmer and I'm unsure whether I've hit upon a design issue with
UI::queue_main
, or if there's a solution I've just missed, as this method isn't used in any of the examples.According to the iui documentation,
UI::queue_main
will queue a function to execute on the GUI thread - I assume this is the thread that calledUI::init()
.libui explicitly states you can call
uiQueueMain
from any thread, but I can't figure out how to do this with iui; it requires aUI
instance which I cannot obtain in non-GUI threads asUI
is neither Send nor Sync.Is there a way to do this, or is this a bug/design flaw? Any advice would be appreciated!
For reference - I'm trying to offload ongoing USB device I/O using hidapi-rs onto a background thread and have it notify the GUI thread when data comes in or when the device is connected/disconnected.
The only method I can figure out for doing this is to have the GUI create a channel where the
Sender
is moved into the background thread andReciever::try_recv
is called regularly on a timer, but this feels inelegant to me and I'd much rather be able to have the background thread notify the GUI through libui's queuing mechanism so that it can update immediately.