cargo-deb VS Cursive

Ok, AMDGPU_TOP v0.1.3 is released. And the deb package is released at the same time (thanks cargo-deb).

cargo deb?

Rust actually works fine with distros. See for example https://github.com/kornelski/cargo-deb and https://wiki.archlinux.org/title/Rust_package_guidelines

I use Arch Linux and Most Rust programs I use are installed from the Arch repositories or AUR. Rust packages are very well integrated with the distro, they depend on distro packages and have other packages depend on it. As far as the user is concerned, the Rust build system is just a developer-only stuff like CMake or autotools or ninja or whatever.

Anyway I would like to point out that C++ also do something similar to what Rust libraries typically do, which is to use header-only libraries that don't appear as separate distro packages. It's as if every Rust library meant to be used by Rust programs (as opposed to libraries that expose a C API that can be called by other languages) were a header-only library. And this is actually great because Rust (like C++) monomorphizes generics, that is, if you call a generic function defined on another crate, the compiler actually generates a new function just with the type parameters you supplied, and there's no way the library can know upfront which generic instantiations will happen over all programs that use it.

On the reproducibility front, I think it would be great if C program actually did what Rust does and pinned the exact damn versions of all libraries they use (like Cargo.toml does)

Rust has great libraries for TUIs. tui-rs (https://github.com/fdehau/tui-rs) has been used in numerous popular applications, but is unmaintained. ratatui (https://github.com/tui-rs-revival/ratatui) is the maintained version, and is pretty new. Less widely known is cursive (https://github.com/gyscos/cursive), which I have yet to try.

Aside from the libraries, I just wanted to start a project that would make be better at Rust. The easy distribution with cargo is a huge bonus though.

There are plenty of terminal UI libraries that are actually nice to work with. For Python, there's Textual and PyTermGUI. For Rust, there's ratatui and Cursive (or, if you want something a bit lower level, crosster or termion). For Go, there's bubbletea.

Switching the backend of Cursive to crossterm removed dependence on ncurses

I'd hear of TUIs so I just searched for tui libraries in Rust and Cursive seemed like a good choice and it turned out great!

This weekend I started porting my game to a different UI library (egui) as a way of familiarizing myself with egui. I don't think I'll have something useable to build off of before this year's 7DRL challenge so I guess I'll be reusing my existing UI code (using cursive). But, once I finish porting the UI it should be a lot easier to add fancy stuff like animations, tooltips, and graphical tiles since I won't be tied to constraints of a terminal UI.

Cursive should let you easily build a layout with a menu and status bars (and mouse works).

The thing that gets me about Dwarf Fortress is that it's a 64-bit text-mode game.

As a grey-haired developer who got excited about "DOS Extenders" that allowed 32-bit mode, seeing a text-mode game written as a native 64-bit application is bizarrely anachronistic.

I get a similar feeling from text-mode GUI frameworks for Rust, which allow multi-threading and 64-bit but are essentially clones of Borland Turbo Vision, where you had to be mindful to keep lists smaller than 64KB: https://github.com/gyscos/cursive

Maybe this helps?

cursive