9 ms·

Rust 2020: GUI and Community

222 points by justin66 7y ago

phkahler 7y ago
IMHO any GUI toolkit needs to work with multiple languages. So please dont make it Rust specific.
- raphlinus 7y ago
  This is an interesting question, and one I did not directly address. One of the features of Rust is that it's practical to bind it to other languages, so I think writing a "GUI engine" in Rust that's designed to play scripts in other languages is feasible. That said, it's not the main goal of the druid project. There, we're focusing on writing a real application in Rust. Dealing with language binding issues is hard, and anything that increases the scope too much puts the project at risk. So if you want a multi-language GUI toolkit written in Rust, asking me is not the way to get that, because I'm not going to build that. But if you want to be part of a community effort to build it, I'd be open to collaboration.
playa1 7y ago
Iced looks like it has a lot of potential. https://github.com/hecrj/iced https://github.com/hecrj/iced
traverseda 7y ago
I'd love to see more mainstream discussion about what gui approaches we could take. Personally I'd like to see something like IMGUI but with more of a focus on data structures, you should be able to cache the result of a function much more easily. I guess I'm asking for a more functional-programming styled API for IMGUI. Allow me to get the benefit of a retained GUI by caching the results of functions. At least for the few small toys I've made I think IMGUI is by far the easiest GUI paradigm to work with. I don't know how it would handle something more complicated though.
- raphlinus 7y ago
  I also would love to see more discussion of this topic. There are some academic papers on functional reactive programming and so on, but now there's this huge wave of frameworks for declarative UI. I've found that there's a strong convergence on goals (one-way data binding, unification of initial creation and deltas, etc), but huge diversity in the way they're implemented. And I also agree that IMGUI is one of the most interesting of these, mostly because it's very simple. You'll find makepad (mentioned in my blog post and in comments here) is fairly directly based on IMGUI ideas, but also has the ability to retain intermediate results. Also, I've been admiring the architecture of Jetpack Compose, and feel it's true to the ideals of IMGUI - you can think of it as IMGUI + "positional memoization." And yeah, it's one thing to build toys and another to build real applications. This is one reason the focus of druid is to build a font editor, as opposed to making a GUI toolkit first and hoping for adoption.
pfraze 7y ago
Rik Arends has been working on a cross-platform IDE in Rust called Makepad [1]. It has a custom UI stack that targets wasm/webGL, osx/metal, windows/dx11, and linux/opengl. His premise (which is fairly ambitious) is to work in both 2d and VR environments. It's been fun to watch. There's a demo for the wasm target. [2] 1. https://github.com/makepad/makepad https://github.com/makepad/makepad 2. https://makepad.github.io/makepad/ https://makepad.github.io/makepad/
- vsskanth 7y ago
  Other than startup time, the wasm demo is very responsive on an underpowered moto g7. I'm shocked. Excellent work.
  - lsh 7y ago
    I was very impressed as well. On a desktop with a hardline it loaded instantly however the text is so small I can't make it out. Zooming gives things different degrees of fuzziness, with 150% zoom the least fuzzy (but still fuzzy). Definitely raising the bar
  - m0zg 7y ago
    Exactly my thoughts too, except I loaded it on an iMac, and it loaded instantaneously as well. Far more responsive than any web or Electron UI.
  - bpye 7y ago
    Really a very impressive demo, I could certainly be tricked into thinking it was native.
  - heavenlyblue 7y ago
    That interface works faster than switching between tabs in Firefox on iPhone 6s. It’s probably the fastest web interface I had ever seen for a phone.
- gunn 7y ago
  This is very cool. Especially the animate into compact code view when holding down the alt key. Is there an extension with similar functionality in any other editor?
saagarjha 7y ago
The issue I see with a Rust GUI framework that has a target to be native on multiple platforms is that certain platforms (iOS, macOS) have their toolkits so tightly bound to a certain language (Objective-C for Cocoa, Swift for SwiftUI) that it just doesn’t seem feasible to call into it without making using horrible, hacky, unidiomatic Rust code. I’ve seen projects that aim to support macOS literally having code like NSArray(msgSend!(objc::Class(“NSArray”).unwrap(), new)) and it’s just so awful :(
- Razengan 7y ago
  The state of cross-platform GUI systems really is a bizarre mess in this day and age, and probably can only be solved with a concentrated joint effort by Apple, Google and Microsoft. Personally I'd love to have something like import SwiftUI // For controls that are common to all OSes import SwiftUI.Windows // For OS specific features
  - skohan 7y ago
    > probably can only be solved with a concentrated joint effort by Apple, Google and Microsoft. It's hard to imagine that happening. None of these companies have an interest in making it easier to port code away from their platform.
    - Razengan 7y ago
      Maybe one day when they are populated by employees who grew up with dismay over the state of xplat GUI. :) I mean even now Apple has an increased focus on services that must be accessible from everywhere: Music, TV, iCloud Drive. Surely there must be someone there who wishes they had to write most code only once for all OSes without making their app a hog. I'd settle for just a convention; i.e. let C# remain the primary language on Windows, but introduce SwiftUI-like primitives like Text, HStack, ForEach etc.
      - pjmlp 7y ago
        Basically XAML/WPF/UWP code first.
shmerl 7y ago
Would be nice to add Linux build instructions to Runebender (if it needs any setup besides simply running cargo).
quantummkv 7y ago
Honestly, writing a cross platform gui is a waste of time. Java tried it(multiple times) and failed. Electron tried it and the results are terrible. Qt is moderately successful at it mostly because it is treated as the system toolkit on a lot of Linux platforms and Windows users are conditioned not to care about consistency and experience because of bad enterprise CRUD apps and Microsoft's own inconsistent behavior. What rust should do is focus more on interop with other languages. Write your critical business logic in Rust and make that cross platform. Then write GUI in the platforms preferred Library/Language combo that handles all the UI and makes calls to a cross platform rust binary for grunt business logic processing.
- hombre_fatal 7y ago
  > Electron tried it and the results are terrible. I use VSCode, Slack, and Discord every day (and some other Electron apps). The results are great and better than anything I've seen in the xplat space where there are always trade-offs.
  - 0_gravitas 7y ago
    i think that is part of GP's point, if Electron is the best we can do, then thats not a great sign. im a regular discord user and used to heavily use VSC, but i had to abandon it, for my uses it was far too heavy for what it was.
  - Razengan 7y ago
    There are definitely trade-offs with Electron. Higher CPU, RAM and battery usage compared to native apps, and on macOS at least, the loss of features which native controls get for free.
  - quantummkv 7y ago
    Is Electron better than most cross platform alternatives? Yes. Is Electron better than platform's native tooklit? No. Electron apps are easily recognizable because they completely stand out from the platform apps (not in a good way). And there are other concerns that are addressed in the numerous electron threads on HN so I won't list them here.
Isomorpheus 7y ago
Very excited to see where this goes! I'm waiting to see which will mature faster between this and https://github.com/revery-ui/revery https://github.com/revery-ui/revery
jarjoura 7y ago
Looks like Windows will soon be launching a way for Rust to call into their COM UI API platform. https://kennykerr.ca/2019/11/05/rust/ https://kennykerr.ca/2019/11/05/rust/
- ChrisSD 7y ago
  There is already a way as COM is cross-language by design. However what this will hopefully do is provide a library that makes it natural and using Rust idioms. I'm looking forward to it.
  - pjmlp 7y ago
    All existing Rust libraries only support a subset of COM capabilities and deployment scenarios.
AndrewDucker 7y ago
I'm not sure I want to program my UI. What I want is to draw it, serialise it to some kind of common markup, and then have an API for dealing with events, altering properties, etc. Making sure that API works well with Rust makes sense, but doing the whole thing programmatically doesn't feel like the right model to me.
- flohofwoe 7y ago
  You should give Dear ImGui (which is mentioned in the article) a try. I was reluctant myself when I discovered it a couple of years ago, but it is such a joy to work with and so "obviously" the right thing on a very basic level that ImGui is now my default choice for writing UI tools (even with the disadvantage of not having a native look and feel). It's still possible to put a data layer on top of immediate mode UIs, which basically turn a data representation into a sequence of function calls. But I think this would bring event handling back, which defeats the whole idea of an immediate mode UI :)
danielscrubs 7y ago
"We don’t yet know what to build" - and continues with the thousands of way a GUI-framework could be built. I'm sitting here thinking: is it that important for the user? For a hobby-project sure, but doesn't developers want to wow customers with really nicely designed GUI:s because of the simple fact that beauty sells? I'd argue that if you could find a really, really great GUI-designer (not developer) to take a crack on just one platform (so as to not make a Frankensteins monster) it would matter way more than if the architecture was modern or not. To put it in another way, developers need a guiding hand with UI-design, not how to structure their program.
- flohofwoe 7y ago
  I think there are (at least) two fundamentally different ways to create UIs, suited for two fundamentally different types of UI applications: Programmer-driven for "tools" (think Photoshop, Maya, IDEs, debuggers), and artist-driven for "user applications" (think typical mobile applications and games). For the first type, "maintainability and functionality" is more important than "beauty on the surface", and it's also important to give the programmer a framework which encourages "best practices", so that the result is not an archetypal "programmer UI". Only for the second type, "shininess" is more important than everything else, this includes general aesthetics, colors, animations / transitions, etc...
axilmar 7y ago
Wouldn't a Rust interface to Qt be possible or desired?
- steveklabnik 7y ago
  It sorta exists but is difficult and doesn’t support all of QT yet.

222 points by justin66 7y ago

phkahler 7y ago

IMHO any GUI toolkit needs to work with multiple languages. So please dont make it Rust specific.

raphlinus 7y ago
This is an interesting question, and one I did not directly address. One of the features of Rust is that it's practical to bind it to other languages, so I think writing a "GUI engine" in Rust that's designed to play scripts in other languages is feasible. That said, it's not the main goal of the druid project. There, we're focusing on writing a real application in Rust. Dealing with language binding issues is hard, and anything that increases the scope too much puts the project at risk. So if you want a multi-language GUI toolkit written in Rust, asking me is not the way to get that, because I'm not going to build that. But if you want to be part of a community effort to build it, I'd be open to collaboration.

playa1 7y ago

Iced looks like it has a lot of potential. https://github.com/hecrj/iced https://github.com/hecrj/iced

traverseda 7y ago

I'd love to see more mainstream discussion about what gui approaches we could take. Personally I'd like to see something like IMGUI but with more of a focus on data structures, you should be able to cache the result of a function much more easily. I guess I'm asking for a more functional-programming styled API for IMGUI. Allow me to get the benefit of a retained GUI by caching the results of functions. At least for the few small toys I've made I think IMGUI is by far the easiest GUI paradigm to work with. I don't know how it would handle something more complicated though.

raphlinus 7y ago
I also would love to see more discussion of this topic. There are some academic papers on functional reactive programming and so on, but now there's this huge wave of frameworks for declarative UI. I've found that there's a strong convergence on goals (one-way data binding, unification of initial creation and deltas, etc), but huge diversity in the way they're implemented. And I also agree that IMGUI is one of the most interesting of these, mostly because it's very simple. You'll find makepad (mentioned in my blog post and in comments here) is fairly directly based on IMGUI ideas, but also has the ability to retain intermediate results. Also, I've been admiring the architecture of Jetpack Compose, and feel it's true to the ideals of IMGUI - you can think of it as IMGUI + "positional memoization." And yeah, it's one thing to build toys and another to build real applications. This is one reason the focus of druid is to build a font editor, as opposed to making a GUI toolkit first and hoping for adoption.

pfraze 7y ago

Rik Arends has been working on a cross-platform IDE in Rust called Makepad [1]. It has a custom UI stack that targets wasm/webGL, osx/metal, windows/dx11, and linux/opengl. His premise (which is fairly ambitious) is to work in both 2d and VR environments. It's been fun to watch. There's a demo for the wasm target. [2] 1. https://github.com/makepad/makepad https://github.com/makepad/makepad 2. https://makepad.github.io/makepad/ https://makepad.github.io/makepad/

vsskanth 7y ago
Other than startup time, the wasm demo is very responsive on an underpowered moto g7. I'm shocked. Excellent work.
- lsh 7y ago
  I was very impressed as well. On a desktop with a hardline it loaded instantly however the text is so small I can't make it out. Zooming gives things different degrees of fuzziness, with 150% zoom the least fuzzy (but still fuzzy). Definitely raising the bar
- m0zg 7y ago
  Exactly my thoughts too, except I loaded it on an iMac, and it loaded instantaneously as well. Far more responsive than any web or Electron UI.
- bpye 7y ago
  Really a very impressive demo, I could certainly be tricked into thinking it was native.
- heavenlyblue 7y ago
  That interface works faster than switching between tabs in Firefox on iPhone 6s. It’s probably the fastest web interface I had ever seen for a phone.
gunn 7y ago
This is very cool. Especially the animate into compact code view when holding down the alt key. Is there an extension with similar functionality in any other editor?

saagarjha 7y ago

The issue I see with a Rust GUI framework that has a target to be native on multiple platforms is that certain platforms (iOS, macOS) have their toolkits so tightly bound to a certain language (Objective-C for Cocoa, Swift for SwiftUI) that it just doesn’t seem feasible to call into it without making using horrible, hacky, unidiomatic Rust code. I’ve seen projects that aim to support macOS literally having code like NSArray(msgSend!(objc::Class(“NSArray”).unwrap(), new)) and it’s just so awful :(

Razengan 7y ago
The state of cross-platform GUI systems really is a bizarre mess in this day and age, and probably can only be solved with a concentrated joint effort by Apple, Google and Microsoft. Personally I'd love to have something like import SwiftUI // For controls that are common to all OSes import SwiftUI.Windows // For OS specific features
- skohan 7y ago
  > probably can only be solved with a concentrated joint effort by Apple, Google and Microsoft. It's hard to imagine that happening. None of these companies have an interest in making it easier to port code away from their platform.
  - Razengan 7y ago
    Maybe one day when they are populated by employees who grew up with dismay over the state of xplat GUI. :) I mean even now Apple has an increased focus on services that must be accessible from everywhere: Music, TV, iCloud Drive. Surely there must be someone there who wishes they had to write most code only once for all OSes without making their app a hog. I'd settle for just a convention; i.e. let C# remain the primary language on Windows, but introduce SwiftUI-like primitives like Text, HStack, ForEach etc.
    - pjmlp 7y ago
      Basically XAML/WPF/UWP code first.

shmerl 7y ago

Would be nice to add Linux build instructions to Runebender (if it needs any setup besides simply running cargo).

quantummkv 7y ago

Honestly, writing a cross platform gui is a waste of time. Java tried it(multiple times) and failed. Electron tried it and the results are terrible. Qt is moderately successful at it mostly because it is treated as the system toolkit on a lot of Linux platforms and Windows users are conditioned not to care about consistency and experience because of bad enterprise CRUD apps and Microsoft's own inconsistent behavior. What rust should do is focus more on interop with other languages. Write your critical business logic in Rust and make that cross platform. Then write GUI in the platforms preferred Library/Language combo that handles all the UI and makes calls to a cross platform rust binary for grunt business logic processing.

hombre_fatal 7y ago
> Electron tried it and the results are terrible. I use VSCode, Slack, and Discord every day (and some other Electron apps). The results are great and better than anything I've seen in the xplat space where there are always trade-offs.
- 0_gravitas 7y ago
  i think that is part of GP's point, if Electron is the best we can do, then thats not a great sign. im a regular discord user and used to heavily use VSC, but i had to abandon it, for my uses it was far too heavy for what it was.
- Razengan 7y ago
  There are definitely trade-offs with Electron. Higher CPU, RAM and battery usage compared to native apps, and on macOS at least, the loss of features which native controls get for free.
- quantummkv 7y ago
  Is Electron better than most cross platform alternatives? Yes. Is Electron better than platform's native tooklit? No. Electron apps are easily recognizable because they completely stand out from the platform apps (not in a good way). And there are other concerns that are addressed in the numerous electron threads on HN so I won't list them here.

Isomorpheus 7y ago

Very excited to see where this goes! I'm waiting to see which will mature faster between this and https://github.com/revery-ui/revery https://github.com/revery-ui/revery

jarjoura 7y ago

Looks like Windows will soon be launching a way for Rust to call into their COM UI API platform. https://kennykerr.ca/2019/11/05/rust/ https://kennykerr.ca/2019/11/05/rust/

ChrisSD 7y ago
There is already a way as COM is cross-language by design. However what this will hopefully do is provide a library that makes it natural and using Rust idioms. I'm looking forward to it.
- pjmlp 7y ago
  All existing Rust libraries only support a subset of COM capabilities and deployment scenarios.

AndrewDucker 7y ago

I'm not sure I want to program my UI. What I want is to draw it, serialise it to some kind of common markup, and then have an API for dealing with events, altering properties, etc. Making sure that API works well with Rust makes sense, but doing the whole thing programmatically doesn't feel like the right model to me.

flohofwoe 7y ago
You should give Dear ImGui (which is mentioned in the article) a try. I was reluctant myself when I discovered it a couple of years ago, but it is such a joy to work with and so "obviously" the right thing on a very basic level that ImGui is now my default choice for writing UI tools (even with the disadvantage of not having a native look and feel). It's still possible to put a data layer on top of immediate mode UIs, which basically turn a data representation into a sequence of function calls. But I think this would bring event handling back, which defeats the whole idea of an immediate mode UI :)

danielscrubs 7y ago

"We don’t yet know what to build" - and continues with the thousands of way a GUI-framework could be built. I'm sitting here thinking: is it that important for the user? For a hobby-project sure, but doesn't developers want to wow customers with really nicely designed GUI:s because of the simple fact that beauty sells? I'd argue that if you could find a really, really great GUI-designer (not developer) to take a crack on just one platform (so as to not make a Frankensteins monster) it would matter way more than if the architecture was modern or not. To put it in another way, developers need a guiding hand with UI-design, not how to structure their program.

flohofwoe 7y ago
I think there are (at least) two fundamentally different ways to create UIs, suited for two fundamentally different types of UI applications: Programmer-driven for "tools" (think Photoshop, Maya, IDEs, debuggers), and artist-driven for "user applications" (think typical mobile applications and games). For the first type, "maintainability and functionality" is more important than "beauty on the surface", and it's also important to give the programmer a framework which encourages "best practices", so that the result is not an archetypal "programmer UI". Only for the second type, "shininess" is more important than everything else, this includes general aesthetics, colors, animations / transitions, etc...

axilmar 7y ago

Wouldn't a Rust interface to Qt be possible or desired?

steveklabnik 7y ago
It sorta exists but is difficult and doesn’t support all of QT yet.