Hacker News new | ask | show | jobs
by brainless 77 days ago
I keep trying Xilem and then egui or Iced. Xilem needs more widgets out of the box to be easy to build with. Slint is another option. I wonder what cross platform GUI framework (from any language) will finally become as common as Electron based apps or the vast number of native OS apps in Windows or macOS or Linux.

I keep going back to Tauri, which is practical to build desktop apps quickly but still uses HTML, CSS, JS to build the UI. You can use Rust web UI tools but then it is still (system) browser based.

4 comments

QT does it well but the license is a maze
Qt is LGPL. Anything that's complicated about that is Qt Company sales tactics. It's really just LGPL.

Unless you were talking about commercial licenses - in that it's not that complicated neither; it's expensive.

I wish it's that simple. Not all components are LGPL, so when you're doing LGPL and you suddenly need some must-have-but-not-LGPL component,you're in trouble.
Cross platform GUI is extremely hard. Qt is the only good choice, even though it's still far from mature after 30 years of development.
FWIW Slint was founded by a group of long time Qt alumni, so brings a lot of that know-how into the space.
I gave it a decent shot, and I wanted to like slint, but I don’t.

It’s not a rust ui system; it’s a declarative ui language that happens to have a rust binding via macros so you can write the custom DSL.

It also has bindings for other languages.

It feels like a bunch of qtquick people got together and implemented a new runtime for qtquick. That might be the direction qt has gone, at the expense of their c++ qtwigets system, but it just feels… “electron app” to me.

If I wanted an electron app, I would just use electron.

If I wanted a non-native ui look and feel, I would use flutter.

Slint has nothing to do with elecron. There is no browser under the hood so it is much more lightweight. Slint has native looking widgets. Slint DSL gets compiled to native code: no need for a runtime interpreter like in QtQuick
Something like GPUI probably, I would be quite happy with it if it wasn't so tied and restricted by the Zed's team (they reject PRs because they're not strictly related to Zed), there's even mobile fork. Dioxus native would be second, but it's far far far away from being ready.
> they reject PRs because they're not strictly related to Zed

What kind of PRs? Like new widget components or what?

Maybe https://github.com/longbridge/gpui-component would be more keen on accepting PRs like that?

For example https://github.com/zed-industries/zed/pull/42905#issuecommen...

So there is now a fork: https://github.com/gpui-ce/gpui-ce/ But I don't know if that's sustainable.

That's disheartening, though also understandable from Zeds point of view.

I hope the community fork could gain traction. I believe there's a lot of potential in GPUI.

Yeah, it really sucks as I really like it, but I've been hitting edge cases which would be solved by some of the PRs mentioned.
Not possible to do it via component. I've seen various, like custom user shaders or some silly basics like text justify (which is implemented in cosmic-text crate used by gpui). That's why it was forked.
IMO this is the best Rust GUI option at the moment:

https://github.com/longbridge/gpui-component

The only things I don't like about this is a) your binaries will become huge and very slow to compile with optimizations enabled and b) it's dependence on GPUI and its unsure future direction (I'd like to see GPUI thrive outside of Zed but the maintainers have clarified that that's not the goal for now).
hum, well, not that convincing :

Failed to open window: WebGPU context not initialized. Was Platform::run() called?

Not being able to load the component gallery does not inspire great confidence.

Yeah it just doesn't have a good error message if your browser doesn't support WebGPU.

It's not really designed for the web though so I wouldn't hold that against it.

Fair enough. A little warning would go a long way though.