61–70 of 148 posts
Earlier quoted context omitted.
A virtual DOM is another indirection, so the opposite of what immediate mode tries to accomplish.
Immediate mode only describes the interface.
I had the impression that the lack of double buffering would imply a more direct access, this the "immediate" in the name.
Earlier quoted context omitted.
Any quarter decent imgui implementation will idle when there's no input or active animations, and the renderer can generate dirty tiles or rects to unnecessary redrawing -- if it matters, gpus are ridiculously overpowered for drawing a bunch of rectangles. Ui logic is usually firmly in the microseconds realm.
I agree that this is not a necessary downside to immediate mode GUIs, but we're talking about egui specifically here. AFAIK, egui always redraws at some relatively high rate even when nothing is happening. (I'm having trouble finding documentation about what that rate is though.)
This is also mentioned in the gui docs here https://github.com/emilk/egui#why-immediate-mode:
> egui only repaints when there is interaction (e.g. mouse movement) or an animation, so if your app is idle, no CPU is wasted.
Earlier quoted context omitted.
Any quarter decent imgui implementation will idle when there's no input or active animations, and the renderer can generate dirty tiles or rects to unnecessary redrawing -- if it matters, gpus are ridiculously overpowered for drawing a bunch of rectangles. Ui logic is usually firmly in the microseconds realm.
I agree that this is not a necessary downside to immediate mode GUIs, but we're talking about egui specifically here. AFAIK, egui always redraws at some relatively high rate even when nothing is happening. (I'm having trouble finding documentation about what that rate is though.)
Reactive mode is the one you are looking for.
Earlier quoted context omitted.
Have you considered just using gRPC in this case? You gain 100% language separation (no FFI) and remote client/server at the cost of a little more call overhead.
Not OP but in same situation. Not every platform can run gRPC over localhost easily or without extra privileges. I used to use protobuf but now I just use JSON, over stdin/stdout on desktop. It’s honestly quite good.
Earlier quoted context omitted.
Since others are sharing Rust GUI libraries, I’ll mention Slint [ https://slint.rs ] a native GUI toolkit written Rust. It has a declarative domain specific languages, editor tools, and has been stable with no breaking API changes since 2023. I'm one of the developers.
Anyone considering it will need to decide for themselves how to feel about it, but I think it's important to prospective users to highlight that the current licensing model for Slint requires either GPL3-compatible licensing of your work, advertising for Slint within your own software, or paying ongoing licensing fees and/or royalties. https://github.com/slint-ui/slint/blob/master/FAQ.md#licensi... I only mention thi…
Earlier quoted context omitted.
Not OP but in same situation. Not every platform can run gRPC over localhost easily or without extra privileges. I used to use protobuf but now I just use JSON, over stdin/stdout on desktop. It’s honestly quite good.
Why not ConnectRPC? It's basically gRPC but without all the strange requirements for exotic HTTP features.
I still prefer good old GUI frameworks with WYSIWYG designers.
Makes sense to use a primitive instrument to satisfy primitive needs, those eschewing a lot of extra complexity.
Though if some funding does fall through for better gui, isn't that a risk of having to do another switch?