3 ms·

I would argue it’s not possible for Rust to have a “world-class” toolkit, because it seems implied that it’d be cross-platform. This means it’ll always lag behi

by ghouj 6y ago

I would argue it’s not possible for Rust to have a “world-class” toolkit, because it seems implied that it’d be cross-platform. This means it’ll always lag behind UIKit, AppKit, GTK/Qt, and... whatever Windows has these days. The Iced project used as an example has a custom renderer for example... does it support VoiceOver? Does it support every standard Cocoa keyboard shortcut? Rust wrappers for these existing libraries (some exist) that maintain all functionality is what would allow “world-class” apps to be built in pure Rust IMO.

zerr 6y ago
wxRust needs to be resurrected. wxWidgets is a wrapper around native controls.
raphlinus 6y ago
I agree that support for VoiceOver (and other assistive technology) and full support for keyboard shortcuts is essential for a production GUI toolkit. We certainly don't do those yet, but I do think we can get there. Rust makes it easier to bind platform capabilities at a low level than most other languages. As an example, we do cut'n'paste cross-platform, supporting complex media types, not just plain text, so we can round-trip a vector glyph from Runebender to other font editors. I think that's a taste of being able to take on these more ambitious challenges. Also, "native" UI toolkits are a lot less actually native than they used to be. On Windows, the old HWND-per-control and GDI drawing model (long considered the standard for "native" Windows UI) is long obsolete, and there are actually a whole bunch of toolkits that people use, with UWP the most actively supported. Apple has a stronger story, but even there you have AppKit + SwiftUI, and technically Catalyst is officially supported, though nobody would argue it's actually a good experience. And the fact is, a lot of people are using Electron, because it actually solves the business problem of delivering good-enough UI. I think we have a good shot at competing against that niche, and also that building it on Rust is a more solid foundation than any other language ecosystem.
- pjmlp 6y ago
  You are also missing the eco-system part, having just a bare bones GUI support isn't enough. A sucessful Rust GUI also needs the likes Telerik, Component ONE and similar third party vendors with GUI component libraries.
  - raphlinus 6y ago
    Of course. And once the basics are in place (again, they're getting there but not yet), why wouldn't that ecosystem develop of it?
    - pjmlp 6y ago
      For sure, it depends pretty much how the framework will look like. I still can't think of a way to make borrow checker deal with a GUI designer and drag and drop of components(which should be able to be plugged anywhere on the visual tree), or even something like SwiftUI, without forcing Rc<RefCell<>> everywhere. I am looking forward how Rust/WinRT will look like with WinUI, but again, COM means AddRef/Release everywhere.
      - andrekandre 6y ago
        > something like SwiftUI one thing im having a hard time wrapping my mind around is, if swiftui depends on (please correct me if im wrong) the swift compiler itself and emited static type information from that compiler, how can rust build an interface to that easily? it seems like you'd have to make some kind of wrapper lib that emits extern c interfaces that take and return `AnyView` and thereby hurting performance...?
        pjmlp 6y ago
        By having macros that produce the required information, similar to how Qt, wxWidgets do it, and Rust/WinRT is in the process of doing. https://github.com/microsoft/winrt-rs https://github.com/microsoft/winrt-rs But that is the easy part, the hard part is having the ability to plug a widget anywhere on the tree without triggering a bunch of lifetime errors. WinRT gets around this because it is built on COM, so you get reference counting no matter what.
tormeh 6y ago
React (vanilla, Native, and Electron) is the one to beat here, not platform native toolkits. For a toolkit to be world class today it needs to be cross platform across web, Linux, Windows, Mac, iOS, and Android. Companies want to reduce duplicated effort per platform, in order to make frontends faster and/or cheaper. That's the number one feature a toolkit can have.

by ghouj 6y ago

zerr 6y ago

wxRust needs to be resurrected. wxWidgets is a wrapper around native controls.

raphlinus 6y ago

I agree that support for VoiceOver (and other assistive technology) and full support for keyboard shortcuts is essential for a production GUI toolkit. We certainly don't do those yet, but I do think we can get there. Rust makes it easier to bind platform capabilities at a low level than most other languages. As an example, we do cut'n'paste cross-platform, supporting complex media types, not just plain text, so we can round-trip a vector glyph from Runebender to other font editors. I think that's a taste of being able to take on these more ambitious challenges. Also, "native" UI toolkits are a lot less actually native than they used to be. On Windows, the old HWND-per-control and GDI drawing model (long considered the standard for "native" Windows UI) is long obsolete, and there are actually a whole bunch of toolkits that people use, with UWP the most actively supported. Apple has a stronger story, but even there you have AppKit + SwiftUI, and technically Catalyst is officially supported, though nobody would argue it's actually a good experience. And the fact is, a lot of people are using Electron, because it actually solves the business problem of delivering good-enough UI. I think we have a good shot at competing against that niche, and also that building it on Rust is a more solid foundation than any other language ecosystem.

pjmlp 6y ago
You are also missing the eco-system part, having just a bare bones GUI support isn't enough. A sucessful Rust GUI also needs the likes Telerik, Component ONE and similar third party vendors with GUI component libraries.
- raphlinus 6y ago
  Of course. And once the basics are in place (again, they're getting there but not yet), why wouldn't that ecosystem develop of it?
  - pjmlp 6y ago
    For sure, it depends pretty much how the framework will look like. I still can't think of a way to make borrow checker deal with a GUI designer and drag and drop of components(which should be able to be plugged anywhere on the visual tree), or even something like SwiftUI, without forcing Rc<RefCell<>> everywhere. I am looking forward how Rust/WinRT will look like with WinUI, but again, COM means AddRef/Release everywhere.
    - andrekandre 6y ago
      > something like SwiftUI one thing im having a hard time wrapping my mind around is, if swiftui depends on (please correct me if im wrong) the swift compiler itself and emited static type information from that compiler, how can rust build an interface to that easily? it seems like you'd have to make some kind of wrapper lib that emits extern c interfaces that take and return `AnyView` and thereby hurting performance...?
      - pjmlp 6y ago
        By having macros that produce the required information, similar to how Qt, wxWidgets do it, and Rust/WinRT is in the process of doing. https://github.com/microsoft/winrt-rs https://github.com/microsoft/winrt-rs But that is the easy part, the hard part is having the ability to plug a widget anywhere on the tree without triggering a bunch of lifetime errors. WinRT gets around this because it is built on COM, so you get reference counting no matter what.

tormeh 6y ago

React (vanilla, Native, and Electron) is the one to beat here, not platform native toolkits. For a toolkit to be world class today it needs to be cross platform across web, Linux, Windows, Mac, iOS, and Android. Companies want to reduce duplicated effort per platform, in order to make frontends faster and/or cheaper. That's the number one feature a toolkit can have.