Thoughts on Rust GUIs


#83

I do agree. There is, however, the problem of fragmentation that is a result of legacy code and the insistence of large corporations to be protective over their IP. As such, fragmentation is as much a consequence of protectionist behaviour as it is of technological challenges.

RISC-V is a large step in the right direction for this run-anywhere aspiration. A large part of the fragmentation is due to hardware incompatibilities. x86-64, and ARM. Based on what I can see, there’s a large drive from future-thinkers on RISC-V to overthrow the problem of vendor lock-in and the resultant fragmentation it causes. As such, a project like Libre GPU http://libre-riscv.org/3d_gpu/roadmap/ could be very successful.

Stated otherwise, there could be ‘one ISA to rule them all’, and its large-scale success could solve a lot of the fragmentation problem. Based on what I can see from the RISC-V ecosystem. This is exactly what a whole bunch of vendors are planning on doing.


#84

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


#85

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?

Android JVM as an example.


#86

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:

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

https://azul.rs/


#87

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!


#88

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.


#89

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 https://pentesterlab.com/exercises/web_for_pentester/course 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.


#90

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.


#91

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.


#92

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?


#93

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,


#94

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 :wink:.


#95

Check out the roadmap for OrbTk 0.3.