If you are targeting Linux with a professional GUI application your only options in 2020 are GTK or Qt (or toolkits that are built on top of those like wxWidgets). The other options lack manpower or features.
In 2020 you need HiDPI support, Wayland, and accessibility. You probably also want a toolkit that has a strong developer community. GTK and Qt have these. FLTK is under active development but it is missing a lot modern features. Maybe it will get there by 2022.
The other option, rolling your own, is a ton of work and a quite a bit of "reinventing the wheel". It's certainly possible but it needs a passionate and dedicated team.
Applications made in Electron are not professional. I am shocked anybody uses such applications. Electron is basically a web browser displaying a web page.
Sorry, couldn't answer before, HN was doing its weird "you post too often" dance.
I guess I misunderstood the intent behind the project. I thought it's like a full alternative to GTK / Qt but in Rust which would be really nice to have, but I get that it would be a much bigger project than something built on top of them.
Ah, yes. There is cross-platform infrastructure we could use, which is what Iced does. We have chosen to do things a bit differently. In general, we use platform capabilities where they're available, for a much lighter weight build and less impedance mismatch with native look and feel. It's a tradeoff, and one of the downsides is that the Linux port needs a bit of extra attention.
Ultimately, I believe our approach will yield higher quality results, but there's a lot to learn from Iced as well.
I remember you wrote before that "there is no such thing as native GUI." Is that more of a high level situation, with text rendering and other lower level things still best handled by "going native"? What other things count as low level like this?
Yes. What I meant by that was more a reference that platforms increasingly support diverse ecosystems of UI toolkits, especially at the high level. Even on mac there's a choice between SwiftUI and AppKit (technically Catalyst too, but that doesn't seem to be a hit), while on Windows there is even greater diversity. So basically it's a way of saying "just use the native toolkit" doesn't actually solve as many problems as one might think.
At the lower level, for some things you really have to integrate deeply with the platform, and for others (text layout is one), there are advantages, including faster builds and smaller binaries. (Ultimately I'd like to have a highly GPU accelerated 2D graphics library that does everything, including text, but that's some ways off and doesn't block current work)
>So, which text and vector renderer are you proposing? That's not snark, that's a real question
I was going to write that there are several, but you already mention most of them. You say though:
"On Linux, that's Cairo and Pango--which are Gtk."
Yeah, they're not really GTK.
Or in any case that's not what people mean when they say they wished a Rust GUI that doesn't use GTK. They mean one that doesn't use GTK+ the lib and widgets, not whether it can use Cairo and Pango...
Many distributions (Ubuntu, etc.) treat GTK as the platform's native GUI toolkit, at least in terms of customization and accessibility features. And, from what I've read on @raphlinus' blog, one of the goals is to integrate well with the native platform. So I think, rather than defeating the purpose, it's entirely in line with the purpose.
Speaking as an outsider, I have been watching Rust very closely for two reasons:
* I hope it will become a viable alternative to C/C++ for graphics programming. Unfortunately, last I checked as of ~6 months ago, Rust graphics libraries are still in their infancy.
* I hope it will eventually replace Electron as the go-to for multiplatform app development. IMO this cannot realistically be done by relying on native APIs / platform-specific tools like GTK, since we need something closer to functional reactive programming a la React/Svelte/SolidJS, with more emphasis on performance. If I wanted to build a GTK app, I would build a GTK app. See also [1].
I believe Rust has the potential to accomplish both goals, partially due to the design of the language, but mostly because I have faith in the very smart people who work on Rust to make good decisions in the long-term.
Care to elaborate? AFAIK C/C++ emerged as the alternative to Pascal way back when. No sense moving backwards--it's clear Rust is on track to displace several common uses for C/C++.
Just basic, stable support for OpenGL / Vulkan. My reading from ~January of this year was that there were several competing methods for graphics support in Rust. I tried a few and the boilerplate was quite a bit more than expected, and I was unsuccessful getting the available samples to run on my Linux machine.
Admittedly, I know nothing about what's actually going on behind the scenes when it comes to graphics + Rust. Just my first impressions as an outsider. I found the existing libraries quite difficult to get started with.
(I'm someone who doesn't know much Rust and is waiting for some of this functionality to mature -- someone already invested in Rust is certainly in a better position to take advantage of the existing graphics support)
Ok, in this case, I think the situation is fairly good. De-facto standard for raw Vulkan in Rust is Ash [1], and raw GL can be worked with GL-rs [2]. It's when you go higher levels where things start diverging more.
There is nothing wrong with gfx-hal. I care deeply about it, and wgpu implementation is based on top. It's just for users who need portability and performance, while Ash gives you close to raw access to Vukan.
That's nice to have, but maybe not a central goal. It's worthwhile to have a library that's designed with Rust in mind and can take advantage of its features and idioms, even if it uses non-Rust libraries somewhere under the hood.
From the article:
> One strength is Rust’s wide “dynamic range” – the ability to describe application logic in high level terms while still being attentive to low level details.
Do you mean main in Gnome? I prefer KDE and Qt to anything GTK based if it's not about Rust. And if it's about Rust, I thought it could be good to have some alternative that's neither GTK nor Qt and is just using Rust all way through.
Define "all the way through"? I mean, on Windows, for example, you're always going to have some C or C++ code from Win32 DLLs on the stack in any GUI app, because you'll need a top-level window even if you're rendering everything else yourself, and it will have a Win32 message loop etc. But if that's acceptable, what's wrong with using the system libraries for text rendering, or even complete widgets?
But what constitutes "actual UI"? You have to link to way more than system libc to make a GUI app on Windows.
And it's kinda orthogonal to using it on OSes that don't have their own UI layer, because that can be implemented as another backend. For example, wxWidgets wraps native widgets on Win32/macOS/X11 (with Gtk considered "native" for the latter) - but it also has wxUniversal, that renders by itself, and is the backend normally used on platforms like DirectFB.
That kind of defeats the purpose?
> Alternatively, there is an X11 backend available, although it is currently missing quite a few features.
It would be good to also support Wayland compositors without GTK.