[HN Gopher] A command line tool that draw plots on the terminal
___________________________________________________________________
A command line tool that draw plots on the terminal
Author : damir
Score : 528 points
Date : 2023-01-13 07:09 UTC (15 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| radarsat1 wrote:
| Would love to see something like this built into tqdm[0]. Being
| able to attach a graph to the output would be a fantastic
| complement to postfixing the progress bar with current numbers.
|
| [0] https://pypi.org/project/tqdm/
| BruceEel wrote:
| Pushing the boundaries of what can be done in a term, extremely
| cool! Output looks really slick too.
|
| Could it also be used to draw an AST or a DAG?
| 082349872349872 wrote:
| yes; I've seen fancier* (traditional tree) tty output, but my
| ~16-line tree dump just provides a quick-n-dirty AST walk, eg.
| (/) +-(+-) | +-(-) | | +-b | +-(sqrt)
| | +-(-) | +-(*) | | +-b | | +-b
| | +-(*) | +-(*) | | +-4 |
| | +-a | +-c +-(*) +-2 +-a
|
| * for DAGs and fancy output I normally produce .dot and run
| through _graphviz_.
| chrisan wrote:
| This is great (as is seeing all the other links in this thread
| for other variations). Makes me want to make a rpi dashboard for
| a retro "ops view" instead of the fancy/pretty graphs in APM
| tools.
|
| Not saying I'd give those up, but would just a nice lil desktop
| ornament :)
| revskill wrote:
| series2 = data.series .map { |s|
| s.map(&:to_f) } .each_slice(2).to_a
|
| Should we use data.series.lazy for better memory consumption ?
| articsputnik wrote:
| This is so cool. It reminds me of Markdown and Mermaid
| (https://github.com/mermaid-js/mermaid), which can do a similar
| thing within a plain text file. Keep it up; looking forward to
| trying it out.
| hyperific wrote:
| How long before someone used this to run Doom in the terminal?
| jwmoz wrote:
| Can you make this for Python pretty please?
| minimaxir wrote:
| Plotext works similar but isn't as magical.
|
| https://github.com/piccolomo/plotext
| cglodt wrote:
| Check out plotille: https://github.com/tammoippen/plotille
| killingtime74 wrote:
| It's open source, can't you do it yourself?
| damir wrote:
| Looks like it's all based on Drawille, which is python.
|
| https://github.com/asciimoo/drawille
| lynx23 wrote:
| Slightly related
|
| https://github.com/diagrams/diagrams-braille/
| tobyhinloopen wrote:
| Cute
| dima55 wrote:
| You want feedgnuplot: https://github.com/dkogan/feedgnuplot/
|
| It gives you all the power of gnuplot. So you can make simple
| plots in the console, or fancy graphical ones, or output to files
| on disk or whatever.
| db48x wrote:
| I really wish I had known about that a few years ago.
| H4ZB7 wrote:
| what's the point in all these terminal programs posted here every
| day? why would i ever draw stuff with text when it's just going
| to be converted back to pixels by the OS anyway? there's clearly
| a bigger reason than just being able to do stuff without the slow
| desktop environment. but what is it?
| cdiamand wrote:
| It could be useful to graph things on a server where you don't
| have a graphical desktop. Graphing CPU performance is a common
| example.
| H4ZB7 wrote:
| [dead]
| spydum wrote:
| totally, and most significantly: without having to shuffle a
| table off to another app to then be graphed. I definitely see
| high value in this for when you are doing adhoc analysis of
| some data (such as logs) and want to see the items which
| stand out. It's easier to recognize some patterns visually
| for sure. sort/uniq -c/awk are great, but when measuring
| things relative to other things, visualizations are powerful
| for humans.
| eigenhombre wrote:
| Aside from the convenience of having the output exactly where
| you're issuing commands, and the ability to copy-paste the
| output into text documents (admittedly not without its rough
| spots), I frequently find unexpected uses for things like grep,
| sort, uniq, etc. - standard unix tools at the command line,
| even for supposedly purely visual output.
|
| As an example, for the last chart shown: cat
| gencode.v35.annotation.gff3 \ | grep -v '#' | grep 'gene'
| | cut -f1 \ | uplot count -t "The number of human gene
| annotations per chromosome" -c blue | sort
|
| gives an alphabetical ordering, rather than by descending
| count. Or you could search only for a single row of interest,
| or filter out duplicates, or ....
| H4ZB7 wrote:
| [dead]
| kergonath wrote:
| > there's clearly a bigger reason than just being able to do
| stuff without the slow desktop environment. but what is it?
|
| For me, it's visualisation of data on a remote HPC cluster.
| Shuffling data back and forth is dangerous because then
| everything is duplicated and you never know where the latest
| version is. SSH tunnels and remote X sessions are finicky and
| in several contexts blocked intentionally or not. Sixels are
| perfect: the plots are accurate enough to actually see what's
| going on, nothing is moved around, and it works with a wobbly
| VPN server over some dodgy wifi (or 3G).
| throwaway12245 wrote:
| >what's the point? Speed, just want to visualize the data and
| don't want to take hands off of the keyboard and not have to
| refocus on another window.
| KirillPanov wrote:
| > clearly a bigger reason than just being able to do stuff
| without the slow desktop environment.
|
| Nope, there isn't. That is the point. And it's awesome.
| jesusofnazarath wrote:
| [dead]
| mh-cx wrote:
| This looks really nice but I'm missing specs on the format of the
| input data.
| Jtsummers wrote:
| tsv files, tab separated values. From the usage section:
| uplot <command> [options] data.tsv
|
| https://github.com/red-data-tools/YouPlot#usage
| eigenhombre wrote:
| There is, as one might expect, quite a long history of such
| tools, since text-only interfaces were the norm in the olden
| days.
|
| When I was a young one doing physics in the '80s, we used CERN's
| HBOOK[1] to do all our (statistical) plotting. Recently while
| working on a Common Lisp project I had a use for something
| similar, remembered HBOOK, and "rolled my own"[2] (much simpler
| version).
|
| Yes, a nice clean graph in a GUI or PDF is cleaner, but if you're
| working at the terminal already or in a REPL, it can be nice to
| just see the output there.
|
| At the risk of downvotes: I do wish this particular project
| didn't require a working Ruby / Gem installation -- nothing
| against Ruby, but I'd be curious if there was an equivalent
| stand-alone executable written in Go or similar... something like
| [3]?
|
| [1] https://cds.cern.ch/record/307945/files/ [2]
| https://github.com/eigenhombre/hbook [3]
| https://github.com/gizak/termui
| [deleted]
| shagie wrote:
| I recall stumbling across a grapher inside of a book on Awk -
|
| The AWK Programming Language (section 6.2; p135)
| https://ia803404.us.archive.org/0/items/pdfy-MgN0H1joIoDVoIC...
| db48x wrote:
| Wow. There is clearly a fine line between genius and madness.
| anigbrowl wrote:
| If you're a pythonist, the Rich library makes it relatively
| quick and easy to do ASCII stuff.
| Alifatisk wrote:
| Never would have guessed this was written in Ruby, that's so
| cool!
| somat wrote:
| Very nice. For live plots there is also ttyplot.
|
| https://github.com/tenox7/ttyplot
| db48x wrote:
| If you really want to draw plots on the terminal, run `xterm -ti
| 340` and then use gnuplot, like this: gnuplot
| -e "set terminal sixelgd;set hidden3d;set view 60, 30, 1, 1.1;set
| samples 50, 50;set isosamples 52, 52;set contour base;set
| cntrparam order 8;set cntrparam bspline;splot [-12:12.01]
| [-12:12.01] sin(sqrt(x**2+y**2)) / sqrt(x**2+y**2)"
| synergy20 wrote:
| someone please enlighten me, why can xterm do this cool drawing
| while the modern gnome-terminal can not, I tested the GPU
| oriented kitty that can display images in terminal, but it
| could not run gnuplot as xterm. what're missing?
| db48x wrote:
| XTerm implements an old bitmap protocol invented in the 80s.
| The author of Kitty rightly points out that it's inefficient,
| limited to one color per column of 6 pixels (if you want a
| second color you can go back to the start of the line and
| print over). Rather than implement support for the Sixel
| protocol, the author of Kitty choose to implement something
| modern. It's actually rather nice; the program can print out
| a filename for Kitty to load, or even point to a shared
| memory buffer. Those are very efficient options, provided
| your program is running on your local machine.
|
| Meanwhile Gnuplot supports a wide variety of "terminals",
| many of which are just outputs to files of various types,
| some of which are GUIs, others of which are for actual
| terminals, like "dumb" (ordinary printable characters),
| "tek40" and "xterm" which use a protocol invented for
| Tektronix terminals, "sixelgd" which uses the sixel protocol
| from the VT340, half a dozen types of printers, etc.
|
| But nobody has added one for the Kitty protocol, so it
| doesn't work there. The downsides of inventing something new
| I suppose; the existing software doesn't automatically
| support it, someone has to go around and add that support.
| enriquto wrote:
| > what're missing?
|
| Nothing. Xterm is awesome!
|
| And even if xterm is an older program, it seems to be just as
| actively developed as gnome-terminal. See the changelogs for
| each:
|
| https://invisible-island.net/xterm/xterm.log.html
|
| https://gitlab.gnome.org/GNOME/vte/-/commits/master
|
| The second link points to libvte, which is the terminal
| engine behind gnome-terminal where the actual terminalling
| happens. The changes to gnome-terminal itself are mostly
| translations and uninteresting desktop stuff:
|
| https://gitlab.gnome.org/GNOME/gnome-
| terminal/-/commits/mast...
| [deleted]
| msla wrote:
| Also:
|
| https://github.com/saitoha/libsixel
|
| contains img2sixel, which lets you dump images to the terminal.
| It can also do animated GIFs.
|
| Video:
|
| https://github.com/saitoha/FFmpeg-SIXEL
|
| GUI apps:
|
| https://github.com/saitoha/SDL1.2-SIXEL
|
| and more, linked from the libsixel repository.
| dgacmu wrote:
| This is astoundingly great - thank you for linking!
|
| (The expected use case - generating quick plots on a remote
| machine; I usually just scp them back, but with this, and the
| new-to-me matplotlib integration, i can just have them show
| up in the terminal without having to launch a notebook or
| fight with X). Well supported by iterm2 on mac as the
| terminal side.
| db48x wrote:
| It's one of the lesser-known superpowers :)
| junon wrote:
| Sixel is, woefully, not very well supported by terminal
| emulators :/ I really wish it were.
|
| There's also the Kitty graphics API but I've never actually
| seen it work on any machines I've used Kitty, Wezterm, etc.
| that supposedly support it.
| smasher164 wrote:
| Yeah, in an effort to spur adoption, I built (shameless
| plug) https://www.arewesixelyet.com/. What's interesting is
| that if VTE gets support, a lot of other terminals will,
| since they depend on it.
| kps wrote:
| mlterm supports sixels --
| https://github.com/arakiken/mlterm
| __alexs wrote:
| xterm even has a tektronix mode which can render vector
| graphics directly in the terminal.
|
| [1] https://www.dim13.org/teapot [2]
| https://jirkasnotes.wordpress.com/2019/07/17/xterm-does-grap...
| db48x wrote:
| Yes, but only in monochrome, and in a separate window.
| cb321 wrote:
| https://st.suckless.org/ used to have a circa st-0.8 fork
| that supported full color sixel graphics, but it seems that
| specific patch is not in the official list anymore. [1] I
| think the work moved to https://github.com/jhhuh.
|
| You can even compose the gnuplots with the scrollback patch
| to scroll back in your gnuplots. I use this all the time.
| In fact, I just have GNUTERM="sixelgd enhanced linewidth 3
| fontscale 2 size 1600,900 truecolor" in my environment
| variables.
|
| Combined with shell history (or gnuplot history) this makes
| for a rudimentary "notebook"-like interface, but with a log
| instead of a file to record state.
|
| [1] https://st.suckless.org/patches/
| mzs wrote:
| here I believe: https://github.com/jhhuh/st-sixel
| rjzzleep wrote:
| There's an alacritty fork with sixel support[1], albeit
| without vector support.
|
| There's also kitty that has some improvements over
| sixel[2]
|
| [1] https://github.com/microo8/alacritty-sixel
|
| [2] https://sw.kovidgoyal.net/kitty/graphics-protocol/
| cb321 wrote:
| Yeah. Good points!
|
| You could also use the techniques of [1] but use `set
| term png` and `set output "/tmp/pl.png"` instead and then
| auto-launch any image viewer on "/tmp/pl.png" instead of
| relying on terminal graphics at all.
|
| [1] https://news.ycombinator.com/item?id=34366758
| db48x wrote:
| That would completely defeat the point! :)
| cb321 wrote:
| Lol :)
| wpietri wrote:
| Is gnuplot better for the use cases demonstrated on the page
| here?
|
| I've always avoided gnuplot because it has looked pretty hard
| to get anything useful out of. But uplot looks much more
| approachable. Just piping some data to "uplot hist --nbins 20"
| is something I'll remember.
| db48x wrote:
| I don't actually get much chance to use gnuplot, but it can
| plot data from a pipe. The syntax is a bit more involved as I
| recall.
| cb321 wrote:
| Within the gnuplot shell you use `<` at the start of a
| "filename" like gnuplot> plot '<pipeline'
|
| It just uses system(3) for "pipeline". So, technically you
| could have a whole script in there with maybe tricky
| gnuplot-quoting/escaping of shell stuff.
|
| You do have 2 different history logs this way - the shell
| one and the plot one while the uplot way is integrated.
|
| If you really want integrated, you could drive gnuplot with
| temp files, though each shell command-line would probably
| have to pass a lot of controls. E.g.,
| #!/bin/sh cat > /tmp/dat # should use
| mktemp -d cat > /tmp/p.gpi <<-EOF plot
| '/tmp/dat' $* EOF gnuplot /tmp/p.gpi
|
| and then $ seq 1 10 | gpl with lines
|
| It is an exercise for the reader (well, it has probably
| been done N times...) to harden the temp paths, clean up
| afterward, generalize to source user/maybe per-directory
| `foo.gpi` setup and so on.
|
| In the unlikely event temp space is actually any sort of
| issue then you might be able to use mkfifo (I've never
| tried) or else generate a .gpi script that uses the plot
| '<string' syntax escaping `string`.
| db48x wrote:
| No need for any of that; gnuplot can just read from the
| pipe directly: `seq 1 10 | gnuplot -e "plot '<&2'"`
| cb321 wrote:
| Nice! Added in 2008, if anyone is curious. (EDIT: and in
| db48x's comment already[1]) Also, I had to put in a `cat`
| to make it work: seq 1 10 | gnuplot -e
| "plot '<cat' with lines"
|
| [1] https://news.ycombinator.com/item?id=34365290
| db48x wrote:
| Oh, that goes to show you how little I use it. I read the
| documentation and merely assumed that it would work for
| stdin, but gnuplot exits with an error in that case. This
| will work, but it's pretty funky:
| gnuplot -e "set terminal sixelgd;plot '<&3' with lines"
| 3< <(seq 1 10)
|
| Good luck remembering that!
| enriquto wrote:
| No need of cat. You can use filename "-" to mean standard
| input: seq 1 10 | gnuplot -e 'plot "-"'
| lajosbacs wrote:
| Didn't know it can do that (in iterm2 works nicely).
|
| My favourite use of gnuplot, over ssh, is to plot ascii, just
| like the presented tool does. Just use set
| terminal dumb size `tput cols` `tput lines`
| quijoteuniv wrote:
| Excellent! Often the results from reading about "new" tools in
| HN is that i find out about well established tools i should
| check before :)
| Aardwolf wrote:
| This worked directly in Konsole for me without "xterm -ti 340"
| and it renders a high res image, which surprised me: I have
| used low-res images in the terminal using block characters and
| 24-bit colors before, but never seen this high res
|
| How does it do this?
|
| One weird thing seems to be that it doesn't support zooming
| in/out the same way the regular text does.
| TomJansen wrote:
| Konsole now supports many different image rendering
| protocols: sixel, iTerm2 and Kitty image protocols. See https
| ://invent.kde.org/utilities/konsole/-/merge_requests/59...
| db48x wrote:
| Magic :)
|
| No, for the VT340 they devised a set of escape sequences for
| encoding bitmaps called Sixels; each character encodes a
| vertical stripe of six pixels. They used it both for
| displaying graphics and printing. They also did a vector
| graphics system called ReGIS a few years earlier.
| earthscienceman wrote:
| This will be the most hideous comment I've ever made on the
| internet.
|
| I would die for something like this to be an emacs package, to be
| written in elisp. I do all my development and data processing in
| emacs on remote clusters and it is insanely efficient and quick
| to iterate. The only thing that slows me down is getting and
| making plots. I can, of course, but I still mount the drive and
| transfer plots as compressed images. Which is horrifically
| inefficient for doing very quick rapid iterations on the
| processing of data....
|
| Of course, the effort to duplicate the functionality of this in
| elisp that properly displays in the emacs TUI would be herculean.
| But there's no way I can install ruby on my remote clusters :(
| dima55 wrote:
| Not sure if this is what you want, but you can pipe emacs
| regions into shell commands, which interoperates nicely with
| lots of stuff. I routinely hit M-| to make plots with
| feedgnuplot. Works great
| earthscienceman wrote:
| Ok, yeah. I had no clue that was a thing. That will be
| _extremely_ useful. I 'm often running python in a buffer and
| being able to run commands on output is a dream. Thanks
| dima55 and thank you emacs.
| rcarmo wrote:
| This is pretty amazing, but is there a non-Ruby alternative?
| Alifatisk wrote:
| What's wrong with a cli written in Ruby?
| Annatar wrote:
| [dead]
| nsteel wrote:
| On the workstations at my work: `gem: Command not found.`.
|
| On my home machine: `Command 'gem' not found, but can be
| installed with: sudo apt install ruby-rubygems`
|
| Not the end of the world but it is annoying enough to put me
| off trying it.
| Alifatisk wrote:
| I understand, so you would prefer the package to be self
| contained & available through apt directly?
| wpietri wrote:
| I'm happy with Ruby for a CLI tool, but I'd love to have
| something like this as a python library!
| marcuskaz wrote:
| I have a Python one, Termgraph, but maybe not as feature full
| as this one https://github.com/mkaz/termgraph
| wpietri wrote:
| Neat! Thanks for mentioning it. I'll check it out!
| lucidguppy wrote:
| https://pythonawesome.com/a-python-library-for-all-your-
| term...
| folex wrote:
| awesome!
| jll29 wrote:
| Elegant, useful and simple - thanks!
| zokier wrote:
| Terminal is not a graphical environment so why try to make it
| into one? Isn't the point of terminal to escape the graphics-
| riddled world
| rfrey wrote:
| The point of the terminal is to interact with the computer
| using the infinite possibilities of the alphabet.
| 082349872349872 wrote:
| Proposed: _Terminal is not a graphical environment_
| assent: # dissent: ####
|
| (in this thread, as of writing)
| nextlevelwizard wrote:
| >Isn't the point of terminal to escape the graphics-riddled
| world
|
| No, or at least not for me.
|
| I use terminal because it is the best tool I have found to
| solve my problems. My problem with graphical user interfaces is
| lack of customization options and having to conform into
| certain way(s) of working.
|
| In my terminal I can easily construct the the UI how I want and
| I can use all the tools as they were intended (of course
| assuming the tools were designed to work on CLI). I like
| building tiny and light terminal UIs for to help me.
|
| Data is the outlier. I can wrangle the data just fine using
| `$EDITOR`, but I have to visualize it somehow. Often I just end
| up working in a Jupyter notebook (inside a browser) and
| lamenting how I don't have nice access to some tool. I don't
| know if this plotter tool will change anything, but I will give
| it a go.
| awestroke wrote:
| You don't get to dictate how I interact with my terminal. I
| like colors in my terminal, I like nicely formatted output with
| columns, I like ligatures, I like emojis in output.
| voytec wrote:
| I share your point of view. Would love to see the ability to
| turn emojis off in a lot of CLI tools.
| junon wrote:
| Depends on your viewpoint. To me, the terminal is a fixed sized
| canvas (as long as you're not resizing e.g. a window or
| something). The fact there's auto-scrolling and a backlog are
| features of your shell, less the terminal emulator itself (even
| though backlog is actually implemented by the emulator).
|
| This comes down more to philosophy than anything, though.
| detrites wrote:
| It _is_ a graphical environment.
|
| Various unique graphical symbols are arranged and manipulated
| across a uniform fixed grid (typically also in colour).
|
| The defining feature of the terminals graphics system is this
| grid which makes both location of updates and the display speed
| largely uniform quantities. These can then be anticipated,
| accustomed to and relied upon.
|
| Ingesting data is faster and more meditative when free of the
| additional distractions of more complex graphical environments.
| These charts present complex information without breaking the
| terminals unique advantages.
| jb3689 wrote:
| The weakest part about distributing these tools in Ruby for me
| has been rbenv wiping them away on switches. I rarely switch Ruby
| versions these days, but this used to be pain all of the time
| synergy20 wrote:
| gnome-terminal really need to support kitty like features, that
| is, draw images and plots directly inside the terminal, xterm can
| do that, konsole is adding them, gnome-terminal please add the
| support so I do not need switch to kitty(which is OK, but)
| JoeyBananas wrote:
| Drawing graphics in the terminal is trying to use a hammer as a
| screwdriver. I'm looking at you, Textualize.
| enriquto wrote:
| In other words, a hack. And that's why we are here!
| guntars wrote:
| So many times I've wanted a quick histogram of a list of values
| to get a feel for their distribution, but it's always felt like
| it's too much effort with the tools that I had available to me.
| This is perfect for it! Would be nice to be able to specify the
| bin size or clamp the values to a range, but that can be done
| with other tools in the pipeline.
| aborsy wrote:
| How does gnuplot compare with Python's pyplot or Matlab plots in
| terms of quality and versatility?
| enriquto wrote:
| Isn't this a bit off-topic for this thread?
|
| Anyways, as a user of the three, I find that the main advantage
| of gnuplot is that you can do simpler plots more easily than
| with the others, as there's often no boilerplate needed. I
| don't mean, "almost no boilerplate"; I actually mean zero
| boilerplate. The complete gnuplot program
| plot sin(x)
|
| is difficult to beat. However, even if you can do _everything_
| that you want with gnuplot, some complex plots may become a bit
| unwieldy to describe.
|
| Regarding quality, I guess this concerns mainly the default
| settings. The answer depends entirely on your tastes. In my
| case I find the matlab defaults of a very good quality,
| followed by those of gnuplot. I don't like the default settings
| of plotly and matplotlib.
| aborsy wrote:
| Thanks! Yes, a bit off topic, but it was the closest post in
| which to ask this question that I had.
|
| I have used all three. GnuPlot is clearly fastest, but the
| documentation and community help are limited. It seems not
| very flexible either.PGFPlots beats them all IMHO!
|
| I tend to think most of the Gnu software is in decline.
| enriquto wrote:
| There's #gnuplot on libera, which is a bit slow, but still
| faster than waiting for a relevant post in HN to ask your
| questions.
| yboris wrote:
| Looks really great! I love tools that work in the terminal.
|
| I used _asciichart_ in my _mortgage-and-investments_ script for
| the terminal (shows a nice graph).
|
| https://github.com/whyboris/mortgage-and-investments <--
| screenshot there
|
| https://github.com/kroitor/asciichart <-- the library I used
| Pr0ject217 wrote:
| Cool. Thanks!
| majkinetor wrote:
| Gorgeious.
|
| I would even use this just to be cool in the public :)
|
| As a realted note, here is one similar thing in Powershell:
| https://github.com/PrateekKumarSingh/Graphical
| anthk wrote:
| Gnuplot does that too.
| jesusofnazarath wrote:
| [dead]
| Annatar wrote:
| [dead]
| kaba0 wrote:
| Cool, but.. why?
|
| I do like CLI apps, but due to the non-standard state of GUI
| development we reach for very inefficient hacks to display
| basically pixel data in a fundamentally text-based medium. I
| would much prefer well-integrated actual GUIs using more than
| 100x100 pixels.
|
| Edit: I don't really have a problem with this specific program.
| My point is more general in that we perhaps have the wrong
| abstraction level for our GUI programs. Those should be
| standardized and cross platform as well besides supporting remote
| access .
| lunfard000 wrote:
| one use case that I can think of is for monitoring something.
| Let's see you have tmux open fullscreen, working in one of the
| panes and have an auto-updating graph at one of the corners to
| check the value of your stocks (?).
| shakow wrote:
| Because I can run it on remote computers.
|
| Because I can put it at the end of a series of pipe.
|
| Because I want to see a few exploratory plots without launching
| an external program.
| darkwater wrote:
| > Cool, but.. why?
|
| I would say: composability. As you can see in the examples the
| datasources are very different, and for some one off
| observation this can be totally handy (if you don't need to
| massage the data too much, probably).
| hk__2 wrote:
| You could have a CLI tool that opens a GUI window, like
| matplotlib does in Python.
| wpietri wrote:
| Exactly. GUI apps trade generality for approachability. The
| GUI version of this already exists; it's part of Excel.
| ape4 wrote:
| You can make the next `top` tool. kaba0top
| [deleted]
| flohofwoe wrote:
| Terminals use a standardized protocol and enable cross-platform
| applications with minimal code and runtime footprint, which
| also work remotely via ssh.
|
| I really would like to see a proper and universally supported
| pixel framebuffer standard for terminals though (sixels don't
| really cut it).
| yboris wrote:
| Haven't heard of _sixel_ until you.
|
| Direct link to a (related?) project
| https://saitoha.github.io/libsixel/
| dan-robertson wrote:
| This is true if you want to output ascii and mostly true for
| ANSI colours but otherwise I think this is very false. To
| point out some of the ways that it is false:
|
| - different terminal (emulators) support different abilities
|
| - those abilities are controlled with different control codes
|
| - there isn't much of a standard. There are some de-facto
| standards for advanced features from whichever terminal
| emulator first implemented them but there is a lack of bug-
| for-bug compatibility
|
| - Unicode, character widths, rtl, etc. Unicode matters for
| things like this plotting program. What happens if you draw a
| double-width character? And then position your cursor 'half-
| way' through it?
|
| - there is terminfo but it works in a janky way and you can
| get all sorts of problems if eg the remote box doesn't have
| your terminal (or all it's new features) in the terminfo
| file. To some extent you can copy over terminfo files but
| that doesn't sound much like 'standardized protocol' or
| 'cross-platform applications with minimal code' to me.
|
| - some apps don't look at term info and eg just assume your
| terminal supports the same escape codes as the author's
|
| I basically feel like the above comment is making broad
| claims about the advantages of terminals however those claims
| are only narrowly true and importantly, aren't true for the
| situation being talked about in the comment which those
| claims are made in response to.
| flohofwoe wrote:
| It's not quite as bad as you are describing it. IME, TUIs
| via ncurses, UNICODE characters (e.g. for box drawing) and
| at least 256 colors work pretty much everywhere and gets
| you pretty far (think 'Turbo Pascal' or 'htop' style UIs).
|
| ...unless you're on the old DOS/Windows terminal of course
| (the new one should be much more conformat:
| https://apps.microsoft.com/store/detail/windows-
| terminal/9N0...)
___________________________________________________________________
(page generated 2023-01-13 23:01 UTC)