Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust cross-platform GPUI components

github.com

Post reply on HN
Print view View original

101–110 of 225 posts

Re: Rust cross-platform GPUI components

#101

Post by adastra22 »

nu11ptr wrote: post #34
nicce wrote: post #29

Earlier quoted context omitted.

> UPDATE: This honestly looks incredible and makes huge strides in the Rust UI landscape. You can run an impressive widget gallery app here showing all their components: > https://github.com/longbridge/gpui-component/tree/main/crate ... > Just "cargo run --release" Very impressive! Only thing I am concerned over is that it uses around 900 dependencies. But I don't know whether it much for GUI applications.

That did seem excessive to me as well. I do worry about the DX of trying to work on an app with this. After each edit, I would expect a solid compile time to simply try your work.

Incremental compiles should be fast.

Re: Rust cross-platform GPUI components

#102

Post by samiv »

WD-42 wrote: post #97
samiv wrote: post #82

Do these "modern" UI toolkits not have visual editors for knocking up the UI anymore? One of the strengths of Qt based UIs is that the framework has IDE like tools where creating UIs is just a matter of drag and dropping the UI widgets into a layout. No need to write code by hand. Both QtCreator and QtDesigner can support this workflow. Secondarily this comparison table has several problems when it comes to Qt. * The…

In my experience QT designer was awful to use. It’s probably fine if you are doing super vanilla layouts and widgets but as soon as my team started implementing custom css (or whatever the qt equivalent is called) things went off the rails. We pretty quickly abandoned to the tool completely to write the ui files by hand. They ended up much smaller and cleaner as a result. For some reason the designer seemed to add lo…

That would seem odd.. the QSS is completely orthogonal to the code generated by the UI tool.

I accept that sometimes you need to some tricks with it and sometimes the layout in the preview is not the same you get at runtime which is annoying.

But in my UIs I use hundreds of widgets and I can't even begin to think about the useless effort required to write all the code by hand vs. spending seconds to drag and drop widgets into their place visually in the GUI editor...

Re: Rust cross-platform GPUI components

#103

Post by daakus »

Keyframe wrote: post #62

I'm interested in how's the battery life while running a thing ilke this. Another thing I'm interested in does it support rendering to texture.. usage being used as a texture on an object (monitor let's say) in a game or rendered as a texture with opacity on a quad/triangle over a screen as a UI layer or a HUD

A quick check with release build on macOS shows the component demo has a non-zero energy impact in the background (per activity monitor), but the input example has zero energy impact while in the background. This is already better than many new from-scratch UI libraries. The foreground impact is harder to measure.

Re: Rust cross-platform GPUI components

#104

Post by tredre3 »

nu11ptr wrote: post #61
WhyNotHugo wrote: post #59

The simplest examples have over a thousand (literally) dependencies. Amongst them, are GTK, GDK, pango, etc. It literally depends on another toolkit, which is the weirdest thing IMHO.

I think this is pretty common on Linux. You would want to GTK (or Qt) I would think to draw the top level window and perhaps system menus, etc. even though the UI itself is drawn using a GPU canvas.

> You would want to GTK (or Qt) I would think to draw the top level window and perhaps system menus, etc. even though the UI itself is drawn using a GPU canvas.

No, you would want to draw for Wayland or X. GTK and Qt themselves don't burden with importing each-other to work, for example.

My guess is that they import GTK only to get a title bar on GNOME, as GNOME forces applications to render their own. They could go custom and cut the dependency but it never looks quite right when apps do that.

Re: Rust cross-platform GPUI components

#105

Post by swiftcoder »

nu11ptr wrote: post #2

This looks to be one of the most complete Rust UI creates (in terms of available widgets/components), but unfortunately has almost no usage (yet). I do see their docs are coming along now. Another very complete one is fyrox-ui used by the fyrox game engine: https://crates.io/crates/fyrox-ui . Again, not really used/known outside of fyrox. The Rust UI scene is maturing, but the most popular options (iced, egui, dioxus…

> but unfortunately has almost no usage

gpui itself is spun out of the zed editor, so I'd say it probably has more real-world usage than the majority of rust UI crates

Re: Rust cross-platform GPUI components

#106

Post by discreteevent »

moralestapia wrote: post #89
discreteevent wrote: post #70

Earlier quoted context omitted.

No. What is the likelihood of an attack on a desktop program via memory unsafety?

>What is the likelihood of an attack on a desktop program via memory unsafety? Low. What's the likelihood of someone entering your house if it's unlocked? Also low, and yet you lock it.

A desktop program is already in a locked house - your desktop - which I can't login to.

Re: Rust cross-platform GPUI components

#107

Post by Buttons840 »

nu11ptr wrote: post #2

This looks to be one of the most complete Rust UI creates (in terms of available widgets/components), but unfortunately has almost no usage (yet). I do see their docs are coming along now. Another very complete one is fyrox-ui used by the fyrox game engine: https://crates.io/crates/fyrox-ui . Again, not really used/known outside of fyrox. The Rust UI scene is maturing, but the most popular options (iced, egui, dioxus…

Fyrox is such a blackpill for me (makes me doubt the Rust gamedev scene), because Fyrox appears to be the most mature Rust game engine, but nobody uses it or cares about it. Instead everyone is excited about the Entity-Component-System in Bevy, but once all the rough edges of Bevy are smoothed out, people excited about the ECS are going to realize they don't actually want to make art, or create game mechanics, they were just excited about a neat system (and in fairness, ECS is neat), but they never really wanted to do the things required for a game.

Re: Rust cross-platform GPUI components

#109

Post by tredre3 »

filleduchaos wrote: post #39
nu11ptr wrote: post #22

Earlier quoted context omitted.

Even though most UI libraries now draw their own widgets some native integration is almost always used/desired. Those integrations are typically: keyboard short cuts, native system menu (macOS), native file dialogs, and (sometimes) native context menus. I'm sure there are others I'm forgetting, but these minimal integrations are a good thing as they give the user some sense of familiarity.

Not just a sense of familiarity; you will simply never build the full spectrum of a file explorer's functionality in a custom file dialog, that would be a complete waste of engineering time. And many more users than you'd expect benefit from the fact that native file dialogs are actually full-fledged explorers. For example, I fairly often find myself quick-previewing a file to be sure it's the correct one when I sele…

Thankfully on Macos x and Windows, the file picker isn't provided by the UI toolkit (though they usually provide abstract methods of calling it, for convenience).

Linux is now working towards that goal as well, in the form of XDG Desktop Portal. It puts the Desktop Environment (or third party provider) in charge of providing services like the file dialog/picker/chooser for better integration/coherence. It's not been fully adopted yet, but I'm very excited about it because GTK's file chooser is just awful and I want to provide my own to those apps!

Re: Rust cross-platform GPUI components

#110

Post by pjmlp »

Arch-TK wrote: post #99
pjmlp wrote: post #87

Earlier quoted context omitted.

They do, but you have to look into the right ones, from ex-Qt employees, https://slint.dev/ You can make use of Figma integration for something similar to Qt Design Studio. Too many folks nowadays don't seem to fully understand how powerful GUI designers for native code used to be. You always get some arguments about pixel perfect positioning, completly ignoring the fact most of them had layout managers available, ev…

The thing that irks me about slint is the use of the more restrictive GPLv3-only which prevents it from being incorporated into a project which is licensed GPLv3-or-later. I don't get why it is done like that.

Easy, similar to Qt.

Don't want to pay upstream? Also don't get to charge money.

Want to pay up stream? Another license can be arranged where both parties get to earn money.

Post reply on HN