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

71–80 of 279 posts

Re: Advice for the next dozen Rust GUIs

#71

Post by mwcampbell »

jakear wrote: post #49
raphlinus wrote: post #27

Earlier quoted context omitted.

“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” — Antoine de Saint-Exupéry I will one hundred percent agree with you that my approach is not a good one if you want a pretty good GUI in a reasonable amount of time. For that, an incremental approach, especially adapting some existing successful design, woul…

> it will be a UI toolkit capable of performance completely untouchable by the existing state of the art Could you give an example of an application where the bottleneck is UI code? In my experience the bottleneck is always either disk or network. Not trying to bash you, genuinely curious.

The fact that our modern computers still often don't feel amazingly fast is a perennial topic of griping on forums like this one. I'm sure the UI stack has something to do with that.

Re: Advice for the next dozen Rust GUIs

#72

Post by c-smile »

> The background for this is that most existing UI toolkits are a poor fit for Rust.

Being in GUI business for almost 30+ years I shall admit that this above is true. And not just Rust but C/C++ are there too.

Real (a.k.a. practical) GUIs are multi-paradigm entities. Same GUI implementation may have React'ive alike widgets immersed into purely declarative DOM/widget tree with elements of immediate mode graphics on top or inside that.

It is just that GUI reflects complexity of real life - you cannot say that sickle and hammer are best tools for everything...

Back to Rust... As a language behind UI Rust is the worst language imaginable. That's primarily due to its strictness.

Object ownership graph in GUI is usually quite complex. yet it is dynamic and frequently contain loops. This situation is best handled by GCable languages. On-click-here-highlight-the-thing-there-and-remove-that-one.

Also each part of UI declaration needs it's own DSL: for UI structure definition, style system and logic behind the UI.

Before arriving with Sciter [1] I've tried [2] many things for UI: C++, D, Java, etc.

Conclusion: HTML/CSS/JS is the best (most flexible and multi-paradigm) solution that we've got so far. Not perfect of course but good enough. And considering existence of Sciter it can be fast and lightweight.

Practical example: RustDesk (https://github.com/rustdesk/ - remote desktop access) is using Sciter for UI layer and Rust for app logic layer. So it is using proper tool for each task.

[1] https://sciter.com [2] https://terrainformatica.com/2014/07/17/10-years-road-to-sci...

Re: Advice for the next dozen Rust GUIs

#73

Post by pcwalton »

moonchild wrote: post #63
pcwalton wrote: post #28

Earlier quoted context omitted.

For most text rendering in the 2D UI use case, I'm not sure there is that much to solve anymore. Aggressive caching of rendered glyphs solves almost all the problems in practice. From what I can tell, Slug is targeted at games and 3D, where there are still interesting problems, but those aren't the 2D UI case.

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 the ball, but it didn't matter because hardware picked up the slack.

Re: Advice for the next dozen Rust GUIs

#74

Post by favorited »

mwcampbell wrote: post #2

I'm the main developer of the AccessKit [1] project mentioned in this post. AMA. To preemptively answer one expected question, I know the project has been inactive for a while; I'm back to work on it in earnest starting this month. [1]: https://github.com/AccessKit/accesskit

This is a really interesting project. Accessibility support is near and dear to my heart.

The readme mentions a macOS adapter prototype, but I don't see that directory. Does it exist in a different branch? I'd love to check it out – I'm pretty experienced with the Mac's AX implementation, but have basically no experience with AX on Windows...

Re: Advice for the next dozen Rust GUIs

#75

Post by oldmanhorton »

tmpfs wrote: post #42
hardwaresofton wrote: post #32

Bit of a hot take, but I basically expect that most new Rust GUI projects will be written in Tauri before long. It works on multiple platforms, and is flexible, and it's easier to find off the shelf pieces due to the web technology involved, and it's lighter than Electron. It's a no-brainer for me (and others, I think) if I'm starting a new GUI desktop project.

I think you are right about this with the one huge problem from my point of view being the text rendering on Windows. This is of course a problem with the Webview implementation on Windows but it is so awful it makes me want to use something else instead. Note this is not a reflection on Tauri which I think is awesome but Microsoft really should fix it.

Tauri uses WebView2 on windows, I believe, which should have the same text rendering as the Windows 11 start menu and Edge itself. You may be thinking of older IE-based webviews, which were used even well after "old edge" webviews were introduced because "old edge" webviews weren't supported on windows 7 or 8.

Re: Advice for the next dozen Rust GUIs

#76

Post by xvilka »

hardwaresofton wrote: post #32

Bit of a hot take, but I basically expect that most new Rust GUI projects will be written in Tauri before long. It works on multiple platforms, and is flexible, and it's easier to find off the shelf pieces due to the web technology involved, and it's lighter than Electron. It's a no-brainer for me (and others, I think) if I'm starting a new GUI desktop project.

Hopefully, not. From my personal experience, Electron and alike applications are slower, larger, and in general have less advanced UI than many Qt or GTK-based (or Windows UI) applications. Nothing can beat good old native GUI frameworks.

Re: Advice for the next dozen Rust GUIs

#77

Post by aaaaaaaaaaab »

raphlinus wrote: post #61
aaaaaaaaaaab wrote: post #57

Earlier quoted context omitted.

>it will be a UI toolkit capable of performance completely untouchable by the existing state of the art Why exactly? What are the current state of the art UI toolkits leaving on the table performance-wise?

I'll have a lot more to say about this as I gather quantitative performance data. But it's a good question. I expect the big wins are: fast 2D (vector with blends and so on) rendering with compute shaders, multithreaded creation of expensive resources like image decompression and text layout, pushing incremental reactivity all the way from app logic to GPU (as opposed to needlessly redoing work), and of course just u…

What do you mean by “pushing incremental reactivity all the way from app logic to GPU (as opposed to needlessly redoing work)”?

Re: Advice for the next dozen Rust GUIs

#78

Post by wokwokwok »

CrimsonVoid wrote: post #40

I know this is going to be a controversial opinion considering how much everyone seems to love Rust, but does anyone else find Rust incredibly painful to work with, even for simple tasks? Like I'm no stranger to unmanaged languages, and to some extent I cut my teeth on C, but doing anything with Rust always feels like the most aggravating exercise in needless verbosity and the "Lombok problem" doesn't help either. (F…

Not everyone loves rust.

I don’t love rust. I think rust has some fair critiques to be made of it.

It’s not, and never has, or (probably) will be the answer to all problems.

Don’t use it just because it’s popular; why are you trying to use it, and what are you using instead?

I’ll eat my hat if you can convince me that rust is more of a pain in the ass than c++. I think cpp is a stupid broken ecosystem, and the fact that rust went all in with a single unified package manager makes the comparison a non-event.

So… compare apples to apples right?

“pre-alpha” language? I don’t even know what you mean by this; but, it’s ok not to love it.

There are things I dislike about it too.

It is verbose.

I still use it though; it’s better than the alternatives for what I’m doing.

Re: Advice for the next dozen Rust GUIs

#79

Post by armchairhacker »

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…

I believe the solution for this is to have a shared context, batch changes and then run through all of them at once.

So when you e.g. mutate a variable, it doesn’t actually change until the next frame. which you can get by calling some sort of poll function. The poll function has mutable access to your entire widget tree, applies the updates, then you can have more UI with shared access

Rust is fast enough that i think performance won’t be an issue.

Re: Advice for the next dozen Rust GUIs

#80

Post by mwcampbell »

favorited wrote: post #74
mwcampbell wrote: post #2

I'm the main developer of the AccessKit [1] project mentioned in this post. AMA. To preemptively answer one expected question, I know the project has been inactive for a while; I'm back to work on it in earnest starting this month. [1]: https://github.com/AccessKit/accesskit

This is a really interesting project. Accessibility support is near and dear to my heart. The readme mentions a macOS adapter prototype, but I don't see that directory. Does it exist in a different branch? I'd love to check it out – I'm pretty experienced with the Mac's AX implementation, but have basically no experience with AX on Windows...

Oh wow, the readme is even more out of date than I realized. I yanked the Mac adapter prototype from the main branch last year. You can find it if you dig through history. I'll bring it back and continue working on it later this year; it's already on my schedule of work to do this year.
Post reply on HN