EDITOR’S NOTE: This is part of a series, start here.
If you’re following along it’s been like six months since the last update. While I…
See the ellipsis up there at the end of that last sentence? The one that I stopped caring about before I finished the second sentence? I wrote that last August. A year ago. Yeah. Okay. So back to it. It’s 2020, a lot happened since the last time I started looking at this.
I’m looking at this project again with fresh eyes and some new ideas. I kind of came at it sideways. I was fooling around with OpenWatcom in the hopes of doing some old school DOS development, just for giggles. I started poking around at potential TUI options for DOS, and stumbled upon PDCurses. I have had minimal exposure to curses, other than as the UI for terminal-based Linux installers. I didn’t really have any idea what it could do beyond that blue and red menu deal. Turns out that not only is it pretty capable, it’s probably the exact library that would have been used to do this if our fabled spaceship interface was developed using 70s/80s technologies.
PDCurses compiles under modern Windows with Mingw64 just fine, and there’s even an SDL2 version that uses an SDL surface to render the terminal, so you can keep everything consistent across different computers and such. The SDL interoperation will probably also afford some cool terminal/CRT/shader effect type things, I’ll have to screw with it a bit.
Because the UI I can build with curses is much more constrained, text-only, and mouse free (yes, there are ways to support mice, I’m not doing it) it helped me constrain the concept to what I could do with a relatively simple UI.
There’s this nifty little thing built into curses that was intended to be on-screen “soft labels” for the function keys on the terminal. This gave me the idea of navigating all the screens in the interface via the function keys, keeping the first four or five as “hard” assignments to navigate through the main screens and then leaving the remaining eight or so as “soft” to perform actions on individual screens or to open subscreens. This creates a more or less hierarchical menu system that can be quickly navigated with only the function keys.
So far, the hierarchy looks something like this:
- LONG RANGE
A “screen” will be a set of function pointers and a struct that can be handed back to a main loop.
Goal for the moment is to get a very simple INFO/NAV/CTRL interface going, so you could conceivably “fly the ship”.← Xoth Devlog Pt. 10 AWS Amplify Is Almost Great →