Hacker News Reader

Hacker News

Comment by shmerl | Hacker News Reader

Full thread

shmerl

> On Linux, Druid requires gtk+3

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.

View on HN

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.

Rust has decent GTK bindings, and that's basically the only decent option at the moment.

But better user relm as well, Gtk-rs alone is a bit of pain if one doesn't want to use Rc<RefCell<>> everywhere (see Gtk-rs samples and clone macro).

I thought the whole idea is to create an alternative using Rust. Otherwise you can just use existing GTK or Qt bindings.

What would you propose doing differently than what we're doing? This is a serious question.

Have you looked into iced? It targets Vulkan or WebGL.

He mentions it about halfway down the article along with other systems he's examining.

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)

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.

For a subset of applications DearImgui is suitable.

There's a gallery of screenshots here. https://github.com/ocornut/imgui/issues/123

Unlike the others mentioned it is an immediate mode GUI, which is an interesting approach.

> If you are targeting Linux with a professional GUI application your only options in 2020 are

There are other options. Maybe unpopular options, but options nonetheless: Electron, and immediate mode GUIs.

They certainly have downsides. But there are "professional" GUI applications in widespread use that are written with both.

Immediate mode makes accessibility difficult, in my experience. That's certainly something worth considering.

Applications made in Electron are not professional. I am shocked anybody uses such applications. Electron is basically a web browser displaying a web page.

Are you suggesting that vscode is "not professional"?

> It would be good to also support Wayland compositors without GTK.

So, which text and vector renderer are you proposing? That's not snark, that's a real question.

A GUI that can actually scale requires both a vector rendering engine and a text rendering engine.

On Linux, that's Cairo and Pango--which are Gtk.

I believe that your only other open source vector engine is Skia, from Google.

Am I missing any other options?

Qt. It supports Wayland. It can do high DPI scaling.

Can you pull the Qt vector rendering engine out and use it independently to render to a non-Qt surface? I've never heard of anybody doing that.

One can use Cairo and Pango without GTK?

To a certain extent. You can probably punt the UI widget stuff. However, I suspect certain things like glib are required dependencies.

Cairo does not depend on glib,, but pango does.

There's also Graphite (still alive?) that doesn't...

Skia is a decent option, or if it has to be written in Rust, then something Rust based.

>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...

Check out femtovg https://github.com/femtovg/femtovg

>That kind of defeats the purpose?

Exposing a nice, standardized Rust interface would be the purpose. Then you can switch the backend later (for a custom Rust one or something else).

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.

Not with the purpose I expected first - GUI toolkit in Rust all way through which would imply no GTK or Qt.

You have to start somewhere. Making use of an existing system is a good way to bootstrap a project like this.

If that's the eventual goal, then sure, it's a pragmatic approach.

> That kind of defeats the purpose?

Which 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.

[1] https://raphlinus.github.io/rust/druid/2020/09/25/principled...

>I hope it will become a viable alternative to C/C++ for graphics programming

This already exists, it is called Free Pascal + Lazarus.

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++.

UNIX, like the browser for JavaScript, helped a bit the alternative to win against the competition.

What kind of graphics libraries were you looking for?

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.

  [1] https://github.com/MaikKlein/ash/
  [2] https://github.com/brendanzab/gl-rs

Thanks! I think I overlooked those before--last time I got tangled up in gfx-hal. I'll give these a try!

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.

Of having a pure Rust based GUI without dragging in non Rust dependencies.

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.

> That kind of defeats the purpose?

Disagree. To be GTK 3/4 are main UI toolkits. If your software manages to look like the rest of my GUIs (read themes, fonts) then I will be happy.

However, if I install your software and it's looking like alien - nah. It's better be looking amazing.

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?

Since it's a UI library, I'd say deep enough to take care of the actual UI. Whether it depends on system libc and the like is less about that.

I.e. imagine being able to use this library on something like RedoxOS, not just on Linux. That would fit the idea.

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.

Reply on news.ycombinator.com