GUI libs recommendations

help
1

(This thread is updated and recovered from "solved" state because iced I thought as my target GUI lib seems not support file chooser.)
I intent to write a Minecraft launcher that will be written in Rust, but I felt confused about selecting a suitable GUI lib.
Here are the brief considerations:

  • No immediate mode GUI frameworks

  • File Chooser supported

  • Use native APIs (optional, I dislike using web-based GUI frameworks like Tauri, but I will use it when no more better alternatives available)

  • Cross-platform (optional, but low priority if not supported)

  • Beautiful themes (optional, because I do not want to use such ugly default interfaces like win32)

Thank you for giving me advice!

1 Like
2

For a small application that doesn't need any fancy styling, I'd reach for the iced crate. It's a cross-platform immediate mode GUI framework that works pretty well on all the platforms I've used.

1 Like
3

I’d like to self-nominate Tk if you are already familiar with Tcl/Tk. It:

  • Use native APIs (it’s a high-level binding library)
  • No immediate mode GUI frameworks( it’s retained mode)
  • Cross-platform (works on Windows, Linux, macOS and BSD)
  • Rust-similar coding style ( I’m not sure, but I’ve tried hard to fill in the gaps between Tcl objects/commands and Rust values/functions/closures).
3 Likes
4

you can check slint: it is traditional retained mode GUI, it has custom DSL to describe the UI. and it has a online editor too.

1 Like
5

The probably not literally, but certainly feels like it, exhaustive list: https://areweguiyet.com/

1 Like
6

If you need to write something right now and want to target the desktop, I would choose fltk-rs.

I can recommend fltk-rs because it just works, has cpu and gpu drawn widgets (your choice) and is very low on resources. @MoAlyousef has been doing great work here. The community is small, but it builds fast and link times are extremely short, and you have multiple state and event models to choose from to avoid weird Rust code.

There are incomplete wrappers around so-called "native" GUI APIs such as libui, but on X11/Wayland there are two native APIs (Qt and GTK), and Microsoft maintains Win32 and is pushing its homebrewn version of Tauri (more or less), with all pros/cons. I suppose Apple still has a native UI, but I'm unsure whethere it's actually two APIs or even two APIs and multiple backends.

Unfortunately, the web frontend migration of most, and definitely new, applications has resulted in a decline of this space. Last I looked, iTunes is HTML, as are Steam and new Windows 10 and 11 UIs. Many teams just use something like Tauri because they find it easier to hire web frontend devs, however I'm not giving up and writing my apps with fltk

I'm uncertain what GTK with libadwaita is aiming at and if they want GTK to be used outside of GNOME. Either way gtk-rs (relm4) link times are developer unfriendly. KDE, as the prominent Qt user, has rewritten most of their desktop in QML and is moving away from QtWidgets, with its own pros/cons. You can use QML with Rust easily, but not QtWidgets without wrapping the unsafe FFI wrappers in safe wrappers. Please correct me about GTK and QT where I'm wrong/outdated.

Allow me to rant:

I shouldn't rant because I don't have time for a UI discourse, but the frustration has been building up for years.

I miss the good old days where GUIs were consistent in behavior, very similarly controllable with a keyboard, and you could develop keyboard muscle memory that worked for years. The tablet and then web focus had a negative effect for usability on desktops. And of course I miss the days where contrast, outlines, depth, widget highlighting, and intuitive UIs were the norm. Because UIs are declining, many developers do more in terminal emulators, from what I gather, which is sad and a loss in productivity.

As I'm unfortunately ranting a little, allow me to say dark/light mode should not mean #fff vs #000. You know, there are so many shades inbetween that work and are ergonomically usable for more humans and their devices or environments. Neither do I need unused empty spaces of black/white on the desktop, or aggressively hidden controls.

Pro tools like in media production or engineering haven't declined as sharply.

9 Likes
7

So do I. Sun took a buzzsaw to that trying to corner the market, then everyone else started doing it and pretty soon Web UIs started looking good.

1 Like
8

Are you referring to Sun investing in fixing paper cuts of GTK2/GNOME2, OpenOffice, Accessibility, and doing user studies?

Today, running a pure Wayland sway desktop, I'm forced to apply CSS tweaks to GTK so that it somewhat behaves outside its natural GNOME habitat.

Do you mean everyone followed Sun's focus on desktop apps before the Web 2.0 phase combined with tablets/phones pretty much killed the focus on desktop apps?

9

I tried iced and slint before I moved to fltk. I'm glad I did because the next iced release removed the OpenGL backend in favor of wgpu alone, and the iced demo I built was higher on CPU than the rewrite with fltk. OpenGL is important because wgpu requires newer GPUs for your UI to render than iced's glow backend.

Actually, the same demo I wrote with relm4 is also higher on CPU than fltk. That was GTK4, but the same inefficiency was visible in a similar demo written with GTK3 in C. What I tested was basics like how it handles resizing, entering/exiting the window, and watch how many cycles are used for damage tracking and maybe redrawing.

BTW, you can build your fltk app with support for its OpenGL backend by selecting the cargo feature and choose the backend at startup, with both backends built in the same executable.

2 Likes
10

I browsed it on crates.io but found it has just few downloads, and it does not have abundant docs online, so this lib might not be suitable for me. But thanks for your advice!

1 Like
11

I wote a GUI framwork that incorporates a builtin physics engine and flexbox stlye layout system. Its written in C but I am in the process of porting it to rust. You can see how I did it here, maybe you can get some ideas to implement your own? I built it mainly for rapid HMI stuff, guages, widgets, graphs etc. So the Rust version will do the same. It's not immediate mode because I'm doing double buffering...only parts of the screen that are changed are updated in the buffer...

12

I am not familiar with graphics APIs like OpenGL so using retained mode GUI frameworks is my best choice so far.

1 Like
13

Thanks for your recommendation! I will refer to your lib when necessary.

1 Like
14

iced is retained mode and you don't need to write OpenGL code. If you were confused by my comment, what I meant is that the OpenGL based renderer was removed and likely won't be restored in the next release. Perhaps in a later release, or maybe wgpu will support non-Vulkan setups.

Mildly related and interesting: GitHub - IronOxidizer/gui-toolkit-benchmarks: Benchmarks for measuring the performance of GUI toolkits

15

Wgpu sports a large array of supported backends? That's basically the whole point, really.

16

That's what I read, too, but on Linux machines without Vulkan support for the GPU all I got last year was the equivalent of device-not-found (don't remember exact error).

Edit: Maybe if iced enabled the angle feature it would support OpenGL? I will try setting env var WGPU_BACKEND=gl when I do another test.

Edit: No need for WGPU_BACKEND=gl. wgpu/examples/cube from git, built with default flags, briefly flashes an actual window which means that OpenGL works in principle with the latest code. It crashes in wgpu_hal::gles::egl::Surface::present, so maybe not quite ready yet. Also, sctk_adwaita errors because xdg-desktop-portal-wlr is queried for color-scheme and this isn't planned to be implemented. I feel like sctk should handle this gracefully. But hey, it does actually show a window for almost a second, that's progress over last year and good to see.

17

I understand your worries about the few downloads. Just to mention that:

  1. It’s a binding to the Tk GUI library, which is more popular, available for Tcl, Perl and Ruby and is the "official GUI library" of Python. It’s not a "cool" GUI library but I think it’s easy to learn and suitable for software tools.

  2. The tutorial of this crate is here

1 Like
18

Is native Wayland support planned? All I found last year was a recommendation to try undroidwish instead of regular wish.

19

Huh, seems GLES3 on Linux is only "best effort" support. :pensive: Honestly, it's probably more likely that Vulkan performance gets better than gl before opengl works flawlessly, since I don't know if all of WGSL can be cleanly supported by GLSL.

20

I certainly considered iced but also found it the lack of abundant docs online, but I think contents written on docs.rs are adequate. I will likely eventually select iced if there are no more better alternatives.