Re:Emulating the DMD 5620 Terminal (2018)
by ogoffart on Wednesday March 13, 2024 @05:42PM
(#39697908)
> 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.
Re:Emulating the DMD 5620 Terminal (2018)
by 0xcde4c3db on Wednesday March 13, 2024 @07:21PM
(#39698751)
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.
Re:Emulating the DMD 5620 Terminal (2018)
by tonyarkles on Wednesday March 13, 2024 @11:36PM
(#39700360)
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?
Re:Emulating the DMD 5620 Terminal (2018)
by ogoffart on Thursday March 14, 2024 @02:11AM
(#39700996)
> Is there a great Rust GUI library that is both lightweight and looks good?
I'm going to say Slint. https://slint.rs
Re:Emulating the DMD 5620 Terminal (2018)
by tonyarkles on Thursday March 14, 2024 @09:07AM
(#39703469)
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.
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?