Something that I don't see in the roadmap which has me slightly concerned:
One of the important utilities for a UI, especially if custom widgets are to a degree deprecated, is something along the lines of a lazy widget. For example, if I have a table of a few million entries, I don't want to have to create a widget for every single entry, but rather have a callback for the data to fill widgets for the hundred or so currently being displayed.
With that caveat, I find myself largely agreeing with these ideas. Rust desperately needs a GUI framework with a more complete set of canned widgets.
This is in fact touched on (if briefly), in the roadmap - it's "virtual lists" and absolutely is a priority for this year. Performant UI is not possible without it.
The idea is not so much that you have a custom widget, but rather that you have a container view which is tightly coupled to a corresponding container widget. As you scroll, that widget requests its view to materialize (and de-materialize) views for the child widgets that become visible. It doesn't need custom widgets, the child widgets can be standard, and because it's Rust the cost of allocating and deallocating the child widgets (as opposed to recycling existing widgets as in Android RecyclerView) is modest.
(Point of clarification for those following more closely: I'm talking about views here, while the linked post is focused on widgets. The widget tree will provide a documented protocol for requesting child widgets, estimating layout sizes, syncing up scroll adjustments, and so on. This protocol will be a bit messy and complicated, because the underlying problems are hard. We'll develop it in tandem with the corresponding Xilem view, which will we hope will provide a really nice clean developer experience, especially in conjunction with an immutable list data structure which can produce sparse deltas. Then, as people want to do their own reactive layer, they can figure out how to do the plumbing from their own take on the incremental computation engine into this protocol.)
We prototyped this last year, enough to be confident in the direction, and it is absolutely a goal to wire it all up this year.
I'm curious about what the author means by "Avoiding Custom Widgets".
> On the other end of the spectrum, the web has shown that you can implement complex custom UIs given a rigid but rich set of primitives.
Does this statement include things like the canvas API and SVG? How restrictive are we talking here?
I don't want to go off on a rant with my interpretation of what the author means, but I feel like having extensible widgets is a huge selling point for a framework written in and for Rust. If you're just going to bake in a bunch of standard widgets without extension points, I feel like developers aren't looking to write that in Rust. They'll use a native GUI framework, or make a webpage, because those are just so much easier to make in Swift/Kotlin/Dart/JavaScript. If someone is making a Rust UI, they very likely care about performance and they probably want to make a "hot-rod" app that is going to do some crazy-fast shit. If they're just looking for a comfy daily driver, they might as well pick a slower but softer language/framework.
I could be totally misinterpreting things here so please forgive me if I am, I just hope my feedback might be helpful.
I think the key thing that is trying to be conveyed here (based on discussions I have had with the blog post’s author beyond the contents of the blog post itself) is that you shouldn’t be required to create a custom widget unless your requirements are unusual.
I am confident that the ability to create custom widgets will be retained for those who do need it.
Personally, the main reason I'm looking to build a GUI in Rust is because the rest of my code is in Rust and I want to have an interface for it is because I don't want to write my own DSL to express it via command line arguments or file inputs and I don't want to have to start using multiple languages just to specify the input to or display the output of my program. I don't really care all that much about speed, I just want to use the language I'm already using for the other parts of the project.
The point about extensible widgets is I think more along the lines that what most people need isn't a way to create new and better versions of <input type=T>, but rather ways to say "if I want to input something of type T, you need to display these inputs in this layout and you can combine them to make a new object of type T". In other words, GUIs should focus on composition rather than inheritance.
> Does this statement include things like the canvas API and SVG? How restrictive are we talking here?
Your have good point for discussion. But to address this sentence I saw in the blog this:
> There will be escape hatches, from a fixed-size canvas surface where end-users can use arbitrary paint primitives to full-on custom widget code, but we should design the framework under the assumption people will almost never need those hatches.
Also instead of SVG you can probably use Kurbo like in Druid.
This is exciting. I genuinely enjoyed working with Druid (though my time with it was limited). I was wondering if Xilem would get to that level of usability. Sounds like they’re planning to go way further.
One of the important utilities for a UI, especially if custom widgets are to a degree deprecated, is something along the lines of a lazy widget. For example, if I have a table of a few million entries, I don't want to have to create a widget for every single entry, but rather have a callback for the data to fill widgets for the hundred or so currently being displayed.
With that caveat, I find myself largely agreeing with these ideas. Rust desperately needs a GUI framework with a more complete set of canned widgets.