3 ms·

Really excited for this work. I'm curious about what the author means by "Avoiding Custom Widgets". > On the other end of the spectrum, the web has shown that

by zengid 3y ago

Really excited for this work. 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.

jcranmer 3y ago
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.
timeon 3y ago
> 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.
nicoburns 3y ago
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.
deleted 3y ago
[deleted]

by zengid 3y ago

jcranmer 3y ago

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.

timeon 3y ago

> 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.

nicoburns 3y ago

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.

deleted 3y ago

[deleted]