Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advice for the next dozen Rust GUIs

raphlinus.github.io

Post reply on HN
Print view View original

211–220 of 279 posts

Re: Advice for the next dozen Rust GUIs

#211

Post by nu11ptr »

nextaccountic wrote: post #197
nu11ptr wrote: post #127

Earlier quoted context omitted.

> No matter what people try to invent, it needs to do all Electron does but ways better. Tauri strikes me as a good step up from Electron, and likely a better fit for Rust users (as you can code everything except for view in Rust), but I have just started playing with it.

> as you can code everything except for view in Rust You can do the whole stack in Rust, https://dev.to/stevepryde/create-a-desktop-app-in-rust-using... https://github.com/jetli/rust-yew-axum-tauri-desktop

I probably should have said "pure Rust" as you are mostly writing HTML/CSS, but yes, we could swap JS/TS there for Rust at least. It is just that for people like me who aren't gifted in HTML/CSS we need a UI library like MUI to help us out. Yew/Seed/etc. aren't mature enough to have a big ecosystem of mature UI libs (yet).

Re: Advice for the next dozen Rust GUIs

#212

Post by aaaaaaaaaaab »

infogulch wrote: post #131
aaaaaaaaaaab wrote: post #105

Earlier quoted context omitted.

Wait, are you talking about deltas as in damage rects?

If I recall correctly, damage rects are a raster-stage optimization that rerenders components only if they have changed ('dirtied') since the previous render. You could extend this concept of 'damage rect' to the next layer down, like React has pursued with the vdom/dom split. If you continue extending the analogy through every layer (raster, layout, scene graph, component hierarchy, data model, ...) all the way down…

Yeah, I get it. Although in React's case the whole vDOM diffing thing is self-inflicted - it is only necessary because they insist on the UI being a "pure" function of state. Turns out that the only way to do this with an imperative API is some kind of tree diffing, so that you don't recreate expensive stuff from zero each frame.

Re: Advice for the next dozen Rust GUIs

#213

Post by pjmlp »

tjoff wrote: post #203
pjmlp wrote: post #191

Earlier quoted context omitted.

Only when disregarding that many languages with GC capabilities, also offer value types and features for manual memory management.

Don't really see the appeal for that, seems like it leads to more fragmentation and very few benefits.

No two language syndrome.

Re: Advice for the next dozen Rust GUIs

#214

Post by mwcampbell »

stephc_int13 wrote: post #188
tayistay wrote: post #60

Earlier quoted context omitted.

What, specifically do you think the flaws are? I think if you're going to make such criticism, it helps to give actionable specifics (i.e. constructive criticism). How is the approach discouraging to other devs?

I think that people who manage to achieve "impossible" tasks tend to be overly optimistic (and naïve) at first, consciously or not, this is a good trick to fuel their own motivation and that of others. On the contrary, knowing/talking too much about the difficulties can quickly kill the fun and motivation. He should talk about how great the end-goal will be and why it is important.

Would you rather end-users continue to get stuck with applications that ignore important things like accessibility, that can block some people from getting or keeping a job, so as not to kill some developers' motivation? I'm glad Raph is talking about the difficulties so they (hopefully) won't be ignored or clumsily bolted on afterward this time.

Edit to add:

"Those who cannot learn from history are doomed to repeat it." --George Santayana

I think the time for recklessly moving fast and breaking things in software, without taking into account known complexity and avoiding the mistakes of the past, is over. Our impact on the world, and the resulting responsibility, is simply too great for that.

Re: Advice for the next dozen Rust GUIs

#217

Post by Hermitian909 »

nyanpasu64 wrote: post #206
kristiandupont wrote: post #204

Earlier quoted context omitted.

Again, I am not sure if I am just misunderstanding something but that doesn't sound right to me. >it relies on memoization to preserve hidden state It relies on the DOM to keep that state. It's not hidden, you are just not forced to deal with it or think about it. >If you change the tree structure [...] and don't give scrollable UI items a key if they move, React will delete the scrollable DOM element [...] Yes, if y…

> This is a fundamental property of any diff-algorithm which the virtual DOM relies on. I don't think that is unreasonable, and IMO it is not something that adds significant cognitive load. I think it's a leaky abstraction nonetheless, regardless if it causes issues in practice. But if it's not a significant issue to users, that's fine; personally I'd prefer to work in UI frameworks that avoid redundant diffing work…

> I think it's a leaky abstraction nonetheless, regardless if it causes issues in practice.

The abstraction is intentionally leak to meet a very valuable design goal: React plays well with other libraries that are manipulating the dom. This is a hard requirement for many businesses because libraries written without React in mind would often cost years to replicate.

So far as I can tell there's no reason someone couldn't apply the general approach to UIs React takes while also making it a less leaky abstraction. In a native scenario this makes a lot more sense because there's less components you might want to reuse vs the web.

Re: Advice for the next dozen Rust GUIs

#218

Post by Const-me »

pbsurf wrote: post #159
Const-me wrote: post #91

On Windows, the graphics story is more or less OK. The OS includes Direct2D and DirectWrite user-facing APIs. It’s now possible to implement an equivalent on all modern platforms which have a 3D GPU. An open-source example in C# https://github.com/Const-me/Vrmac#vector-graphics-engine That particular one requires GLES 3.1, but I’m sure (did it before) it’s also possible to implement comparable stuff on top of GLES2.…

Getting sufficient antialiasing quality for 2D graphics is difficult on GPUs. https://github.com/memononen/nanovg accomplishes this with GL2/GLES2 level hardware for most of the stuff one would want to render as part of a GUI. My project https://github.com/styluslabs/nanovgXC supports rendering arbitrary paths with exact coverage antialiasing, but requires GLES3.1 or GL4 level hardware for reasonable performance.

Here's how I did that https://github.com/Const-me/Vrmac/blob/master/Vrmac/Draw/VAA...

Inexact but IMO pretty good still. With some modifications, the approach can be used in GLES2.

Re: Advice for the next dozen Rust GUIs

#219

Post by mwcampbell »

pcwalton wrote: post #73
moonchild wrote: post #63

Earlier quoted context omitted.

Even in 2-d, it is nice to have smooth zoom in/out. The only way to do this that I know of that doesn't compromise on quality is to re-render every frame, and the only way I know to do that fast is to use the gpu. I believe pathfinder can do it (correct me if I'm wrong). I know I'm working on something that can do it too. Moving a bit farther from the strictly 'text' realm there are authoring tools for vector graphic…

Honestly, there are so few different glyphs on a typical page, and CPUs are so fast, that it usually isn't that hard to just rerender every glyph on CPU and aggressively reuse glyph images in order to hit 60 FPS during pinch zoom, at least for Latin text. CJK may be a different story, but I kind of doubt it. In 2022, smooth font rendering during pinch zoom is yet another case in which we in the software field dropped…

> In 2022, smooth font rendering during pinch zoom is yet another case in which we in the software field dropped the ball, but it didn't matter because hardware picked up the slack.

But just letting hardware pick up the slack hurts people stuck with older hardware, right?

Re: Advice for the next dozen Rust GUIs

#220

Post by hnjst »

nine_k wrote: post #98
pornel wrote: post #17

The background for this is that most existing UI toolkits are a poor fit for Rust. Rust doesn't like having shared mutable state, but event-based UIs have a global event loop and can mutate anything at any time. Rust works best with strictly tree-shaped data structures, but event handlers turn trees of widgets into arbitrary webs with possibility of circular references. Rust prefers everything thread-safe, but many U…

There's one "UI toolkit" that builds in top of immutable data structures, trees, and unidirectional data flow. It has also taken web UI development by storm. It's called React. I wonder if React-like approaches are going to work for Rust UI toolkits. They could even wrap some native controls, much like React does with DOM controls, or React Native with Android controls.

I recently tried https://github.com/yewstack/yews that looks very much like "React in Rust". It is web oriented through WASM compilation and integration with web technologies, Tauri can be used to bridge the gap and use it for desktop apps but it is probably an excessively complex and impure assembly for that goal.
Post reply on HN