For Rust programmers that want to write GUIs, I highly recommend gtk-rs. It does not have the easiest-to-read documentation in the world but it is a good wrapper of gtk and it suffices for production use. Although it has not reached 1.0 yet, the changes to the API are slow and mostly happen in esoteric corners, so the development cost of keeping up is not noticeable. Further, since cargo has good versioning, it won't update and surprise you.
In the GTK+ 2.x era, I would have agreed with you. GTK+ was either the basis for or easily themeable to feel reasonably native under any Linux desktop environment and, because of the applications which depend on it, pretty much everyone is likely to have it already installed.
Unfortunately, in the GTK+ 3.x era and beyond, the perspective of many KDE users is that hell has frozen over because GTK+ has supplanted MacOS as the GUI with the most alien feel to it.
(Plus, the LXDE developers started a transition to GTK+ 3.x, got fed up, and decided that their upgrade path from GTK+ 2.x would be Qt 5. They then merged with Razor-Qt to form LXQt.)
Personally, what rubs me the wrong way the most is the various ways in which it explicitly goes against what HCI research recommends because the GNOME people just liked it better their way. (And I've read quotes by the devs showing that they now see GTK+ as GNOME's toolkit first and other desktops are on their own if they don't want to ride along... which explains things like how long it took them to stabilize the GTK+ 3.x theming APIs.)
I still might consider it if the gtk3-mushrooms patchset for making GTK+ 3.x less alien weren't a single-person, amateur effort that's only packaged for Archlinux.
The advantage that Rust's GTK bindings have over Rust's Qt bindings is great enough to counteract any advantage that Qt has over GTK. That's because GTK has an (XML?) schema that allows bindings and documentation to be autogenerated to a large extent. Binding to Qt from Rust is in comparison very difficult (not to mention the fact that Qt's idiosyncratic programming model naturally conflicts with Rust's militant ownership concepts).
Edit: To be clear, I'm not comparing the relative merits of different GUI options, I'm saying that GTK is the only option that you really have in Rust today.
As I mentioned in another comment, I value my GUIs feeling native on my KDE desktop (and not having to reinvent things like QSettings and, last time I tried with GTK+ 2.x, drag-and-drop multi-select for list views) strongly enough that I start with PyQt and then add rust-cpython and Rust if enough of the application can be cleanly encapsulated away from the GUI code to justify the added build-time complexity.
please no one turn this into a gnome 3 flame war. all I wan to know is what HCI flaws did gnome make? it seems fairly universally hated, but unconfigured (fresh rhel or centos install). I like it better than 2.x. I recognize I am unusual in many ways so I wanted to know if maybe I was using 2.x wrong. my workflow on any os is press button start typing the name of an app then hit enter dock to a position on screen then do everything from there. I like it shows what is in the workspace when I got the button. I want to dock apps, move between workspaces and move apps between workspace and start apps only using the keyboard. don't muh care about anything else as long as there is a dark theme. rat poison was a bridge to far for me, but that is the general idea
While I’m always surprised that Gnome seems less powerful and configurable with each release, after installing Dash To Panel it’s mostly tolerable. I too have few needs from a window manager beyond ‘runs emacs’.
> 2.1) I want to ship something that looks the same on Windows / Linux / MacOS
As a user: No no no, please, no.
I want apps to fit the look, feel, and idioms of the OS I'm currently in, not "look the same" on every OS.
For example. macOS in particular has many builtin features that work in all apps with standard controls. Like text-to-speech, or converting selected text into all-caps, lowercase, or capitalized. Or custom services/scripts built in Automator.
I may not always use these little tricks all the time, but when they fail to work in some app, it immediately feels lower quality, suspicious, and/or suggests a lazy developer.
It's not pleasant to use something that ignores the special features of a platform in favor of the lowest common denominator.
Personally, I find that most modern UIs that explicitly do not conform to an OS’s opinionated UI design style (for example: the majority of web stack UIs[1]), are often better in almost every way vs apps that do conform to OS style!
When I’m using an advanced UI to do some specialized task, I generally appreciate when the UI patterns I learn on one OS transfer seamlessly to any other device and OS I may use to do the same task.
But I especially appreciate that apps can choose the UI style and design to suit the task at hand, rather than some notion of conforming to OS style patterns that may or may not work in its favor. For example, I prefer that Visual Studio Code looks the same on all platforms, because I find its UI to be superior to the default style of any OS!
What do you think about these thoughts? Am I alone in preferring custom UIs per app, with consistent app experience across devices?
[1] For the sake of this argument, I’m not counting differences in runtime performance and efficiency, since that’s a whole other topic, and one theoretically orthogonal to the UI design.
1. The reason for platform UI conventions is so users can transfer knowledge between apps. Some specialized apps may want to establish their own conventions, because they are aimed at experts who will be investing a lot of time in the app. Most apps aren't in that category.
2. HTML and JS make sucky UIs regardless of how much "work pools", because the underlying APIs are limited and incomplete. For example, scrolling: there is no native support for large tables in HTML, so apps either do some janky faulting in like infinite scroll, or reimplement scrolling entirely. Cut/copy/paste/undo is another example, along with keyboard navigation in general.
Custom UIs by themselves are not the culprit. Apple itself is "guilty" of that, using special controls and styles for their own apps (including even the new Reminders in Catalina.)
But if an app on macOS puts a close button in the upper-right corner of a window or panel (like Windows does) instead of the upper-left, for example, or when an iOS app uses the Android sharing icon, I feel annoyed.
A worse and more practical example is when an app is missing some of the global system features I described in my previous comment, like common text field options (spelling, transformations, dictionary lookup etc.) missing from an Electron-based chat app and so on.
I can understand that some might want the same experience across apps. That said, I tend to agree. I mostly favor applications that are cross platform and similar across platforms. There are times the Mac version, for example, uses mac idioms and I find it painful to use.
Most cross platform applications feel alien somewhere, and I use Windows, Mac and Linux enough that I'd rather a given app be more consistent to the application. Yeah, make the toolbar use the global one if there is one, use the menu conventions, etc... but beyond that, I'd rather the app be pretty consistent to itself over the OS.
As an example, most archive manager applications, and a lot of file transfer/storage applications are really painful to use on macos vs windows or linux where they just feel better and more usable.
Back when I wrote the comment, I tried to make clear that there were two very important and very contradictory requirements :
1. it has to look and behave the same way everywhere (because we don't want to have to retrain users when they switch platform, to maintain several documentation and marketing materials, and because we want to respect the designer's esthetic vision, and / or corporate graphical vision)
2. It has to look and behave native everywhere (because we don't want to confuse users of any given platform.)
Again : of course, I know they're contradictory ! If you have a sword to cut that knot, go for it !
And of course you're perfectly allowed to value requirement 2 more than requirement 1.
And sadly here, different user's interests are not aligned with different software producer's interests, so we're basically not going to please everyone.
Again, I have neither data, nor religion, nor solution about this.
As someone who switches between mac, windows and linux many times over the course of a week, the more similar a given app is across platforms, the more likely I am to choose that app for a given task. There are some low hanging fruit you can do for cross-platform support (menus in particular), but I'm going to prefer same-app to same-app experience beyond that for the most part.
Not particularly fond of the UWP paradigm either. For the most part, Linux and Windows versions of apps line up, but the controls may not match, but even MS programs in windows don't align.
More and more, I'm preferring the MS (Whatever the name of the day) and Google (Material Design) approaches for inside the app, with either an integrated or global menu as appropriate for the platform. With the rest in-app experience with a clean UX.
Again, I understand the desire, but most windows programs, in particular MS generational applications, already have disparate user interfaces.
It could be useful, but at least a bit of funny, if cross-platform apps would offer every platform flavor for every platform. So you would have, for example, a Linux, a macOS and a Windows option for each platform. A 3x3 matrix of options. Also quite a hard problem and a maintenance nightmare.
Electron, as critically as I see it, seems to make a pretty good compromise.
The UIs can be styled and modified to an app author's liking, but unspecified properties fall back to the operating system defaults (assuming the Chrome developers did their jobs well).
Wouldn’t the ideal solution (if you really need rust performance) then be to write platform-Native applications (ie swift/obj-c for Mac) with bridges to performance critical parts in rust?
I’m probably very naive here- since I am not a rust or swift developer!!
Those are some of the outputs possible, TUI is cross-platform, so is GTK and HTML. I don't know why they put them under "supported backends" it would be clearer if he just put "supported output interfaces". If you dig into his "/examples" directory it's all Rust code.
One of those efforts is druid. I'm deliberately choosing not to make a lot of noise on social media yet, but I suggest people actively looking for native GUI in Rust take a closer look. Our team (currently two people funded full time, a GSoC student, plus a growing, dedicated community) is solving the hard problems, and we're on the hook for delivering a basic font editor by the end of the year. The webpage and demos don't look impressive yet, but this is because we're currently focusing on building out the core.
Druid and OrbTk have definitely caught my attention. The challenge for me is that while I have relatively simple needs for now (buttons, text, table widgets), I would like to do things not represented by the examples. With the (understandable) paucity of documentation it's difficult to be productive.
My current challenge is to swap out different top-level views as I navigate to different parts of the app. This may may be something best suited to something like Cursive.rs, but I'm still holding out hope that the GUI toolkits will mature at a reasonable clip.
It's really quite refreshing to see something more portable and lightweight than Electron gain traction. So far the only major detractor I've seen is that the project uses Zulip for chat/messaging and it's put behind a registration wall.
The two funded full-timers focused on making a font editor using druid as the GUI toolkit. I personally think this is the best way to grow an ambitious new toolkit from scratch. Also, there's overlap with the xi team, but in Silicon Valley speak you might say we've pivoted.
The GSoC student project is a GPU compute renderer for 2D graphics. Early experiments (piet-metal) show promise that this could advance the state of the art.
How coupled is druid to druid-shell? It would be great if it would easily be embeddable into projects that already have platform native windowing code.
It definitely depends on druid-shell, but we're also thinking about being a good guest (ie for VST and the like). But honestly our focus is full desktop apps right now.
Good to see more alternatives in this space. If I can make one big app design request it would be this: Don’t assume that apps can always create their own windows. This has been a snag for winit and several others. Allow creating a GUI given an existing window handle.
If you create a rust ui framework that supports the VST windowing/event loop model and just supports one GUI backend on Win32/MacOS, then many people in the audio plugin community would be very happy.
Interesting project, I’ll be checking this out soon.
I’ve been experimenting with several gui libraries in Rust lately and so far the GTK3 bindings seem to be the most promising for building native GUIs in Rust.
With native I mean GTK/Qt style fast/performant widgets that do not necessarily use platform-specific widgets.
This project seems to use GTK as one of its backends. I’m curious to see how the multiple backends architecture will influence the library design as GTK, html and TUI are vastly different.
While i'm not vbsteven, I can probably give a useful answer to your question.
As a KDE user, QML is about as useful to me as GTK+ when it comes to feeling native, so bindings built around those APIs are out.
rust-qt-binding-generator (the one maintained by KDE people) is fundamentally designed around the assumption that you're comfortable writing parts of your program in C++. (It's designed for embedding Rust pieces in a project with its own build automation, like CMake, and where hand-written C++ will still be used for part of the process of talking to Qt.)
rust-qt comes the closest to what I want (something where, as long as I don't touch the `unsafe` keyword and I only pick trustworthy dependencies, I can't accidentally introduce memory-unsafety into my project.) but "Creating custom signals from Rust code." is still on the TODO list and its development seems to have run out of steam.
So far, my solution has been to use Rust to write a cleanly encapsulated backend, use rust-cpython to expose it to Python, and then use PyQt5 (because I haven't started a new Qt project since PySide2 matured) to build a frontend, producing a QML-esque development experience for the QWidget APIs... though I'd still much rather have strong compile-time checks for the entire project.
Yeah, existing GUI libraries tend to make heavy use of inheritance, which Rust doesn't support very well. I have high hopes for a Rust-native GUI library being the goto cross-platform UI library at some point. But that's probably still 2-5 years off at this point.
I have a side question. How are Qt bindings for D? Since, AFAIK, D has one of the best, if not the best, FFIs to C++. I also imagine if D could run on Android's JVM or could it be traspiled to Java. I've seen the latter effort, but quite preliminary from what I remember. Can't really hope for this with Rust, at least not yet.
I want a multi process GUI architecture that lets me send messages to a native rendering process from a bundled sub-process which can be written in any language. Is it a bad idea? I don’t see anybody trying this…
It's a nice idea. One possible implementation could use a Unix domain socket to communicate between client and server. Or even regular sockets to support network transparency. We can call the server X and after eleven versions end up where we are already.
X11 and wide idea of terminals go in hand. It's a problem of abstraction and platforms evolving. So I think, that you either end up with something like Web front-ends of today or something more structured, but far simpler like various TUIs or maybe Tcl/Tk with it's windowing shell wish. I think that some middle ground is possible, but hard and shifting quite fast.
I have liked the idea of NeWS for a very long time. Sadly NeWS was born and died long before it was viable: postscript has always been difficult to write a VM for and unfriendly to application programmers, machines were significantly slower, and NeWS itself was very much vendor-locked.
However, things are different now. We could embed Lua or WASM into the display server, and you'd have a much more programmer-friendly platform that can run efficiently enough to feel snappy. We have more memory, so you don't need to share toolkits between applications.
Funny enough, Chrome Embedded Framework runs multiple processes to render the GUI. The main event loop is running in the host process, but there's others for GPU operations, etc.
You can already do that with X11, any X resource can be used by any process (caveats apply for security reasons, but for applications running locally it shouldn't be a problem) so you could simply pass a window ID to a child process via a pipe and then have it draw stuff on it.
Since its a front end component and front end people are used to looking at gorgeous front ends and since you took the effort to make it functional (well done!) you should take the little bit of extra effort to also make it look pretty so it resonates with your audience. :). Rust is more a system language so you want to avoid that stigma from the outset.
If you are serious in supporting this project, a way to prevent that is by sponsoring the project via the authors Patreon or if he applies for GitHub sponsorship. This has worked for projects like the Zig Programming Language, etc.
This used to be a problem in the past but not anymore. I would really like to finally see Rust's answser to having a non-Electron cross-platform GUI library.
Some charge money for developing products, and it leads to sustained development. Some call those commercial products, and have a tendency to work well. The source can still be open, as open source doesnt have to be free. But many dont want to pay for products, want them free, and at the expense of others.
When it comes to using only GTK+ for the cross-platform use-case, it already has the Cocoa and Win32 back-ends built in via the GDK, which that API is abstracted to GTK+ so that work is already done. It maybe enough to solve the Rust GUI problem on Win/Mac/Linux, however the drawback to using GTK+ is that it will look out of place on other platforms other than Linux, because of the GNOME _look and feel_ it brings.
I think the author might have to support GTK+ theming options to counter this issue then? If not then perhaps using GTK+ for Linux and using the win32 and cocoa crates separately and abstracting that might be something worth looking at?
however the drawback to using GTK+ is that it will look out of place on other platforms other than Linux, because of the GNOME _look and feel_ it brings.
It is not worse than electron in that respect ;). But some small Rust Gtk+ utility that I have for personal uses a whopping 7564KB of resident anonymous memory.
Personally, my issue with Electron is that, in practice, it is hugely inefficient. The up-side to Electron, IMO, is that it doesn't try to straddle the uncanny valley of native GUIs. In GTK, usually everything _looks_ like a normal GUI, but behaves/looks just a little (or, often times, a lot) bit different than what is expected.
This ui framework, if not abandoned by the tedium of win32 api integration, will make me sit up and actually try Rust for the first time. The TUI in particular looks great.
2020 was already slated for Rust for me but this may make me start dabbling in it a few months early (assuming I can find up to date leaning materials)
Tldr great job, please don't give up on the hard part of win32 and macos but this has a great foundation feature set.
The core architecture is not done yet. I put this out in the open in the hope it will get more contributions, since I will be working on to a next project. An enthusiast would certainly be able to play with it and maybe experiment with the core architecture.
So, would you rather have me hoard this into my local workspace until forgotten? Or release it in the open since I will be working on a project that actually pays money. At least if somebody will be building something similar he/she can look up at this code and maybe make a derivative out of it.
I agree that dumping a project in the hopes that someone else will swoop in to do the hard part is a pipe dream. OP is going to find out quickly that it just doesn't happen.
But you lost me here. I don't see how most developers would think there's some issue with dumping code on Github.
For example, I could recommend some avenues for finding useful software that aren't trawling through random Github projects, if that's the problem. If Github had 100x more dead projects, it really shouldn't affect anyone.
It also breaks the site guidelines, which include: "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
I'm not really abandoning it. It's just that I will be spending much less time than I used to, since I am accepting a full-time job to work on something that is not related to this project.
We're considering using it for the next generation of the ZeroTier desktop UI. Unfortunately no mobile support (but we already have native mobile UIs), but it looks like the best contender for a cross platform UI lib that is light and fluffy and simple. Rust bindings should be trivial. There are high quality Go bindings here:
>> a cross platform UI lib that is light and fluffy and simple
Can you comment on whether you evaluated Java Swing or Java FX as a cross platform UI lib for your needs? I am curious to hear others thoughts on the matter.
The problem I ran into using Pis was that 3D hardware didn't seem to want to play well with Qt. Unfortunately since using 3D acceleration for UIs is all the rage almost nothing worked without a lot of tinkering (and even then).
I'm pretty sure this has changed since the last major Raspbian update, but the Pi still isn't quite at parity with more mainstream desktop hardware.
Personally I’d say: separate data and interface logic to the maximum possible level and then write a truly native interface for each platform that matters to you.
This does not apply if your application has so many custom controls that being native does not matter that much (for example a music creation software or a highly advanced raster editor)
