Thoughts on Rust GUIs

[H2CO3]

@Gee5ive

he greatest degree of flexibility without sacrificing to much in terms of performance at the same time. Personally, I wouldn’t mind things not being platform native, that’s what theming is for

As I mentioned earlier in this thread, the problem with a browser-based GUI is not primarily performance, but security.

[DrizztVD]

@H2CO3

Furthermore, having to compile half of a browser engine into my app just in order to display a button and an image doesn’t sound terribly attractive from a developer’s point of view. Not to mention the infinitude of security holes that operating a browser engine opens up

A browser engine written entirely within Rust should do 10x better on the security front, conservatively speaking. I have no idea how/when that would happen, but it could?

@Gee5ive

I would expect usability applicability to take precedence over performance alone. That’s not to say that performance shouldn’t matter, but sometimes (most of the time ) good enough is all that’s needed.

Android JVM as an example.

[sunjay]

A browser engine written entirely within Rust should do 10x better on the security front, conservatively speaking. I have no idea how/when that would happen, but it could?

This exists:

GitHub - servo/servo: The Servo Browser Engine

And there's a Rust GUI framework based off of its rendering engine (early stages of development):

Azul GUI Framework

[Gee5ive]

I’m actually about to build a simple desktop app using this crate. I love the ideas behind it. In a perfect world you’d be able to use something like this to write an app for web, mobile, and desktop all at once with a crate like this in rust, but it’s still early, so you never know!

[H2CO3]

@DrizztVD

A browser engine written entirely within Rust should do 10x better on the security fron

You seem to assume that all browser security problems are memory safety issues. They aren't. Many of them are inherent in running basically arbitrary e.g. JavaScript from various sources, while others are an unhealthy combination of bad habits of web developers and obscurities in web-related technologies stemming from backward compatibility or misdirected standards. Neither of these are easily mitigated using a memory-safe language.

[DrizztVD]

@H2CO3

You seem to assume that all browser security problems are memory safety issues.

You seem to assume that I assume that all browser security problems are memory safety issues. I don't. Having said that, about half of them are memory related, and most of the more serious issues are memory related. The whole gamut of browser related problems given here PentesterLab: Learn Web App Pentesting! should be of little concern for a GUI implementation. Unless you're suggesting a GUI implementation should somehow be able to solve those problems as well? It should be obvious that the GUI library and webpage building is not the same thing.

[DrizztVD]

The security issues of GUIs would perhaps be something like this https://security.stackexchange.com/questions/97856/can-simply-decompressing-a-jpeg-image-trigger-an-exploit

I’m unaware what other security issues such a library would need to fend off.

[Gee5ive]

After digging around a bit yesterday trying to assess the current state of affairs in rust gui development, I found this. So now I’m wondering if there is any reason not to just invest in making integration between rust and qt as seamless as possible? I mean, qt is already well established, qml is really nice, it works pretty much everywhere , theyre even working on wasm support.

Is there some sort of technical merit that I am unaware of or simply too ignorant to understand in creating a new ui framework for rust from scratch as opposed to just making rust <–> qt interop as idiomatic as possible from the rust developers’ perspective?

For instance, after watching this video, It’s clear that while this approach to using qt with rust can work, there are still holes that need to be filled to make typical development easier, things like making the lib macro based, better integration with cargo, etc.

As I said before, I’m definitely not a gui programmer, so I’d love to be better informed on the pros and cons of this approach so I can understand why or why not it may be suitable. At this point, it seems like the easiest approach though, I’m just wondering why it doesn’t seem to be being taken into consideration? I mean, it worked for python.

[pythoneer]

It’s not that it is not taken to consideration. The Rust-Qt-Binding-Generator is really great and just to throw in another approach qmetaobject also is. The main problem i see with Qt is deployment/dependencies and it feels alien programming it with Rust. I am used to Qt & C++ for work and i really like Qt/QML even though i have to use C++ – a language i never really warmed up to – but the combination is quite useful and both complement each other. We use Qt specifically to create cross platform application and building versions for macOS / Windows / Linux can get tricky (unfortunately quite tricky on Linux, the system i primarily use at work and private). And the same applies when you try to make the same with Qt & Rust. It just feels weird if you are used to the simple build system cargo provides. The first time i tried Azul or OrbTk it just felt right to me to just call cargo run and it does exactly this: run. I really don’t want to fiddle with the hole Qt libraries if i can avoid it. So the more “pure” Rust the GUI lib gets, the more happy i get because cargo can do its magic.

Also Qt is closely intermeshed with C++ and to OOP to some extend and i just don’t feel like that’s the way i want to program applications with Rust. Qt has the big advantage to be very mature but that does not mean its still the way “we” want to program. I think with Rust we have the great opportunity to bring fresh air in this field, especially if you bring things like Flutter into the game which i really like atm. It just feels like a “better” way to achieve my goals, i’ve never felt so productive. And i want something like this feeling with Rust. Yes there are mature Frameworks out there that you can use today but why not try to do it better? I was used to write mobile application with their respective “native” sdk’s and i was – for a long time – against things like react native, ionic, xamarin, titanium … etc. because they felt suboptimal. With flutter things dramatically changed for me. We shipped our first mobile app this week with flutter and we’re all quite happy with the result. We don’t know if we change our hole mobile story in our company to flutter any time soon, but it made a good impression. I don’t think i will ever write “native” mobile applications again for private projects – the same “shift” that happens with C++ -> Rust. I think i havn’t touched C++ for almost two years now in private projects since Rust fully took over the game (same happened to Python, Java, C#, D … Rust replaced them all)

If things are dramatically better in some departments/tooling it can really drive people away from things that are “just” mature but lack the “joy of programming” part. Flutter is really a joy opposed to activities, intents, xml … navigation controller, segue, storyboard shenanigans. And i hope Rust can do the same thing with Qt, its mature but what if we can do better?

[Gee5ive]

@pythoneer

OrbTk

Thanks a lot for your response, as someone not versed in gui development in general, what you say makes a lot of sense, especially after checking out orbtk. I really hope this project stabilizes in the near future and becomes a way to create mobile apps completely in rust. I've had an idea for a little app I want to make for quite a while now, but mobile dev just isn't my thing,

[FloVanGH]

You could check the current progress of OrbTk on our Issue Board and on the Examples. You could use the README as start guide.

There is still a lot to do but we’re making good progress.

And the documentation is growing day by day .

[FloVanGH]

Check out the roadmap for OrbTk 0.3.

[pythoneer]

For those still interested in this topic, please take a look at areweguiyet

[FloVanGH]

OrbTk has now an improved widget API and contains new layout widgets like Grid.

Check out the examples:

• https://gitlab.redox-os.org/redox-os/orbtk/tree/master/examples
• https://gitlab.redox-os.org/redox-os/orbgame/blob/master/examples/dungeon.rs
• https://gitlab.redox-os.org/redox-os/orbutils/blob/orbtk-next/src/calculator/main.rs

Next step is the integration of OrbGL as OrbTks new renderer.

Your feedback is welcome.

[thoroughburro]

Thanks for updating the thread. I’ve been waiting for the OrbTk work to land!

[susurrus]

For those of us just following along but not really wanting to deal with code yet, it’d be really helpful if there were screenshots of the examples. I know that’s asking a lot, as you already have a screenshot on the front page. But I think it’d help sell your toolkit if it was clear what widgets were supported and what they looked like.

[FloVanGH]

Thank you for your interest.

The visual design of the widgets in the example are not finished now. But our design team will continue their work tomorrow. I will upload more screenshots after it is finished and implemented. I hope next week.

I will also write some lines about OrbTk on reddit in the next days.