[codelobe]

> The second front end, the one I’ve actually published on GitHub [ed: link now defunct, since the JavaScript front end was scrapped], uses JavaScript for the drawing, and Neon Bindings as a Rust-to-JavaScript bridge. It’s packaged as an ElectronJS app because ElectronJS apps can be built and deployed to all the major platforms, which was an essential goal.

Ugh, all that just to provide a HTML5 canvas pixel buffer to a native (Rust) app. The pain of doing simple input/audio/graphics on GUI OSes today... We've made a wrong turn. It's back to TUI for me. Would you accept sixel graphics for the DMD 5620 Terminal's display?

> The main pain point so far has been working with the JavaScript ecosystem, which has hitherto been an enigma to me. I’ve found ElectronJS to be somewhat painful to work with because, although it is indeed cross platform, there are many caveats. The primary issue is in recompiling native NodeJS modules across platforms, which took some trial and error to get working correctly. In fact, I still haven’t produced a Linux app bundle yet, because the build keeps failing in ways I don’t quite understand.

> In general, it feels like JavaScript and NodeJS modules are a lot more brittle and error-prone than the code I’m used to working with.

Seriously, its $CURRENT_YEAR and getting a simple cross platform windowed graphical application up and running is still a pain? Hey that emulator community, say, MAME or BSNES might be of help -- oops, Rust... yeah, maybe not? Why isn't a simple GFX/audio/input API a must-have in any [new] language today?

[ogoffart]

> Seriously, its $CURRENT_YEAR and getting a simple cross platform windowed graphical application up and running is still a pain?

$CURRENT_YEAR was 2018. Really early in the Rust history. There are now a bunch of Rust GUI framework to choose from.

[0xcde4c3db]

This is definitely a tangent, but the thing that bugs me is that I think it's not really so much a Rust problem as a general desktop app problem. It feels seriously wrong to me that we're embedding Chromium or linking megabytes of crusty GUI library code (some old enough that it has its own "future-proof" string type invented when Unicode was still 16-bit) into the app's address space instead of something that looks more like "open the NeoNeWS+Tk socket and utter a few TLVs, and it Just Works" (maybe C programmers need to remember to call fflush(), though). Instead we're expected to be impressed when Electron adds native Wayland support.

And I mean... it's not wrong to be impressed at the effort or the people involved, but I'm not sure what we're actually doing here.

[tonyarkles]

I’ve played a bit with CLI Rust but haven’t yet tried diving into GUI Rust. The language feels like it aught to be great for making really robust and performant GUIs but when I look at lists like this: https://blog.logrocket.com/state-rust-gui-libraries/ I generally feel disappointed… it’s GTK4, FLTK, or embed a web browser? Am I missing something? Is there a great Rust GUI library that is both lightweight and looks good?

[ogoffart]

> Is there a great Rust GUI library that is both lightweight and looks good?

I'm going to say Slint. https://slint.rs

[tonyarkles]

Nice! I’ll have to play with it a bit!

Sigh, I was quite excited to see the embedded stuff with that but then discovered that you need a commercial license and pay royalties to use it in a non-GPL3 embedded device. But that’s the same story as Qt so it’s not all that unusual.