termbox-go has a couple of pretty wicked global variables, and they caused me a surprising amount of issues last time I used it. By contrast, tcell has good interfaces, and it shows: tcell even has a SimulationScreen you can use for testing.
Interesting you should mention testing, since I use termbox (not termbox-go) in a teaching/exploratory project to come up with more testable OS primitives. Among other things, I implemented a fake screen for this project.
Thanks! Though I don't want to overstate where we are at this point. I implemented all this at the "syscall" level for an extremely toy simulated computer. We don't really yet have the chops to implement syscalls in a real-world OS. But my collaborator and I have been slowly learning what we need. The first system we've been playing with is OpenBSD.
Last time I tried to use termbox (the C version), it required a build tool in python that I'd never heard of (waf), which then required me to do all kinds of yak-shaving to get up and running. All to compile a small C library.
I'm not saying waf is bad, I've never used it (obviously, since I failed to install it). But it was an annoying hoop to jump through.
I do think re-doing the old unix lib faithfuls is a Good Idea. A cleaner curses like library with a better interface would be great.
I'm a fan of this library -- I used it to build Hecate (https://github.com/evanmiller/hecate), a terminal hex editor. If you get creative with Unicode box and box-drawing characters, you can build some interesting interfaces (tabs, progress bars, etc).
Speaking of Go and terminals, is there a library that doesn't take over the whole screen? For example, let's say I want to display a three-line progress bar. I want to update just that three-line area, and when done, remove all the lines and continue from there, and otherwise just integrate into the text flow of the terminal.
I started writing the dumbest-possible thing-that-can-work here: https://godoc.org/github.com/polydawn/go-slog but don't necessarily recommend it. (There's barely enough code there to be worth linking, honestly.)
It doesn't do anything fancy -- certainly not like the progress bars linked in a sibling comment -- but it also works without setting the TTY into raw mode, which means your scrollback is never disrupted.
> No optimization of data sent because everything is fast now (really?)
As the link says it's a trade off between CPU and bandwidth. Most of us aren't using 9,600 baud terminals nowadays, so it seems like a fair trade-off.
I'd imagine these 'optimisations' include workarounds for the way certain hardware works as well:
"The terminal can operate at transmission speeds up to 19,200 baud. However, the terminal may not be able to keep up with incoming data. The terminal stores incoming characters in a 64-character buffer and processes them on a first-in/first-out basis. When the content of the buffer reaches 32 characters, the terminal will transmit 0238 (XOFF or DC3). On this signal the host should suspend its transmission to the terminal. Eventually, if the host stops transmitting, the terminal will deplete the buffer. When 16 characters remain in the buffer the terminal will transmit 0218 (XON or DC1) to signal the host that it may resume transmission."
My goodness that's a terrible thing to have to deal with. But the termbox page says "But nowadays we don't have terminals anymore! We have terminal emulators which reside on the same machine. Exchange rates are not a problem anymore." So it still sounds like its assuming you are going to localhost and not over the internet so there is no need to compact the VT100 codes that are sent.
termbox-go has a couple of pretty wicked global variables, and they caused me a surprising amount of issues last time I used it. By contrast, tcell has good interfaces, and it shows: tcell even has a SimulationScreen you can use for testing.