Termbox-Go – A minimalistic Go curses library | Hacker News Reader

Termbox-Go – A minimalistic Go curses library

github.com

102 pointsMaxLeiter29 comments

Another alternative to consider is https://github.com/gdamore/tcell

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.

https://github.com/akkartik/mu#readme

Wow, that's... just, wow.

> New, testable interfaces for the operating system.

So you implemented this at the syscall level, and that just happened to include a tty? Very neat.

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.

tcell is what is used by the micro editor https://github.com/zyedidia/micro

Another alternative that provides a higher-level interface with widgets is https://github.com/gizak/termui. I used it to build sparkyfish, my open source console-based network speed tester: https://github.com/chrissnell/sparkyfish

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.

Once I got it running, I figured out what commands waf was running and then ripped it out. You can see my changes inlined at https://github.com/akkartik/mu/tree/master/termbox

Edit: ack, sorry I momentarily forgot that I also recently ripped out my project's dependence on `make`. You can see my old makefile at an earlier commit: https://github.com/akkartik/mu/blob/d9ee2076d9/termbox/makef...

Wow, it was as simple as that. Legend!

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 don't know about Go, but there's quite a nice similar library for Haskell, https://hackage.haskell.org/package/concurrent-output

Right, I'd love something like that for Go.

You might try this from my co-worker: https://github.com/sethgrid/multibar

Nice, thanks. I'd like something like that, but generalized for any output, not just progress bars.

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.

I was looking at termbox-go but then came across gocui[0], which uses termbox-go to do some really quite powerful things.

[0] https://github.com/jroimartin/gocui

my stackover question from August 2016 http://stackoverflow.com/questions/38728614/how-do-i-control... before i knew the term curses. Thank you photoionized, you changed my life.

...curses?

https://en.wikipedia.org/wiki/Curses_(programming_library)

The standard UNIX terminal UI library.

Link is to a Go lib for termbox, which is a Curses alternative. Title is inaccurate.

https://code.google.com/archive/p/termbox/

Apologies, should say 'termbox alternative'

Then change the title?

I can't edit the title once it's submit

Ah. I thought you could. Sorry then.

If you let us know what a more accurate title would be, we'll change it for you.

That site has the reason for Termbox. Simpler interface (good). No optimization of data sent because everything is fast now (really?) https://code.google.com/archive/p/termbox/wikis/Rationale.wi...

> 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."

http://www.vt100.net/docs/vt100-ug/chapter3.html

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.

Reply on news.ycombinator.com