I've done professional GUI programming and there are really only three options that make sense:
1. Write the GUI natively per platform. This is best from a UX perspective but is expensive and you probably need different developers working on different platforms. Other downside is that really advanced functionality is harder to implement and sometimes the performance of native APIs is poor and hard to improve (Apple has this problem frequently).
2. Use a cross-platform framework like Qt (Electron would also go here). This is the most cost-effective solution, but generally does not feel like a native app, which may or may not be a problem.
3. Use a custom GUI framework.[0] Probably the most expensive option and hard to hire developers for, but can be warranted for complex applications like CAD tools, games, etc.
The problem with Rust GUI libraries is that they can't really target 1 or 3 so they need to target option 2. But the big players there are Qt and Electron. Qt is popular because it works well, is proven, and has a lot of financial backing. If you don't need something super complicated a decent Qt developer can get it working quickly. Electron is popular because there are tons of web developers and they can be productive quickly.
Rust attracts a lot of hobbyists who are talented and have good ideas, but I don't think they have the staying power (or financial ability) to provide something that competes with Qt and Electron. I'm sure it can be done in theory but I don't see it happening in practice anytime soon.
[0]: By custom I mean tailored for the type of application you are making, e.g. what a lot of game devs do for their internal tools.
> 1. Write the GUI natively per platform. This is best from a UX perspective but is expensive and you probably need different developers working on different platforms. Other downside is that really advanced functionality is harder to implement and sometimes the performance of native APIs is poor and hard to improve (Apple has this problem frequently).
That really depends on the software though. I develop a media software and my users are adamant that they want the exact same look&feel across the three main desktop platforms (to the point that I had to use freetype everywhere for font rendering - thankfully easy with Qt). Also had the same case for a customer at a previous job - I remember comparing screenshots across macOS and Windows until they matched in a pixel-perfect way.
On the other hand, if you're writing, say, a productivity app, calendar, notes manager, most likely it is better for it to fit to each platform.
Although I personally also prefer to use the same apps across platforms, e.g. my main combo no matter whether I'm on Linux / macOS / Win32 is Zim for note-taking, Strawberry for music, Qt Creator for IDE, Seafile for data exchange, Telegram and ripcord for chat, Krita for image manipulation, Darktable for raw photo processing, Digikam for photo collection management ; DaVinci Resolve for video editing.
With the exception of Zim and Darktable which are GTK, all the others are Qt-based.
If this is editing audio or video, I can 100% believe that. Anything with complex controls that a user has to learn, or keyboard shortcuts, it really matters to end users.
I worked on a Qt app quite a few years ago and that wasn't a media app but it was a complex GUI. Our end users also wanted the exact experience regardless of platform.
On a related note, if you need a rich UI I totally recommend using Qt on the frontend and the backend. Qt isn't just UI libs. There are a bunch of super useful server-side libraries as well that you can use. We used protobufs and had unbelievable performance on the front end and backend. It was a beauty to behold.
The point of making native apps is that once one has learned how to use the computer, they’ve simultaneously learned the basics of using every single native app made for it. If a Mac app uses control C to copy instead of command C just to achieve parity with the windows version, that would likely be considered a bug, not a feature.
I'm honestly not sure it really matters for most people. This year I taught a bit of programming with p5.js to design students who are between 18 and 22-23 years old. Over ~50 students, maybe 2/3 were aware that keyboard shortcuts even existed. To them their computer is merely a gateway to Adobe tools.
Those were students. That's like spending time with computer science students, then saying only 2/3 of software engineers are even aware that git exists.
Most graphic designers I've met have been more adept with keyboard shortcuts than I am. It's impossible to be productive in Photoshop or Illustrator just using a mouse to click on menu items. Beyond copy+pasting, I use barely any shortcuts, I generally use zsh and type commands instead. But in media workstation software, keyboard shortcuts are the equivalent to unix commands for programmers.
Should Starcraft have different UI and keyboard shortcuts on Mac and Windows? Should a Marine's steampack use command instead of ctrl on a Mac? Ofcourse this question makes no sence, the game is so different from 'normal' apps, it has no copy paste!
Learning Blender, Eagle, Inventor or Starcraft requires you to learn about a hundred keyboard shortcuts and hundreds of UI aspects that are spesific to that domain. There are very expensive, large pieces of software that require thousands of hours to master. Thats why Photoshop looks the same on every platform.
To suggest they should use os native controls basically indicates you have no experience with them - there are no standard OS cotrols for bevel, extrude, build siege tank, or start network rendering.
end-users. It's very important for them to have the software be exactly the same no matter the platform, as it's somewhat common to start a work on e.g. a mac as a first draft and finish it on a windows or linux machine where the production actually runs.
Electron is popular because it gets the job done quickly. I can start a new Electron app in 10-20 minutes and build it across Linux/Mac/Windows in moments. There's almost no setup needed except node which is easy to install locally (nvm, nvm-windows). Most other solutions require installing large tool chains manually first and lots of pre-reqs and being familiar with those tool chains. On Electron I just "git clone proj && cd prog && npm i && npm run build && num run dist" and an installer/msi/dmg/AppImage pops out.
I'm fully capable of writing a native app or using Qt but for a large number of apps my clients won't notice a difference and I can be finished faster with Electron so I use Electron.
I even use to just provide a GUI shell over running command line tools. Sure it's "bloated" by some definition of bloated but I get the job done so much quicker and 99% of the cross platform issues disappear.
> Electron is popular because there are tons of web developers and they can be productive quickly.
It's also popular because a browser engine as a lot features that are otherwise difficult to get (e.g. bandwidth-estimated multiplexed video streaming).
Also accessibility and bulletproof text rendering and input handling and layout and a million other things that are a lot more involved than people think. I say this with great sadness as someone who wishes Electron wasn't the most practical solution at the moment.
> Use a custom GUI framework.[0] Probably the most expensive option and hard to hire developers for, but can be warranted for complex applications like CAD tools, games, etc
This will also suck for users because things like focus, keyboard shortcuts, accessibility, non-English text rendering, etc will probably not work as expected if at all. It turns out there's a lot that goes into GUI that most of us take for granted.
I've worked as a GUI developer with Qt for years in the past, and I think that library/framework is an awesome technical feat. It would be a pity if Rust (or any other language, for that matter) had to start over from scratch and reinvent their own toolkit, instead of taking advantage of the years and heaps of applied knowledge (and optimizations) that some older toolkits already have.
If all the man-hours required to design, write, and coordinate the creation of a GUI toolkit that's the same level of advanced and mature, are instead employed in overcoming any difficulty in creating the best possible bindings, we would end up with a heck of a good quality bindings for Qt and still probably for 1/10th of the human effort. All IMHO, of course.
(Disclaimer: My knowledge of Rust very limited, but I have quite a bit of experience with getting Qt/KDE classes to work with other languages.)
You are absolutely right. The effort to be acceptable bindings for Qt would be a tiny fraction of the cost compared to building a whole new Rust native GUI library.
Qt is huge set of libraries with an equally huge API. But there are a lot of shortcuts and smart ways of approaching the problem to get what you want out of Qt for minimum effort.
Bindings like PyQt and even PySide go for the nuclear option of generating bindings for the whole Qt API and trying to match the C++ API in style too. This is an absolutely massive huge task. Also, getting people to contribute to an open source bindings project is hard. Getting people to contribute to a bindings generator is even harder.
NodeGui https://github.com/nodegui/nodegui, Qt bindings for Nodejs, on the other hand takes a very different approach which in one way is low-tech but I think is actually very smart. I'll summerise the differences:
* It focuses on Qt Widgets first. This greatly reduces the amount of work to the parts that people actually need. (BTW, if you just want QML and Rust back-end then Jos van den Oever's work at https://invent.kde.org/sdk/rust-qt-binding-generator has probably got you covered already.)
* Mostly hand written, no generation techniques being used. This makes the bindings code repetitive yes, but also easy to understand, easy to debug, and easy to extend. That greatly lowers the barrier for casual contributors.
* Doesn't try to copy the C++ API 1:1. For example, to extend a widget in C++ you are expected to subclass it directly and override methods etc. NodeGui chooses a more composition approach where method you might override are instead exposed as events. Another example, the Qt API is encrusted with convenience methods and overloads. Most of these can be skipped or implemented purely on the JS side.
* Intercepts most events via `QObject::event()` instead of trying to do this method by method (i.e. in QWidget's collection of event handling methods). Smart move.
* Qt has a lot of tiny value classes which can be replaced in the API by JS native objects holding the same data.
I agree that a more selective approach might be better.
The typical response when talking about bindings to Qt is that there are so many impediments to make a decent bridge between language X and the C++ land. But I think that while correct (I've suffered trying to do it myself), it never compares that effort with what would really take to do it from scratch and get to a comparable level of features or robustness. Not only because of the code itself, but because of the knowledge, the know-hows and know-whys of the field, all the tiny decisions that the original library made and you'll take ages to come up with and make too.
It's not just a matter of putting in enough man-hours to create decent bindings. Native-C++ libraries are hard to write good bindings for in the best of times, typically requiring C wrappers with limited functionality and/or significant runtime overhead. Creating workable and safe (but still non-idiomatic) bindings for a C++ library from a language like Rust with a very different object model (can't use C++ templates or define new C++ subclasses; functions called from Rust must not throw C++ exceptions) and a far stricter type system than either C or C++ (borrow checking, lifetimes, thread-safety enforced at the type level) can be next to impossible. Even if you succeed, the result will be restricted to the least common denominator supported by both C++ and Rust and will never feel like a native Rust library.
This is not to say that Rust could not benefit from the significant effort which has gone into developing Qt, but a Rust port of Qt might be more workable than bindings to the C++ toolkit.
> a Rust port of Qt might be more workable than bindings to the C++ toolkit.
That's an interesting idea! it might be worth considering it, at least.
I wasn't thinking of a full-blown bindings that cover 100% of the API which is an immense task and, as your sibling comments thinks, was a mistake. A more opinionated stance of what parts of the Qt features are deemed necessary seems more feasible in the short to medium term.
I wasn't advocating for one specific way of doing it, but for the more general sentiment that reinventing the wheel and creating a new toolkit from scratch is definitely the most expensive of all the options, in terms of human effort, time dedicated, and progress achieved. We'd basically be decades later than other OSS options, why not build upon their shoulders instead?
However I think you need to differentiate between GUI for internal tools and customer facing products.
Dear ImGui is pretty damn stellar for internal tools. Nigh unbeatable along certain axes. Rust has a couple of Dear ImGui inspired libraries. I think for tools and editors Rust is getting close to being perfectly viable.
For customer facing GUI I largely agree with your assessment.
It's not very clear from their docs, but it looks like tauri is mostly a way to launch a system WebView from rust and communicate with it via message passing. Doesn't really seem like a GUI toolkit for rust, since all the GUI stuff is going to be done in JS.
The difference is that Electron guarantees you're always using a known version/engine. With Tauri, you'd be using whatever is installed, and that engine may behave different from what you are used to.
So basically you get all the drawbacks of developing for different web browsers, without really any of the benefits a cross-platform GUI gives you.
Does it use less RAM because it's shared with the system browser? I sure as hell avoid all the Electron based apps because of their memory consumption.
Cross-browser compatibility is not too bad these days.
I did some testing using webview (https://github.com/Boscop/web-view) which is used by Tauri if I'm not mistaken. On Linux this uses webkitgtk, and it used a total of around 100 MB. That's not that good, but certainly better compared to Electron.
The most viable competitor to Electron other than Qt are the Java GUI toolkits. There are several but the two main ones are Swing (old, mature, not gonna win any prettiness awards but it gets the job done well enough in IntelliJ), and JavaFX (pretty darn good but people forget about it).
I've shipped apps using JavaFX before. It was quite a pleasant experience and I'd do it again in a heartbeat.
Themes are something they would like to implement and once they have themes they could do native looking themes like Qt (which are perfectly reasonable, I'm generally very happy as a user with Qt applications across all platforms)
I agree with you there is not yet an audience big enough to justify a Qt written for Rust, but who knows, maybe something will change in the next years.
That said, when I had to do something like this, I used Qt with Rust, just because I couldn't justify the time investment of reimplementing a native looking theme on top of Conrod.
Wrt option (2), what do you think of other libraries like wxWidgets or GTK+? At least on Windows, the latter certainly doesn’t feel at all ‘nice to use’ (admittedly a subjective criterion), but I find I quite like programs made with wxWidgets.
GTK+ on Rust is a thing that is seeing a lot of active work (see https://gtk-rs.org/). I think some of the core gnome stuff has even moved over to rust at this point (like libsrvg).
I have used wxlua in the past and it's a seriously underrated feat of engineering in my opinion. It would be great if there were somehow a wrapper for wxwidgets that plays well with Rust, fingers crossed.
Why does Rust need to compete with QT? Most programming languages have QT bindings.
Similarly, different languages could work with Electron through compile to JS/WASM.
> sometimes the performance of native APIs is poor and hard to improve (Apple has this problem frequently).
Compared to the alternatives (especially Electron, where you oddly forgot to mention this), the performance from native Apple APIs is often the best you can get.
I like Apple a lot, it is the most pleasant platform to develop for IMO, but performance depends a lot on what you're doing and how much they've optimized it.
There's a lot of custom rendered stuff there. The problem with that is, without a lot of work, custom GUIs are completely opaque to screen readers and other accessibility tools.
I've started working on this. I'm not really ready to loudly announce this yet, but you can check out my plan and what little code I have so far (really just data structure definitions) here:
Really looking forward to seeing where this goes! A good, cross-platform abstraction for accessibility could make a big difference for a lot of people. Certainly I agree that accessibility is one of the major differences between a toy UI toolkit (of which there are many) and a real one (of which there are none yet in Rust).
I would like to see an cross-platform accessibility library, that would branch out to become a cross-platform widget toolkit, than the usual "we render widgets ourselves and accessibility is not even planned yet".
But with the popularization of apps, webapps and Electron everyone is accustomed to custom UIs for every app. Does the Spotify app feel Mac-like? Barely. Does it need to be? Not anymore.
I think that as long as we don't see badly-drawn UIs and "ugly styles" (like Java apps’ gradient buttons) we're good nowadays (given that someone actually designed the UI)
I disagree. The fact that most users don't explicitly care is irrelevant — platform conventions are important. They teach a user how to use a new app without having to poke around. Users can drag and drop from one app to another and it just works.
I certainly see the argument that for many companies, it's simply too expensive to write native apps for every platform. But I don't think we need to pretend that non-native apps aren't worse — they're just economical and generally, even at their best, just _okay_.
> The fact that most users don't explicitly care is irrelevant — platform conventions are important. They teach a user how to use a new app without having to poke around.
I agree that's important. But I think it's much less important these days now that operating system developers seem happy to churn their platform's UX every couple of years too. The days when you could read the Apple Human Interface Guidelines and understand how all Mac apps would behave for the next decade are long gone, unfortunately.
For reasons I don't totally understand, the platform vendors are themselves constantly invalidating the information in users' heads, so there's simply less in there for application developers to build on anyway.
> operating system developers seem happy to churn their platform's UX every couple of years too
Since the top-level comment in this subthread is about accessibility, I should mention that the churn is especially bad for blind people using screen readers. That's why I'm apprehensive about Windows 11.
When Windows 10 came out, I was the developer of a third-party screen reader. I did what I could to deal with the platform churn, in the limited time that I could give to it. But I was happy that no critical applications (even Office) were following where the Windows team was trying to go with the platform; once you started up your applications, your PC basically worked the same as before -- even more or less the same as Windows 7.
Then I joined the Windows accessibility team at Microsoft. I suspect that if there had been any significant UI churn in Windows while I was there, the cognitive dissonance that I felt during that time would have been stronger. Perhaps I could have done some good for the experience of using Windows 11 with a screen reader if I had stayed, but then again, an individual developer in an org that big usually doesn't have a lot of power. Anyway, I had my reasons for leaving, and I'm glad to be free to share my honest opinions on Windows again (within the bounds of my NDA).
> For reasons I don't totally understand, the platform vendors are themselves constantly invalidating the information in users' heads, so there's simply less in there for application developers to build on anyway.
To be honest, I'm not sure this is true. macOS has had pretty much 1 major redesign in recent memory (Big Sur), and even that is mostly a visual update -- functionality is all still there and works the same. Toolbar buttons are still toolbar buttons, you can still drag and drop them around, etc etc. In practice, the amount that actually "churned" is pretty small.
I think that ship has already sailed with the prevalence of the web. Users are already very used to learning a new UI for a new app, their online bank doesn't work like Gmail does, nor does Netflix, etc. etc.
Sometimes it feels like OS UI is literally just window dressing these days.
Sure but the argument being made was that native UI helps users learn to use apps. My point is that users are very used to learning entirely new UIs on a regular basis.
Generally I prefer an app that exists to an app that doesn't exist. Companies that can afford multiple teams are still going the multi-platform way and those who can't, still do it. At the end of the day, you can choose the best app available.
I too would like every app to be a 2MB Swift app, but those are rare for a reason.
It's more than just looks: Electron exactly replicates how the OS handles scrolling and text input, while custom frameworks often don't. Lacking macOS's scrolling velocity or being unable to add accents to letters in a text input gives the app a different behavior, which is distracting and feels bad.
I disagree on this "not anymore" part also. For example the Discord app is cool and hip or whatever but it feels totally off and the UX is totally foreign on Windows. It's one reason other than the fact it's not free like mumble that I've never really become an active user on the platform. Just feels awkward to use kind of like Steam does.
I just spent a few hours evaluating WinUI 3 for a new project. There's currently no way to hook into the app exit event. Want to flush your SQLite store before you exit? Tough.
I'm not sanguine about this actually having any staying power before they get distracted or have another internal coup and it goes in the dustbin with all the other UI schemes they've rolled out and then abandoned over the past decade.
I would put my money on WinForms being ported to Linux first...
One of the tags you can select is WinUI. Another is MacOS. So they clearly thought platform-specific UI might be usful to someone. It may not scratch your itch, but that doesn't mean it's useless.
For my part, I'd argue that, if you care about inclusiveness, you should probably favor either Electron or some other option that builds on the Web stack, or writing a separate native front-end for every platform. The problem with all the cross-platform toolkits is that they have accessibility problems.
I have switched half back to Windows (after a decade of 100% Linux) recently just because I finally accepted there is no way of making GUI apps as a single developer nearly as easy and pleasant as WinForms with VisualStudio. The result is virtually Windows-only (it can run on Mono but there are some quirks) but it feels worth that sacrifice.
It is WAY easier than WinForms. WinForms' VS "integration" feels as if they started with what Delphi 1 could do back in 1995 or so, implemented most of it and then decided that is enough.
Lazarus' GUI tools are way above and beyond anything WinForms can do and the underlying LCL is crossplatform using native widgets wherever possible with backends for Win32, Gtk1/Gtk2/Gtk3 (though Gtk2 might be the best ATM), Qt4/Qt5, Cocoa and a few others (Carbon, fpGUI and some Amiga toolkit).
Here is a video from 3 years ago where i make a simple sliding image puzzle game under Linux using it:
Pascal seems a way too vintage programming language (not nearly as handy as C#, let alone C# 5.0) and the IDE's editor isn't nearly as intelligent as that of VisualStudio (let alone with ReSharper). But it indeed seems the only of the kind truly cross-platform. The only close-enough alternative I found on Linux was QtDesigner+Python but it still wasn't that convenient.
I adore people who code Lazarus (e.g. Double Commander authors - they have been doing an amazing job with visible progress and persistence all these years) though. Perhaps I'm going to dedicate some time to learn Pascal once, just for this. It would be easier if they had a seamlessly-compatible C++ version at least (like Delphi had).
Keep in mind that Free Pascal is not exactly the same as classic Pascal. The language has a lot of features you'd find in other modern (as much as Java and C# can be called modern nowadays anyway) object oriented languages. Things like classes, interfaces, dynamic message dispatch, properties with getters/setters, for with ranges, dynamic arrays, generics, a rich RTTI (though not as rich as managed languages - yet, it is work in progress - it is rich enough to do things like serialization, etc), etc.
As for a C++ version, it would be useful (though i find Free Pascal a better language overall, despite its warts - the only thing i wish it had from C++ was 'const' and slightly more powerful generics, but both aren't that big of an issue and generics are improving anyway) but VERY difficult to do as i wrote some time ago here [0] and here [1] where i went into more details about the language side of things (C++ Builder has extended C++ to allow for Object Pascal-isms because VCL itself is written, like LCL/FCL, in Pascal, which for Borland was possible because they made both the Pascal and the C++ compilers).
[1] https://news.ycombinator.com/item?id=19882489 (note that the discussion was originally about using LCL from C++ so i also mention the alternatives - and how not having the rest of the IDE would end up with a worse wxWidgets since LCL isn't really designed to be used purely via code)
Please don't assume bad faith. Glade was not "killed," there are technical reasons why Glade cannot be used for GTK4 (I can give more detail if you want). There is currently a new tool being developed by a Glade maintainer, catch this guadec talk later this month if you want to know more: https://events.gnome.org/event/9/contributions/191/
Nobody is particularly happy about having to edit the XML directly but it's the best option right now until the new tools stabilize.
I think that this might speak to the deeper problem that a lot of people have experienced with GTK: stability. The project isn't a huge well-funded company with lots of vendor-lock in like Microsoft is; it can't afford to be rethinking how the GUI toolkit should work every few years like Microsoft does. (Or continuing to support and maintain all the old no-longer-favored GUI frameworks like Microsoft does.)
It's great that GTK4 has decided to commit to API stability, but, at this point, it may be too little, too late as far as the project's reputation among many developers is concerned. Having to lose a venerable tool like Glade to get to the API-stable version doesn't exactly take the edge off.
I've posted about this before, but if you want GTK and you believe API stability is the most important thing then you should just use GTK3. The API there is frozen. I'm not sure what "reputation" you're referring to but if GTK does not meet your needs, and Qt (or something else) does, then I think that's great for you, you should just use that.
GNOME being slow and not having basic features like thumbnails in the file picker after almost 18 years was often attributed, by their maintainers, to be caused by GTK3 limitations. Even now Glade still needs a lot of "volunteering" to be production ready for GTK3. I don't use GTK anymore, this is my opinion after reading a lot about it and seeing recommendations like "if you need documentation just read existing code", "why is Glade missing X or Y? just copy some XML node, just edit the XML and pray".
Anyway who cares, maybe GTK4 is good and new GTK threads will not be full of people talking about how bad it was. But why not move the tools together with the rest? I know, it's open source, lack of maintainers, but I wouldn't dare to declare my toolkit stable until basic tools work. Qt is also guilty of doing that in some ways but at least the previous version is still production ready and they move really fast.
I don't know I'll ever get over my irrational anger about how they handle(d) GTK.
> if you want GTK and you believe API stability is the most important thing then you should just use GTK3. The API there is frozen
That is certainly not a solution, you just postpone the problem.
The real solution would be the Gtk4 to be 100% backwards compatible at both the API and ABI level with Gtk3 and similarly with Gtk5, Gtk6, etc.
Otherwise you're just subscribing to wasting your time - it might be now or it might be 5 years from now, it doesn't matter however as it will happen unless the Gtk developers finally decide to stop breaking their library every few years.
(of course don't get me wrong, it is their library and they can do whatever they please with it, they are giving it for free and they are not beholden to anyone - however that doesn't mean others like to have their code broken and waste time that they could use to improve their applications instead)
Alternatively GTK3 could get a higher level of ongoing support. That was what I was alluding to when I referenced Microsoft. For example, WinForms has technically been superseded for ages now, but, while it's not necessarily getting any big new features, WinForms apps still look decent on newer versions of Windows, benefit from things like updates to the common dialog boxes, and continue to be well-supported in new versions of the developer tools. So one doesn't necessarily have to have a lot of anxiety about leaving an old WinForms app on WinForms. With GTK3, on the other hand, I would guess that it's going to get the absolute bare minimum of love, and probably become a liability rather sooner than I might like, because the project simply doesn't have the resources to maintain a higher level of support.
And yeah, you're right, the GTK team isn't beholden to anyone. But... GUI code is expensive to write and expensive to maintain. So a GUI toolkit can have an outsize impact on the health of projects that use it. There's value in talking about things like this publicly, so that anyone who's shopping for a GUI toolkit can have a better understanding of what they might be getting into.
Ideally they could have done that with Gtk2 which would continue on to Gtk3 and Gtk4 without breaking backwards compatibility.
Of course yes, the next best thing wrt. backwards compatibility is at least not breaking what works - but IMO that is a waste of time for both the Gtk developers (sure, it'd be self inflicted, but still) who would need to support two (or three or four or however many times they decide to break their own APIs) libraries that do essentially the same thing in different ways, and for the developers who at the end of the day will most likely need to move on to the next version at some point to gain access to new features that they may need - so they'll spend that porting time anyway.
> And yeah, you're right, the GTK team isn't beholden to anyone. But... GUI code is expensive to write and expensive to maintain. So a GUI toolkit can have an outsize impact on the health of projects that use it. There's value in talking about things like this publicly, so that anyone who's shopping for a GUI toolkit can have a better understanding of what they might be getting into.
Indeed and this is why i mention my issues with backwards compatibility whenever i see it being relevant.
I do believe the Gtk developers are free to do whatever they want as they are not beholden to my -or anyone else's- wishes for stability, especially when they give out such an otherwise high quality library for free. However that is from their perspective.
From the library users' (that is the developers who use the library) perspective however there are additional issues, like all the time you spent learning the library (breaking the API invalidates your own knowledge which is something that is also important - unless you plan to somehow live forever it makes sense to want to avoid this sort of "knowledge churn" :-P) and writing the code that uses it (important especially for framework-style libraries like Gtk that put their tendrils everywhere in your application). And even if someone believes (wrongly, IMO) that commercial developers can afford all that time, it still is an issue with FLOSS since the vast majority of which is developed during its developers' free time: that time would have better been used to improve the applications instead of keeping up with their dependencies' breakage (e.g. XFCE or... Gimp :-P).
And of course from the end users' perspective it also means that even if the developers decide to drop a program, they can keep using it for a long time without having to worry about the libraries their program depends on getting stale (since they are linked dynamically), not supporting new features (like, e.g. Wayland - AFAIK Gtk2 apps do not support it natively and chances are if a new display server is made Gtk3 apps wont support it either) or having unfixable security issues (for the applications where that makes sense at least).
But yeah, Gtk developers - or any library developers - do not need to care about all of that nor they have to really. As you wrote, it is the developers who decide or not to use a library that care about such things mostly.
Sadly at last on Linux there aren't that many choices: of the "mainstream" toolkits only Gtk and Qt exist. Gtk is, well, Gtk and Qt cannot provide "perfect" ABI compatibility even if they wanted to because of C++ (there are some hacks that could be made but i am not aware of any project doing such a thing - i think only Haiku does something similar with proxy libraries that forward the GCC C++ 2.95 calls to modern GCC C++ calls for BeOS compatibility). But Qt is also a different beast, they are a middleware company with different priorities, the people that pay money on it (and thus affect these priorities) do not care much about providing a stable platform and can affort to waste time on upgrades. From other toolkits there is also Motif but that fell out of favor and got opensourced way too late to make much of a difference - its API/ABI is stable though and has been stable for decades, but that means nothing when barely anyone uses it or develops for it.
Personally i use Lazarus and LCL. LCL uses a variety of backends, kinda like wxWidgets, but unlike wxWidgets it doesn't break its API. This pushes the issue of keeping up to date to the LCL developers (who could have spent their time in fixing LCL's other issues - of which are many - instead) but that is how things are.
I think Java and SWT might be another stable solution for a native UI, AFAIK this never broke backwards compatibility either... or at least it never did back when i looked into it several years ago. Looking at some examples in their site, several of them seem to be somewhat old so it probably is stable (isn't it great how when you do not break your API left and right you get to also get time to build better documentation that you don't have to invalidate it after a while?)
> Qt cannot provide "perfect" ABI compatibility even if they wanted to because of C++
That does not really matter in practice though. I ship a Qt app as AppImage, it works fine from CentOS 7 to the very latest ArchLinux. I just ship libc++ along with it - which is the same that I have to do in Windows anyways.
Of course it matters in practice since we're talking about dynamic linking that applications can link against the OS-provided libraries so that they can keep gaining new features and bug fixes.
A trivial example on Windows would be how Win32 applications get to use the Win+; emoji popup even if they were made before Windows even got that feature, or how even classic VB applications can be made to run in HiDPI mode by ticking a shortcut checkbox despite being written decades before HiDPI was even a thing (assuming they use twip instead of pixel coordinates at least).
Or on Linux, how some old games made for it need their bundled SDL removed so that the games can use the system-provided version because the old version tried to use OSS or whatever was common at the time the game as written and the new version can use ALSA or even Pulse that didn't even exist in older times. And i remember reading on twitter about some distros planning to provide the SDL1-to-SDL2 wrapper as an option instead of the real SDL1 because it provides better compatibility with some modern window managers... and Wayland (that SDL1 doesn't support at all but the API doesn't really make a difference and could work perfectly fine with Wayland).
> which is the same that I have to do in Windows anyways.
Windows comes with WAY more functionality out of the box so that applications do not have to rely as much in their own libraries and can rely on the OS to provide and keep functionality up to date. Of course applications can ignore that, but they just do not get those new features and fixes.
The recent Visual C++ runtimes not being part of Windows is a baffling and really stupid decision though. I am certain it has more to do with internal politics and feuds between WinDiv and DevDiv than something practical.
> A trivial example on Windows would be how Win32 applications get to use the Win+; emoji popup even if they were made before Windows even got that feature, or how even classic VB applications can be made to run in HiDPI mode by ticking a shortcut checkbox despite being written decades before HiDPI was even a thing (assuming they use twip instead of pixel coordinates at least).
eh, I really really disagree with this. In my experience more often than not this kind of changes breaks the app in various ways. What if the app was using that shortcut for something else ? Now it's broken and can't be used anymore.
Likewise for the hidpi thing that windows does, it's terrible - running the app at original resolution and applying a 2x nearest neighbor filter to the whole window would be better than that mess of "crisp" text with upscaled pixmaps that were never made for this resolution.
> Or on Linux, how some old games made for it need their bundled SDL removed so that the games can use the system-provided version because the old version tried to use OSS or whatever was common at the time the game as written and the new version can use ALSA or even Pulse that didn't even exist in older times. And i remember reading on twitter about some distros planning to provide the SDL1-to-SDL2 wrapper as an option instead of the real SDL1 because it provides better compatibility with some modern window managers... and Wayland (that SDL1 doesn't support at all but the API doesn't really make a difference and could work perfectly fine with Wayland).
I strongly believe that for old games / software it's better to use a VM / emulator for hardware of that game's era.
> eh, I really really disagree with this. In my experience more often than not this kind of changes breaks the app in various ways.
What did break?
> What if the app was using that shortcut for something else ? Now it's broken and can't be used anymore.
Win+; is very unlikely to be used by anything and it is handled by the window proc of the EDIT window class, meaning that other stuff (e.g. accelerators, which are used to implement shortcuts) get to take first dibs. So if an application was using that shortcut it wouldn't reach the EDIT window proc anyway. It isn't any different than an application replacing the right click menu of a text field - the applications that do not do that (ie. most applications) get the new entries introduced in (IIRC) Vista about Unicode characters, etc and the (few) applications that replace it just do not get these options but their menus keep working.
> Likewise for the hidpi thing that windows does, it's terrible - running the app at original resolution and applying a 2x nearest neighbor filter to the whole window would be better than that mess of "crisp" text with upscaled pixmaps that were never made for this resolution.
Note that this is what Windows does by default, what i describe is something you can do manually.
But personally i disagree, i'd rather have crisp text (which is what the majority of a window contains) and a few upscaled bitmaps than lowres everything.
> I strongly believe that for old games / software it's better to use a VM / emulator for hardware of that game's era.
I play a ton of old games and i completely disagree with this. VMs pretty much never work properly and have all tons of issues. Emulators are very slow. And above all, running games on modern hardware allows for higher resolution and maxing out graphics that was often impossible in original hardware (e.g. forcing 32bit color, antialiasing, anisotropic filtering, etc). Not to mention the potential for mods that improve parts of the game which would be impossible on original hardware.
What you've said is really not correct, at all. For one, Glade is not deprecated in the sense that it doesn't work any more, it still works okay with GTK3, however it has a number of limitations that may make it difficult to use (which it always had, nothing has changed here). Two, a replacement is being worked on, I'm really not sure what your criticism is besides "go faster" which, I'm sure we all wish we could write code faster and have it work perfectly and do everything the first time, but that's not realistic.
Edit: Just to be clear here, in my opinion the new tools will likely end up being a large improvement on Glade. Glade is a pretty old application that by design does a number of weird things that don't match current best practices, you can see some of them if you read the blog post that was posted above.
> The fact that that Glade was deprecated without a replacement being ready means exactly that GNOME does not "value good UI/UX tooling".
That's a false dichotomy. It could be (and I believe is) that things are a tradeoff. They obviously value good tooling (what developer doesn't? and look at the docs), but they value other things too and had to make a decision. With limited resources you can't do it all.
> Nobody is particularly happy about having to edit the XML directly
I wouldn't mind editing a concise XML dialect (XML really doesn't have to be monstrous, a dialect it can be designed with humans in mind). A visual designer producing XML files as its output doesn't actually solve the problem. VisualStudio's developer experience (where you can change everything on the fly, go to the relevant piece of code in a click or two, refactor something and get it also changed in the designer etc) feels really seamless and fluent while PyQt with PyCharm+QtDesigner seems nice but not nearly like that. It seems to me nothing can be considered a serious and worthy improvement until we have an actual integrated visual RAD IDE. I would immediately buy the paid version of PyCharm (I'm using the community edition if they built a good and well-integrated visual designer in it, for whatever a desktop toolkit they prefer).
Thanks for the link, I will watch it when the opportunity comes.
However it is like the sibling comments mention, this hasn't been properly managed as message to the UI/UX community.
So when someone used to Forms, WPF/Blend, Qt Designer, Interface Builder, Delphi, C++ Builder, Swift UI, Flutter, JetPack Composer,... sees blogs and tutorials where .ui files are written by hand and direct use of GtkBuilder is praised, eventually all interest is gone.
That blog is just one developer's opinion, not an official statement. Although I will say I share the opinion, Glade messes up my ui files and I can't recommend using it if you want to use any newer widgets. It has always had those problems, but now with GTK4 it's no longer really worth it to try to work around them.
Also, Glade is not really even used by GNOME designers that much, what they do is make mockups in some other tool (usually Inkscape) and then have the developers implement it. I don't know about other GTK based desktops, though I think some Elementary developers are working on this: https://github.com/akiraux/Akira
Linus recently said something that left me thinking that Linux on the desktop has much deeper problems that need to be addressed before it's worth even thinking about the fine details of GUI toolkits.
Yet Linux worked perfectly for me and many people/offices I migrated to it (they didn't need any Windows-only apps) during the recent decade. Since about half that time Windows and Mac users don't even have to learn nor tolerate anything - everything is familiar (today users of Ubuntu should better learn GNOME3 workspaces though but that's not necessary) and eye-candy.
So I really have zero idea of what problems might he mean. Besides lack of native Photoshop and Visual Studio the only thing which always annoyed me in desktop Linux were NumLock quirks. There was also a problem with games but apparently it's not the case any more.
Then, in just some years, everything changed: Wireless drivers became flawless out of the box (it could take a day to make WiFi work in 2007). Unity emerged, took some years to mature and Linux has became really like Mac but even better in many aspects (and slightly worse in some small details advanced Mac users can miss). Windows 7 came and prepared the Windows population for the Unity panel. Then Unity died making the desktop experience slightly worse again but KDE finally matured enough to achieve even more (except I still miss Unity HUD with menu search). Today I just use XFCE with Chicago95 on Manjaro for my own hot-meets-retro pleasure, give others vanilla Ubuntu (with "restricted extras") and everybody is happy. Also Pop_OS with its user-friendly tiling integration is insanely cool (but it fails to install on some laptops where Ubuntu doesn't).
Nothing really changed. Linux on the desktop is still pretty much relegated to people who develop for Linux. ChromeOS is probably the closest Linux will ever come to desktop success.
When a company rolls out Linux desktops it's a news story because it's unusual. There are killer apps for Windows and Mac. How about Linux? What application is going to have my uncle calling me asking which Linux machine he should buy?
> Nothing really changed. Linux on the desktop is still pretty much relegated to people who develop for Linux.
I can only attribute this to marketing as I can see no single humble thing (except lack of MS Office (which is being phased out by MS favouring Office 365), MS VS, Adobe CS and the NumLock bug) in which Linux actually is worse than Windows. And I can see many in which it is better. Even the very user experience is better - Linux feels faster, is more reliable and can be customized to whatever you want (if you do) with relative ease. Lack of some specific apps is not a flaw of Linux. Whoever doesn't need these specific apps can use Linux comfortably.
> What application is going to have my uncle calling me asking which Linux machine he should buy?
What apps does he need? If he doesn't need the apps I've mentioned I would insist he uses Linux if I were you - so I won't have to fix it next time it breaks, gets slow or infected by something nasty.
> When a company rolls out Linux desktops it's a news story because it's unusual.
I have alone rolled out (and never wanted that to be in any news) Linux in a number of companies (~20 desktops/laptops, Browser+Office+Skype+Samba+RDP+OpenVPN workflow, one also needed a Windows GUI CRM client which I configured to run with Wine flawlessly). This worked fast and reliably forever ever since. I wouldn't, however, agree (unless paid extremely well) to become in charge of a Windows system of the same or bigger size as that would mean much more work regularly.
Flutter desktop works shockingly well on Linux desktop in my experience. It's AOT compiled to native byte code, so it's pretty fast. I think the main weakness would be 3D applications, but I can't say for certain.
Cool. I've been waiting for this since Flutter has been first announced. I will surely give it a try. I just hope you don't need to be fluent in Photoshop, CSS and a pack of libraries to create a basic table-and-buttons desktop app in it like that is with the web stack.
No, it's actually pretty fun writing UI's in Flutter, because it's relatively straight forward.
Edit: Fair warning, desktop development code is _interpreted_ by the VM when doing debug builds, so that you can have hot reloading, which is great. But it may seem like your app is slow until you do a release build. Though it seems obvious in retrospect, it took me by surprise at first.
The developer experience of web technologies is after all this time still far worse than all the desktop libs I've tried. It is even worse than Swing (for those who don't know: That's Javas GUI technology. From the 90s). Add to that the horrible RAM usage, the general jankiness and ... thanks, but no thanks.
> It is even worse than Swing (for those who don't know: That's Javas GUI technology. From the 90s).
As someone who loved Swing and used to hate JavaScript, that's really nonsense if you actually want to be a UI developer (and not just some side afterthought).
State management and the custom capabilities when you need them are amazing. I wasted a lot of my time writing tons of Swing code. Sorry, but the modern front end experience is much more enjoyable and productive. If you want "native widgets" I get the complaint, but most platforms seem to be less interested in consistent experiences these days.
> State management and the custom capabilities when you need them are amazing
JS devs just rediscovered MVC with some added immutability and that’s all. Hardly more productive. Also, I don’t see your point on custom capabilities - please add a slight modification to the date picker widget. Oh, you have to reimplement the whole thing with some insane number of divs, while you can trivially override certain parts of it in most desktop libs.
Dependency management is simple for Swing. In can mostly be assumed that it is available and works. How many dependencies will an Electron /Webstack based app have?
I really like JetBrains IDEs and I think they are based on Swing.
Although I haven't used it for more than a decade, I still have some fondness for Java. I like Workflowy but am not crazy about it being in the browser. I contemplated writing my own outliner and Java + Swing is one combination I'm thinking about.
Compared to WinUI, I wouldn't exactly call web technologies' developer experience pleasant.
This was pre WinUI, but a while back I worked at a shop that simultaneously maintained Web-based and WPF versions of an app. The Web version required 3 dedicated developers to maintain. The WPF version needed about half of one person's time, and had more features.
I would say that the main thing favoring tools like Electron is entry costs. There are lots and lots of people who know who to do front-end Web development, and you can do a good job of supporting all platforms using free tools. Even if you grant me for the sake of argument that native GUIs cost less in the long run, there aren't a whole lot of people who have experience doing them these days, even fewer who have experience on more than one platform. Going that route also requires you to shell out for Macs and probably also Visual Studio.
You wouldn't ask the question if you had developed both GUI apps on MS stack with VS and web apps: the MS dev experience is very good, while the web one is meh at best. C# vs JS, XAML vs HTML+CSS (debatable), desktop application model vs web one, VS vs whatever else, there is a lot of strong arguments in favor of the MS stack in that case.
Microsoft is trying to port some of this magic with Blazor, with is quite liked from what I read here and there.
It is C# vs Typescript. Modern JavaScript is a very good language, and when enhanced with TypeScript's static types, it is every bit as good as C#.
XAML and MVVM is all about two-way data binding. JS frameworks copied it at first. But now it is widely recognized that 2-way data binding is a bad idea.
Targeting 90% of the desktop consumers and non-iPad Tablet owners (Android tablets are being overshadowed by 2-1) seems pretty useful business opportunity to me.
And usually 100% if you're in a big company/typical corporate environment. Not everyone targets the whole market, and lots of companies are windows-only, for better or for worse.
That may be true for the market as a whole, but tech companies tend to be very MacBook-centric. Windows tends to be used by some managers and a handful of graphics/games engineers. Or the cut-rate contractors they won't spend on for MacBooks.
I just opened this today, what a nice coincidence to see it here. I want to create a cross-platform app to show some information on a Git repository. I do not have many UI widgets, it is just a visualization in a way. I also want to continue learning Rust. So I want to create this in Rust, but I am not sure if that means my project will take many many months. I thought of desktop web-app too, using Tauri (1), if this effort is too much.
One I am excited for is Druid. Is is worked on by some of the same people that the xi editor, and they really understand responsive design and good font rendering.
The backend is Piet, which are platform native crates. And then Druid abstracts over those backends. This lets you write GUI code once and then use native API’s and features.
Thanks! To clarify, the platform abstractions are both in piet, which is 2D drawing, and also in druid-shell, which contains a wide range of other things, including menus, copy-paste, and a good start on IME.
I've written lots about Druid. I haven't really chimed in much in this thread, as a lot of the discussion is frankly not that relevant to what we're trying to do. We are currently not focused on making a good out-of-the-box developer experience, which is what most people here seem to be looking for. Rather, we're systematically exploring what it takes to make a good next-generation UI toolkit, and building a knowledge community around that. It turns out there's quite a bit to that, much more than building a toy UI toolkit.
For starters, real text handling. Just doing a full text widget with all the trimmings is quite complex problem. Druid has made good progress on this front but is nowhere near where it should be. I also put IME in this category.
As mentioned elsewhere, accessibility. Aside from web technology, Qt is one of the very few cross-platform toolkits that gets this right. I'm happy to see that some other projects, egui in particular, are starting to pay attention.
One of the things that Druid doesn't do well right now is integration with 3D and video content. That will depend on the application (it's not needed for font editing), but is definitely needed for a toolkit to be considered general purpose. The implications go deep, mostly because you have to hook pretty deep into the system compositor to do this well.
I may do a blog post on these infrastructure topics, depending on interest.
For Rx[0] I built a custom GUI using opengl and Luminance[1]. I'm very happy with the results and would do it again if I had the chance. I'm a Linux user, and there is no acceptable GUI framework to may taste on Linux, so this was the only option that:
My conclusion is basically "there's nothing viable". _If_ you are OK with
basically limiting yourself to Linux/BSD, the GTK bindings are good. However,
for a text editor you'll likely need a custom text widget (the GTK ones aren't
very good), and that's where things (with basically any GUI toolkit) get tricky.
There are a few libraries providing Qt bindings for Rust, but they either focus
on QML, are only infrequently maintained (e.g. Ritual), or seem to focus more on
exposing Rust to C++; not the other way around.
egui looked really interesting, and the immediate mode GUI pattern is really
nice to write. Sadly, it's still in the very early stages, and most notably is
lacking support for displaying text with different colors/styles.
The rest isn't really worth mentioning I think, at least when wanting to write a
text editor. They basically all suffer from the same issues, such as:
- It not being clear if the library will still exist 2 years from now
- Poor support for Unicode (especially Emoji)
- No support for assistive technologies
- Poor support for flexible text rendering (e.g. multiple colors and styles)
- Little to no documentation
For a while I thought about just using Electron, or maybe Sciter (that would at
least need fewer resources). Technology wise I think HTML makes sense, as it's
very flexible (e.g. many GUI toolkits struggle the moment you want to mix text
and e.g. images in the same widget) and quite easy to work with. Sadly, Electron
is a fat pig and the last thing I want to do is write Javascript in my spare
time. Sciter is proprietary, and you can't distribute the binaries yourself
(from what I understand). That basically means your project is dead on arrival,
at least if you intend to open source it.
So for now I shelved my idea. Maybe in a year I'll take another look :)
I don't think it was created for Firefox, as Rust (in various forms) has been around for over 10 years at this point I think.
Setting that aside, Servo and Firefox both implement the UI side of things from scratch I think. I think from a browser perspective that makes sense: you're already writing a rendering engine, so you may as well also use it for your browser UI.
Heh, thanks. It's more of a passion project - I find that dealing with AppKit is sometimes a lost art, and I'd like to see a cross-platform GUI toolkit in Rust, so I figure this is the best way for me to contribute currently.
I maintain that someone (or a team) needs to just take winsafe/cacao/gtk-rs, slap a declarative layer on top, and do the bare minimum set of controls with hooks for users to do custom things.
Probably the best way to go is to write native GUIs for each OS. That means win32 on Windows, Cocoa on MacOS, and X11 on Linux. win32 and X11 are just C APIs, so those are easy. On Linux you'll need a widget toolkit, such as GTK or Qt or WxWidgets (or many, many more!). MacOS is a bit more complex (the native APIs are exposed as Objective-C APIs), so you'll probably want to wrap your app in an XCode project with all of the GUI built in XCode.
There’s other projects that wrap the varying frameworks so I don’t think macOS is as bad as it used to be, but I foresee it still being confusing due to missing docs on Apples side…
The cross platform frameworks are most of the time a disappoint for at least one part of your users as it does a bad job at mimicking typical OS interactions.
Or in some cases, they don’t even try to mimic native widgets. By far the most common example I come across is text fields, which in most cross platform UI toolkits aren’t even half as functional as their Cocoa/AppKit counterparts. It’s incredibly frustrating for things like text navigation key shortcuts to work in the majority of your day to day apps, only to have the habits and muscle memory run into a brick wall when you need to use some cross platform app. Lowest common denominator UI is just… ugh.
I have a large amount of experience in this space and with Rust in general, and my recommendation is simply that like all cross platform non-web GUIs, it's not ready.
* gtk-rs is fairly good, very completely and functional bindings to a functional library. But GTK is also very GNOME/linux centric, is tricky to learn, and not developed as stable or as fast as you might want. Not to knock on the GTK/gtk-rs teams, they're doing amazing work, and imo the best open source GUI library. They've even made great strides in documentation with the new website and API docs recently. Just not quite good enough yet to be recommended for general purpose use. But if you insist on making your GUI in rust, gtk-rs/gtk4-rs optionally with libadwaita-rs is what I'd recommend.
* druid and iced are both promising, but too incomplete.
I've written a few small, personal tools in GTK-rs[0], and it's GUI-enough for me. I love how quick it is to whip up apps, and how well it supports tools like Glade to build more complex apps.
So still not ready yet and is still not mature or production ready either.
Until there is a mature library that is able to compete with Electron or Qt then I'm afraid that Rust is not a sensible choice for serious cross-platform GUI development at this time.
Like I said before [0] With these libraries, All you get is a mixture of unmaintained or unstable bindings that may break when the GUI library that it is using changes its API.
No thanks and no deal.
To Downvoters: So you are telling me that you can confidently recommend to any engineering shop to develop a very complex GUI app with either of these unstable libraries faster in Rust than one who uses JS/TS with Electron?
Even though I hate Electron, I can see why it is always chosen. Rust for GUI development? I don't think so, especially if you have a short time to release something complex and used by thousands into production.
It's unfortunate, but I agree with you regarding native Rust libraries.
There is a reason why we don't have options in this domain, apart from Qt, Gtk (with lot's of caveats) and more recently flutter.
Building a cross platform native UI toolkit is an immense amount of work.
It took Google a long time to turn Flutter into a decent option just for Android and iOS, and the newer desktop integrations are still very rough after years of work.
All for Rust implementations are not at all viable for professional usage, and won't get there without major corporate backing.
That said, the gtk bindings are in a good shape and very usable.
Are there startups that still write desktop GUI applications? Maybe I'm just not informed, but most just seem to be an instance of chrome (aka electron) written to directly call a website or reuse the web application locally.
If I'm not wrong and something doesn't change, we'll find ourselves surrounded by electron apps on our desktops.
The GTK bindings are being used pretty heavily by a few GNOME projects now, so I would expect them to continue to get the maintenance effort.
It's a heck of a lot easier to bind to an existing GUI library than writing the equivalent of GTK from scratch. But all languages have this problem, and most of them don't have Microsoft's ability to generate multiple different and incompatible GUI toolkits to suit the fashion of them time.
As others have already mentioned in the thread, they didn’t kill it, it is just not compatible with GTK4 out of the window. But a similar program for that is being done.
I didn't downvote you but I can see why some may downvote you and it would just come down to "how" you said it, not necessarily the substance. It is all about delivery and that can be improved to be a bit more friendly. There are a lot of people working on this, it seems, and the tone that I felt from your comment was "pfttt, still not good enough". So that is why I _think_ you got down voted, but I don't know for sure.
Tauri competes with Electron, and is a viable alternative. There are milestones they haven't hit yet ( https://tauri.studio/en/?hn ), but many of the features needed are there already.
Even for unsafe code Rust was designed to be more ergonomic than C (like pointer arithmetic operations). That said a safe wrapper would be preferred to unsafe everywhere.
There are a lot more options but nothing that's clearly winning. The first projects I'd check for building a GUI today are Microsoft exposing the Windows UI toolkit and the Rust+Flutter integration. I know that the GTK crowd were engaged with the Rust core team years ago but I don't know if anything came from that.
I'm still on the DOM-as-the-main-platform train (since 2001, I believe in the Mozilla vision) so I haven't been tracking the details that carefully.
It really isn't, at least if you want to meet the expectations of the users of each platform you're targeting.
It's easy to say "I want a button that says '[Click Me]'." It's less easy to say what the pixels representing that button look like in a platform-agnostic way. Are the corners rounded? What kind of bevel does it have? What sort of visual indication is there when you mouse over?
And then there's stuff like layout. Does your form have the buttons ordered `[OK] [Cancel]` or `[Cancel] [OK]`? Because there are platforms that do both, and if you get it wrong, your user will mis-click because of muscle memory.
And what do you do when one platform supports a widget natively that you don't? Or when the APIs for a "common" widget diverge wildly? Windows Explorer and MacOS Finder serve the same general purpose, but they aren't identical, either from the user's perspective, or from the API perspective.
Java's Swing probably comes closer to "cross platform GUI" than any other package, but it's far, far from perfect, and it solves a lot of these problems by not trying to mimic the underlying OS. Yes, there are themes that get close, but generally, when you're using a Java desktop program, you know you're using a Java desktop program.
A lot of very smart people have tried to create "a single language to build UIs," and "target it to multi platform." It isn't as trivial as you make it seem.
Edit: Ok, I was wrong. I thought Tauri was also being used as a platform for Rust development, not just Javascipt. Also, it's not buried..just not highlighted. First comment of the day did not get off to a good start.
What surprised me was that Tauri was buried and not mentioned as a viable Electron replacement. I think we will eventually get to the point where native OS UI is a Web UI, with the OS UI running on a special virtual interface for security. I have seen Web-based UIs that are every bit as nuanced, complex, and well-designed as native UIs. Two bits are not quite there yet though. First, performance of Web UI has improved amazingly, but until we do have native support integrated into the OS it's going to be a step behind. Second, as already mentioned, accessibility must be accounted for.
Tauri is written in Rust, but it's a Electron alternative, with user code written in Javascript. It deserves a curtious mention, but it's not really relevant to a Rust UI development.
(Sure, you can write UIs via WASM now, but that's equally true for Electron)
It is ridiculously fast for what it does. There’s another question that it does plenty of unnecessary computations for the end-goal and is probably not a good basis for.. well anything to be honest. It is not good at layouting, nor interactions.
1. Write the GUI natively per platform. This is best from a UX perspective but is expensive and you probably need different developers working on different platforms. Other downside is that really advanced functionality is harder to implement and sometimes the performance of native APIs is poor and hard to improve (Apple has this problem frequently).
2. Use a cross-platform framework like Qt (Electron would also go here). This is the most cost-effective solution, but generally does not feel like a native app, which may or may not be a problem.
3. Use a custom GUI framework.[0] Probably the most expensive option and hard to hire developers for, but can be warranted for complex applications like CAD tools, games, etc.
The problem with Rust GUI libraries is that they can't really target 1 or 3 so they need to target option 2. But the big players there are Qt and Electron. Qt is popular because it works well, is proven, and has a lot of financial backing. If you don't need something super complicated a decent Qt developer can get it working quickly. Electron is popular because there are tons of web developers and they can be productive quickly.
Rust attracts a lot of hobbyists who are talented and have good ideas, but I don't think they have the staying power (or financial ability) to provide something that competes with Qt and Electron. I'm sure it can be done in theory but I don't see it happening in practice anytime soon.
[0]: By custom I mean tailored for the type of application you are making, e.g. what a lot of game devs do for their internal tools.