
Termbox-Go – A minimalistic Go curses library - MaxLeiter
https://github.com/nsf/termbox-go
======
heavenlyhash
Another alternative to consider is
[https://github.com/gdamore/tcell](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.

~~~
akkartik
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](https://github.com/akkartik/mu#readme)

~~~
heavenlyhash
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.

~~~
akkartik
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.

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

~~~
akkartik
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](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...](https://github.com/akkartik/mu/blob/d9ee2076d9/termbox/makefile)

~~~
lacampbell
Wow, it was as simple as that. Legend!

------
EvanMiller
I'm a fan of this library -- I used it to build Hecate
([https://github.com/evanmiller/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).

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

~~~
tene
I don't know about Go, but there's quite a nice similar library for Haskell,
[https://hackage.haskell.org/package/concurrent-
output](https://hackage.haskell.org/package/concurrent-output)

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

~~~
dtjohnnymonkey
You might try this from my co-worker:
[https://github.com/sethgrid/multibar](https://github.com/sethgrid/multibar)

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

------
libeclipse
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](https://github.com/jroimartin/gocui)

------
andrewfromx
my stackover question from August 2016
[http://stackoverflow.com/questions/38728614/how-do-i-
control...](http://stackoverflow.com/questions/38728614/how-do-i-control-
where-text-is-printed-to-console-via-fmt) before i knew the term curses. Thank
you photoionized, you changed my life.

------
aetherson
...curses?

~~~
LukeShu
[https://en.wikipedia.org/wiki/Curses_(programming_library)](https://en.wikipedia.org/wiki/Curses_\(programming_library\))

The standard UNIX terminal UI library.

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

[https://code.google.com/archive/p/termbox/](https://code.google.com/archive/p/termbox/)

~~~
ape4
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...](https://code.google.com/archive/p/termbox/wikis/Rationale.wiki)

~~~
lucaspiller
> 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](http://www.vt100.net/docs/vt100-ug/chapter3.html)

~~~
ape4
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.

