[zorr]

I think, now in 2022 it is time to let go of this idea (for cross-platform applications). What you propose means that any app that wants to be available on "all" desktop platforms has to be written at least 4 times (macOS, Windows, GTK, Qt) and few developers or organizations have the resources for that.

> Recreating widgets from scratch with GPU rendering is doomed to feel wrong to users.

Yes, and no. When these widgets try to mimic platform-native widgets we have the uncanny valley problem which makes everything feel out of place like you describe. But if we drop this constraint and design widgets with their own consistent style within the same app, we don't have this problem. Apps like the JetBrains IDE's and Todoist show that this can be done.

To me the middle-ground solution is a UI toolkit with its own widget style, that has some tie-in with platform-native things and conventions like windows, menus, notification trays and keyboard shortcuts. Essentially GTK or Qt without the focus on pixel-perfect matching of platform-widgets. I think this is what Druid is doing. Rust is in a good place for this as it is a modern language that works well on all of these platforms, with no native UI toolkit yet and a package-manager/build-system that supports multi-platform library configuration.

There will always be a place for platform-native apps but cross-platform apps have different requirements. I don't care that my todo list application or IDE does not look exactly "native" on my Macbook. However I do care that these applications look and feel similar when I use them on my Macbook vs on my Linux machines or Windows laptop. Preferably without dragging in a full web-based rendering engine a la Electron.

[dmitriid]

> But if we drop this constraint and design widgets with their own consistent style within the same app

Style is just one of many things. And it's extremely hard to properly code your own consistent UI toolkit.

On top of that every platform has a myriad of platform-specific behaviors that people expect and that you will get wrong in yours. Accessibility is the big elephant in the room. But even things like secondary focus in prompts/dialogs on MacOS (that Apple's own Catalyst and Swift forget about) is a bitch and a half to get right.

[zorr]

I agree, which is why I'm not advocating writing or designing your own toolkit. Instead we as a developer community should focus on the "next generation" of toolkits for the modern cross-platform world. Take all that we have learned from GTK, Qt, Flutter and all the web stuff and incorporate it into something new for the next 10-20 years.

Rust is a nice language for that since it is already a "next-generation" language in terms of memory safety and its momentum is still building. Projects like Druid, while far from ready, are a good starting point.

[cmrdporcupine]

The problem with this is unless you drag in something like Electron, you're inevitably going to end up using (or writing) something that just doesn't have the number of maintainers and quality development as either the native UI or an embedded webview. There's nothing with the level of development of e.g. Qt for Rust.

Which means "unsexy" things like accessibility get left by the wayside. And your users suffer.

Writing a UI kit is a huge task. It's one of those things (like so much else in our industry) where you can fairly quickly climb "stupid mountain" by getting a pile of shiny widgets on the screen; but then you look out over the valley below and realize that, holy, crap there's a whole other mountain range of things that a UI kit has to do.

It's also a tough story for Rust, in particular, because copying what other people have done with other toolkits won't really cut it. Rust's ownership semantics and general opinions don't necessarily accord well with the highly object oriented and event-loop / object-tree structure of most existing GUI toolkits.

Aside: I still don't understand why things like Electron based apps are so bloated. They seem to static link whole chunks of their own (forked) Chromium. But both Windows and Mac OS ship native webview components as part of their system which can be used instead. I've done this myself (used Edge's Chromium webview component in a VST synthesizer, and equiv webkit stuff on Mac) and binary sizes were entirely reasonable. Linux was a slightly more complicated story.

[zorr]

It's a tough story indeed, but every existing toolkit had to start from scratch at some point. If I'm not mistaken Druid had its start in 2017 (I personally contributed some stuff on the GTK bits around 2019) and it is far from ready but I see it progressing in the right direction. Accessibility is on its roadmap as well I believe.

This is why Rusts' "Are we GUI yet?" and posts like this are a good thing. Eventually some new toolkit will arise that ticks all the boxes. We are not there yet and it will require a huge amount of work.