Porting a cross-platform GUI application to Rust - Mozilla Hacks - the Web developer blog (hacks.mozilla.org)

submitted 7 months ago by snaggen@programming.dev to c/rust@programming.dev

12 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[-] BB_C@programming.dev -4 points 7 months ago

The crash reporter has a very unique requirement: it must use as little as possible of the Firefox code base, ideally none!

we already ship GTK with Firefox on Linux to make a modern-feeling GUI, so we can use it for the crash reporter, too.

I'm almost hoping for some GTK-caused crashes. They can enjoy the native look and feel while debugging that!

Maybe then they will learn how to stick fully to logical requirements instead of going for "meh big dependency" and "meh look and feel".

[-] FizzyOrange@programming.dev 7 points 7 months ago

What would you use instead?

[-] BB_C@programming.dev 2 points 7 months ago

iced or slint

[-] notriddle@programming.dev 2 points 7 months ago* (last edited 7 months ago)

iced doesn't support accessibility at all https://github.com/iced-rs/iced/issues/552

slint has some support, but it's a lot weaker than gtk https://github.com/slint-ui/slint/issues?q=is%3Aissue+is%3Aopen+label%3Aa%3Aaccessibility

p.s. I'm also curious if you have any actual evidence that these two are more reliable than gtk. It's reasonable to think they might be, but I'd like something more than "they're written in Rust and have fewer features."

p.p.s. How many Firefox Linux users even use the Mozilla crash reporter? I know on Fedora, if I crash Firefox, I get the Fedora crash reporter, not Mozilla's. (edit: apparently they stopped doing that years ago; "Another good example comes from Fedora: they had been using their own crash reporting system (ABRT) to catch Firefox crashes in their Firefox builds, but given the improvements on our side they started sending Firefox crashes our way instead.")

[-] BB_C@programming.dev 1 points 7 months ago

p.s. I’m also curious if you have any actual evidence that these two are more reliable than gtk. It’s reasonable to think they might be, but I’d like something more than “they’re written in Rust and have fewer features.”

I based my suggestion based on the logical requirement stated (first quote) which was later ignored (second quote).

I didn't make any specific claims about imaginary reliability score points.

[-] notriddle@programming.dev 5 points 7 months ago

I based my suggestion based on the logical requirement stated (first quote) which was later ignored (second quote).

I know they call it a requirement, but it has the phrase "as little as possible." If that were taken as broadly as it could be, it would not be written in Rust or C++, since, after all, there might be a standard library problem that takes Firefox and the crash reporter both down.

The stated requirement is "don't use Firefox's code." GTK is not Firefox's code, and the code paths exercised by Firefox are going to be different than the ones exercised by this crash reporter. Besides, a lot of people use GNOME, XFCE, or LXDE: if GTK as a whole is borked, then you wouldn't even be able to start Firefox under these environments, much less crash it.

Also, they list other requirements, not just that one (it's not a requirement if it uses words like "minimal," because there's no definite test to see if you've met the requirement or not; these are all desirables).

We want to minimize the use of external code: to improve crash reporter reliability (which is paramount), we want it to be as simple and auditable as possible.

Firefox vendors all dependencies in-tree, so we are hesitant to bring in large dependencies (GUI libraries are likely pretty sizable).

There are only a few third-party crates that provide a native OS look and feel (or actually use native GUI APIs): it’s desirable for the crash reporter to have a native feel to be familiar to users and take advantage of accessibility features.

They downplay it in this list, but I'm pretty sure a11y is the biggest non-negotiable requirement, so Iced is out of the picture.

Slint, on the other hand, is not a small library at all, and it only has full functionality if it pulls in Qt. There might not be a clear-cut, definite criteria for "minimize the use of external code," but pulling in Qt definitely doesn't count.