Advice for the next dozen Rust GUIs • Hacker News Board

Re: Advice for the next dozen Rust GUIs

#51

Post by Nadya » Sat, Jul 16, 2022, 12:13 AM UTC

wmf wrote: post #45

overgard wrote: post #34

I think the web really killed the idea of "native" widgets. I think the rise of web apps just got everyone used to the idea that controls are just going to look different everywhere. Even on macOS, practically every app I use has a very distinct look and set of widgets (vscode, photoshop, blender, spotify -- two of those are electron, but even the non-electron stuff doesn't look very much like a "mac" app anymore). A…

I think it's more a desire for branded UI rather than Web apps. Adobe wants their UIs to be instantly identifiable as Adobe, Slack wants to be instantly identifiable as Slack, MS Office as you said, etc. Personally, I doubt this benefits users (do you really need to market to people who already bought your product?) but I'm sure the logic is compelling to decision makers and it's cheaper to "design once, run everywhe…

What's funny is that it pisses off a large number of those 1% of users who swap OSs frequently as well. So it isn't even for the benefit of that 1% either.

When operating a Mac I expect Mac-specific behaviors. When operating a Windows PC I expect Windows-specific behaviors. I LOATHE programs that decide to do away with OS-isms that I am accustomed to and require me to learn how to "do things their way" because they wanted cross-OS consistency. Sometimes this means conforming everything to a single platform which is partially evil but just as often it means conforming to _none of them_ which is pure evil.

But I understand this - as a web developer I've experienced pressure from Project Managers and the "decision makers" to make things consistent across browsers/devices even if doing so goes against how the users of said browsers/devices would expect things to operate - breaking user expectations and creating a worse UX for many users. I fight against it when I can but I'm not always successful.

Re: Advice for the next dozen Rust GUIs

#52

Post by game-of-throws » Sat, Jul 16, 2022, 12:13 AM UTC

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…

When I hear you say "Lombok problem", it makes me think you're writing getters and setters and generally treating the language as if it's Java. You might get along better if you try to unlearn some of those habits. There's nothing wrong with public fields or free functions; in fact I'd say most of the time the straightforward approach is preferred.

Re: Advice for the next dozen Rust GUIs

#53

Post by the_duke » Sat, Jul 16, 2022, 12:14 AM UTC

Isn't all the discussion about the top level UX a bit of a red herring?

Iced, slint, sycamore, Dioxus , yew ... they all have quite different but very workable API surfaces. Yes, three of those target the browser, but there's nothing stopping them from building on a lower level Rust widget system instead. Even gtk-rs found a solid way to map a class structure to Rust extension traits.

Isn't the real problem in the weak fundamentals? Solid window and input handling, text rendering, layouting and 2d drawing libraries, ...

I see all the UI attempts struggling with those, and either implementing their own solutions or battling the existing ones (like winit).

I feel like if all those pieces were in place decent solutions could emerge.

Re: Advice for the next dozen Rust GUIs

#54

Post by __david__ » Sat, Jul 16, 2022, 12:16 AM UTC

I just happened to build a little project using Slint (https://slint-ui.com/) last week and found it fairly pleasant, even though it's got some rough edges still. I liked it because I was able to cross-compile to Windows from my Mac and from my Linux based CI with extreme ease ("cargo build --release --target x86_64-pc-windows-gnu"). It supposedly has some sort of native widgets available if you have Qt installed, but I haven't pursued that yet.

It has a little meta language for describing the UI that gets compiled when you compile the code and that was nice because it catches type and syntax errors at compile time.

I almost went with Tauri, but the cross-compile story didn't seem quite as good compared to Slint. Tauri does look nice though—web UIs are more flexible than Slint at this point. But for my simple little tool, Slint really hit the spot.

Re: Advice for the next dozen Rust GUIs

#55

Post by runnerup » Sat, Jul 16, 2022, 12:17 AM UTC

raphlinus wrote: post #27

stephc_int13 wrote: post #9

I have no business related to Rust, but after reading a few articles from this author, I tend to think that his approach to GUI toolkit design is deeply flawed. He is undoubtedly highly knowledgeable about the subject, but this knowledge may be a curse in his case. A mix of second system syndrome and Architecture Astronaut, trying to satisfy too many constraints can be a deadlock. I think the sensible approach is sta…

“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…

Last part might be worth an edit. I saw his comment as constructive well meant criticism rather than callous, thoughtless, or mean spirited.

Also love the work you do and enjoy following it. Your treatises on Oklab are the #1 place I send programmers of all skill levels to understand color.

Re: Advice for the next dozen Rust GUIs

#56

Post by bogwog » Sat, Jul 16, 2022, 12:18 AM UTC

modeless wrote: post #16

billconan wrote: post #6

Earlier quoted context omitted.

Also, do you think if multi-channel signed distance field is a good approach for GUI text rendering? I understand, for games, it can support extreme zooming with small textures. But for GUI (for example a text editor), we only occasionally resize fonts. I looked at some of the open source projects (mostly terminal emulators), they simply rasterize fonts onto a texture map using CPU. I wonder if signed distance field…

The best GPU accelerated text rendering I know of is https://sluglibrary.com/ . Not based on distance fields. Unfortunately not open source, though it is a one-man project. Maybe someday one of the big tech companies will pay him a whole ton of money to open source it.

The problem with slug is not that it isn't open source, it's that it's patent encumbered[1]. If it weren't for the patents, it'd be possible to implement an open source version.

For font rendering, there are a lot of existing techniques out there, but whichever is best depends on your requirements. There are no silver bullets, and slug certainly isn't one.

I will say though that most applications probably don't need hardware accelerated font rendering. A software renderer like Freetype2 is going to offer much higher quality results than anything like slug ever could, and with proper caching you can achieve good realtime performance. For a real world example of a text-heavy application that does this, see Lite-XL[2]

1: The landing page doesn't even mention the word "patent", so here's some evidence: https://twitter.com/ericlengyel/status/1159917092331642880?l...

2: https://lite-xl.com/

Re: Advice for the next dozen Rust GUIs

#57

Post by aaaaaaaaaaab » Sat, Jul 16, 2022, 12:18 AM UTC

raphlinus wrote: post #27

stephc_int13 wrote: post #9

I have no business related to Rust, but after reading a few articles from this author, I tend to think that his approach to GUI toolkit design is deeply flawed. He is undoubtedly highly knowledgeable about the subject, but this knowledge may be a curse in his case. A mix of second system syndrome and Architecture Astronaut, trying to satisfy too many constraints can be a deadlock. I think the sensible approach is sta…

“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

Why exactly? What are the current state of the art UI toolkits leaving on the table performance-wise?

Re: Advice for the next dozen Rust GUIs

#58

Post by raphlinus » Sat, Jul 16, 2022, 12:20 AM UTC

riquito wrote: post #25

Raphlinus, great post as usual, thanks for sharing your knowledge, is always an interesting read. I'm loosely following the progress of slint ui (formerly SixtyFPS), anything interesting in their approach or does it strictly matches one of your examples?

I don't follow slint as closely as maybe I should. I'm definitely happy there's a real product out there, and would be happy to work with them on common infrastructure, but we haven't had much interaction (yet).

Re: Advice for the next dozen Rust GUIs

#59

Post by favorited » Sat, Jul 16, 2022, 12:22 AM UTC

seanalltogether wrote: post #20

I haven't looked closely at the latest rust gui projects, but from what I remember most of them seem to be focused on code driven ui layouts, which I think is going to be a non-starter for anyone doing serious application work. View hierarchies and layout rules are too big and too complex to be maintainable via hand coding. Even a moderately sized app can have hundreds of custom views or components that need constant…

I think the industry at large is moving in the opposite direction, towards declarative layouts written in code. As an example, for decades, Apple's UI design tooling (Interface Builder) was serialized to XML, but SwiftUI uses a DSL so your interfaces are written in code. I haven't been a web developer professionally for a while, but I've dabbled in React, where you build UI components in JSX, which is an extension of JavaScript.

I don't see why Rust couldn't be successful with a similar approach.

Re: Advice for the next dozen Rust GUIs

#60

Post by tayistay » Sat, Jul 16, 2022, 12:22 AM UTC

stephc_int13 wrote: post #48

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…

To be frank, I think that the kind of work you are doing is necessary. In my opinion GUI is not yet something I would consider to be a "solved problem". Both from the API perspective and the rendering side, and compute shaders are indeed extremely promising and could be something close to an end-game in this space. This is why I read your articles. And I have absolutely zero interest in dumping on your work, but I ha…

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?