Hacker News Reader

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

> I develop a media software and my users are adamant that they want the exact same look&feel across the three main desktop platforms

Are these end-users, or just the person in charge? I find it hard to believe that the actual users of the software would care about this.

> media software

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.

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.

The mantra that end users want native app is tired and was always pulled out of one's backside.

Productivity applications like 3Dmax, Photophop, Eagle, Blender and others can take years to master. Even Excell and Word fall into this category.

The last thing a professional needs is to learn the same software 3 times and keep up to date with 3 diverging implementations

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.

It's funny you mention media software. GTK was originally written as a toolkit for GIMP (It stood for GIMP Tool Kit).

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.

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?

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

Good post.

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.

The third option is basically Flutter. Maybe Rust guys would like to do some Flutter bridge?

A pretty amazing interop library at https://thlorenz.com/rid-site/

Tauri seems like the only viable Electron alternative right now, and it's written in Rust.

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 same can be said of Electron.

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.

Just like building for the web then? In that scenario you also do not know what version the browser is (or even what kind of browser).

An advantage would be that the browser gets security patches by the OS.

Is this really a problem now that IE11 is finally being deprecated? You basically have Blink/Gecko/Webkit which is no different from regular web dev

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.

That's a stretch.

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.

IntelliJ is great example of Swing, which also extends into its plugin ecosystem.

If you are looking to use Java. This is very good

https://github.com/JFormDesigner/FlatLaf

There’s also Kotlin multi platform

Conrod is targeting 3 and it does a decent job at that

https://www.youtube.com/watch?v=_ZXLCVibI8c

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.

I've never used them, but they seem similar to Qt. For whatever reason Qt seems to be the most popular in commercial products.

wxwidgets is unique in that it translates to native gui widgets (when available)

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.

Have you looked at stuff like TextKit 2 etc.?

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.