Current state of GUI development in Rust?

[codechapin]

Any thoughts about doing something like Scenic for Elixir? https://youtu.be/1QNxLNMq3Uw

My biggest concern about something like that is accessibility, which was mentioned before.

[KrishnaSannasi]

Ok, I misunderstood. Thanks for clearing it up.

[ZootAllures]

I mean, it looks like a perfectly fine library. Again I’d say though based on examples like this one I found that it’s just doing the same old thing every GUI lib in every language ultimately does, with the only differences being syntactic ones per Elixir itself, because why wouldn’t it?

I think the accessibility point boils down to a simple question of “do we think a hypothetical fully from-scratch Rust UI framework can adequately implement something close to the level of accessibility features that would be available to it if it was instead wrapping an existing, established framework?”

[newpavlov]

I think it was brought up several times, but is there any progress on layout solvers? (e.g. see yoga) For bonus points it would be nice to be able to have “compile-time layouts”, i.e. you provide layout restriction at compile time and library will precompute how elements should react to resized window, instead of traversing the whole layout tree.

[matklad]

Not an expert in the field, but Flutter’s approach to layout seems very interesting: https://www.youtube.com/watch?v=UUfXWzp0-DU

It’s not really a layout algorithm in a sense that it is not some kind of mathematical constraint-solving framework, like cassowary. It’s more like a programming API which you get if you use “single linear tree traversal” as your main design constraint. However, I see how things like flexbox or grid layout can be easily implemented on top of it.

[monkeyTux]

Is possible to implement a GUI like Flutter in Rust? Because the framework is built with a lot of inheritance, and Rust does not support inheritance.

[skyschermer]

Rust is Turing complete, so it’s possible to do anything in it, up to performance. The pertinent question is if you can do it efficiently.

[parasyte]

One alternative to the event-loop-and-callback-soup (aka retained-mode GUI) is the immediate-mode GUI. There are plenty of other resources describing the paradigm, and of course Rust bindings for dear-imgui exist. Here’s a popular one: imgui.

[ZootAllures]

I’m not sure there’s really as much difference between the two in ways that actually matter as people think. Also immediate-mode GUIs certainly still use event loops, quite transparently at that.

[parasyte]

Apart from the obvious that there must be a loop unless your application exits immediately … I was pointing out event loops in the sense of something like Windows where you call GetMessage and DispatchMessage and friends, and it does a bunch of black box things just to ultimately call back into your code for the UI element’s window procedure. Or how about HTML, where even the loop is hidden away from the developer? Again, the loop will eventually call back into your code to handle interactions.

With an immediate mode GUI, there are no callbacks (unless you implement them for some reason, maybe a good reason at that?) You also implement the main loop. The major difference is that handling UI interactions takes the form of checking the return value of the function that displays the element. For example, fn do_button(text: &str, x: u32, y: u32) -> bool. If it returns true, the button is being clicked, therefore perform some action.

[glowcoil]

This approach has the downside that it introduces a frame of latency for every user interaction, and the only way to fix that is to run the entire render function again immediately when there is a user input.

[parasyte]

I don’t buy this explanation. The example do_button function can draw the button in the “pressed” state when it returns true. There is no 1-frame latency or redraw necessary.

[glowcoil]

Suppose there’s some state x: i32, and if do_button returns true, the render function increments x. Any part of the UI that depends on x that is drawn earlier in the render function than the call to do_button will have been drawn using a stale value of x.

[parasyte]

That sounds like a pretty standard state management/ordering concern. In a similar vein to rendering triangles with translucency last when a depth buffer is used. You have the same issue if you choose to draw the GUI last and expect that button to add an object to the scene.

[glowcoil]

I’m just pointing out an inherent limitation in the immediate-mode event handling pattern that retain-mode event handling is not subject to. In your example, if you keep layout information around after drawing the GUI, you can handle events before drawing either the scene or the GUI, which eliminates the frame of latency.

[parasyte]

I’m aware that retained mode doesn’t have the same considerations for ordering and state management. What I’m describing is that since the developer is drawing the GUI they should be aware of how state is flowing through it, and be able to order their draw calls appropriately. It may not always be the case that a developer is aware of how all state flows through the application, and more complex scenarios will make it more difficult to keep latency ideal.

My point is there is no inherent latency added by immediate mode GUI, contrary to what you wrote earlier:

This approach has the downside that it introduces a frame of latency for every user interaction, and the only way to fix that is to run the entire render function again immediately when there is a user input.

Since changing the order of operations also avoids adding a frame of latency, then rendering twice is definitely not the only fix.

[rpjohnst]

Reordering your operations is not always possible. Separating update and render into two phases is, and comprehensively fixes the problem.

[parasyte]

I agree, with the caveat that it adds other problems. The concept of HMGUI was mentioned earlier in this thread as an attempt to address the problems with both IMGUI and RMGUI.

[zoumi]

I am using:
(web-view(html5+js+css3))<-----> ( websocket and minihttp)<----->(rust host at background).

The advantages:
1.Html5+css3 is expressive. You can make a cool gui with canvas, css3 animation.
2,Data transports between rust and client is rapid by keeping three websocket connections at background.
3,The final single binary app is only 1.5Mb(use zip pack all resources into the rust source code then unzip in RAM when the app startup).
4,gui events is handle by js.
5,layout and debug ui by using web browser.
6,communicate with json between ws side and the host side

The disadvantages:
1,On windows7 only IE10+(include IE10) support websoket.

[pythoneer]

For those still interested in this topic, please take a look at areweguiyet