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

191–200 of 225 posts

Re: Rust cross-platform GPUI components

#191

Post by written-beyond »

mdhb wrote: post #28
nu11ptr wrote: post #16

Earlier quoted context omitted.

Pretty sure native as in "not web". AFAIK, everything is drawn using the various GPU APIs (GPUI started with Metal on macOS, for example).

Same model as Flutter which is a million times more pleasant to write and mature at this particular use case which I don’t actually think Rust is well suited to generally speaking.

Yeah but sometimes you don't want to write connectors between high performance code and convenient to use UI code.

I welcome this, I want to write cross platform lightweight UI applications without going to C or C++.

Re: Rust cross-platform GPUI components

#192

Post by aryonoco »

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

Earlier quoted context omitted.

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.

Qt is LGPL 3. Slint is GPL 3. There is a massive difference there for a “library “

But to be fair to Slint, they do have a free proprietary license which can be used for developing proprietary applications as long as it’s not considers in the “embedded” space.

Re: Rust cross-platform GPUI components

#193

Post by aryonoco »

pjmlp wrote: post #164
_bent wrote: post #158

Earlier quoted context omitted.

According to Microsoft WinUi3 and WinUi2 are also native https://learn.microsoft.com/en-us/windows/apps/winui/

Naturally, they build on top of UWP. There are some details on what that exactly means, but I am on the go for lengthy comments.

None of which is used by for example the Office team, which maintains their own UI Framework just for Office.

Which itself is not used by Teams, which uses electron/WebView2, even though Teams is part of Office.

And let’s not forget about MAUI, which has its own components and UI library, which as far as I know is not used by anyone at Microsoft.

And I’ve heard from people at Microsoft that the future story of .NET UI framework is “Blazor WASM”. Is that considered native? Probably not. But I’d argue it should be considered “first party”.

Let’s be honest, Microsoft’s UI framework landscape is a mess.

Re: Rust cross-platform GPUI components

#194

Post by Animats »

Unfortunately, it's a framework. That is, it demands to own the event loop. It has a type "Application" (This is Rust, don't get to say "it has a class Application, which you subclass", but that's how it works.) That's fine for a cold start where you do everything their way, but tough if there's already an event loop. egui, in contrast, is just a library crate which needs to be called on each frame.

Re: Rust cross-platform GPUI components

#195

Post by Arch-TK »

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

Earlier quoted context omitted.

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.

You can freely charge money with either GPLv3-only or GPLv3-or-later.

I am not asking them to remove GPLv3-only and replace it with MIT, I am asking them to use GPLv3-or-later.

Re: Rust cross-platform GPUI components

#196

Post by filleduchaos »

the__alchemist wrote: post #185
filleduchaos wrote: post #183

Earlier quoted context omitted.

I fail to see how that's particularly relevant, considering that this discussion started with the implication that ECS specifically is a neat fad that Bevy users will eventually get bored of. And again, I am not sure what exactly people are expecting of a game engine that started development in 2019. Development of Tiny Glade itself started less than three years after Bevy's first commit, which was an obvious factor…

It's relevant because the post I replied to is misleading on its own.

How is it misleading? Even Unity and Unreal games often have parts of the engine modified or replaced, e.g. swapping built-in audio for fmod/wwise or built-in physics for something in-house. Pounce Light has discussed the fact that it's primarily the renderer that they replaced[0], and they are not the first, nor will they be the last studio to use a custom renderer.

If your criteria for "made with Bevy" is "every single system in the game must be from Bevy", then sure, you won't find a single Bevy game in existence. But you will also find a lot fewer Unity and Unreal games than you think.

0. https://80.lv/articles/exclusive-tiny-glade-developers-discu...

Re: Rust cross-platform GPUI components

#197

Post by Arch-TK »

pie_flavor wrote: post #127
Arch-TK wrote: post #99

Earlier quoted context omitted.

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.

GPLv4 could be the MIT license. GPLv3-or-later is a statement of arbitrary trust towards the FSF. Corporations serious about licensure, like SixtyFPS, aren't fans of that. (I don't think I've ever seen GPLv3-or-later in the wild from non-GNU/FSF software.)

GPLv3-or-later is pretty commonplace in the world of free software even outside of GNU stuff.

Re: Rust cross-platform GPUI components

#198

Post by rayiner »

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…

I downloaded the Longbride app they made with it. It looks like a real application! Fits in pretty well on Mac. Runs much more smoothly than Electron!

Re: Rust cross-platform GPUI components

#199

Post by tracker1 »

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…

I would think you could absolutely create something like that with a few steps on top of a relatively complete component library like linked.

You would probably want an xml/markup representation of component hierarchies, similar to other efforts, this can work with Rust with a macro interface that replaces the render hierarchy with the component structure format of this library. From there, you would need an application to hot-mount the same markup "live" as part of an interactive design tool.

In the end it wouldn't be much different than Glade, XAML or QT Designer. That said, you have to build a foundation before you can put solar panels on the roof.

Re: Rust cross-platform GPUI components

#200

Post by tracker1 »

miki123211 wrote: post #53

Does this implement accessibility at all? This is often a problem with Rust UI frameworks, they may look beautiful, but the moment accesibility becomes a requirement, the whole app needs to be scrapped and rewritten in something more mature.

You might want to consider Dioxus if you want better accessibility in a Rust app... though afaik, there's no component library as complete as this one available.
Post reply on HN