[HN Gopher] Ftxui: C++ Functional Terminal User Interface
___________________________________________________________________
Ftxui: C++ Functional Terminal User Interface
Author : ingve
Score : 127 points
Date : 2021-06-05 10:50 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| HKCM852 wrote:
| Wow this look great. Does anyone have a good recommendation for
| the equivalent in Python?
| dangrie158 wrote:
| rich[0] has some nice Lay-out functionality [1]
|
| [0]: https://github.com/willmcgugan/rich
|
| [1]: https://www.willmcgugan.com/blog/tech/post/building-rich-
| ter...
| antattack wrote:
| For a polished gui as FTXUI is I am surprised that horizontal bar
| movement is rather jerky, as it appears to move two steps
| forward, one step back.
|
| https://arthursonzogni.com/FTXUI/examples/?file=./component/...
| kzrdude wrote:
| Compiling all the demos to wasm and showing on the site is what
| would have been such an impressive feature before and now seems
| common.
| creamytaco wrote:
| C++ ensures this will never be used widely.
| pipologist wrote:
| Yes like you didn't use a browser written in C++ to write that
| comment
| vitaut wrote:
| And yet C++ is one of the most popular languages in the world
| and widely used in the industry including most (all?) tech
| giants.
| pjmlp wrote:
| To reinforce that, even those giants that are slowly adopting
| Rust, do have employees seated at ISO C++ table and are major
| contributors to its compilers and IDEs.
| layoutIfNeeded wrote:
| Lol, sure! The amount of software written in C++ is minuscule
| compared to Rust, right?
| p1131 wrote:
| Looking at the source, I think it "renders" and reprints the
| whole "frame" everytime... In which case it might be bad...
| kragen wrote:
| That's a reasonable thing to do nowadays; I wrote a terminal
| text editor on a Sharp Zaurus in 02003 that worked that way,
| and it was fine. ssh -C removes most of the bandwidth cost if
| you're doing this remotely. You do have to be a little careful
| about flicker, and probably on mobile devices (like the
| Zaurus!) it costs you battery life.
| einpoklum wrote:
| I am worried by the sentence:
|
| > Cross platform (mostly). Linux (main target), Windows
| (experimental), Mac.
|
| So, it is not targeting _terminals_ (like traditional libraries
| do, including ncurses), it is targeting entire operating systems.
| That suggests it might be relying on things it shouldn't be
| relying on, and possibly making a bunch of simplifying
| assumptions. Given that it also says:
|
| > No dependencies
|
| I'm even more worried.
| jcelerier wrote:
| > That suggests it might be relying on things it shouldn't be
| relying on,
|
| why ? If I have a choice between using a software that works on
| mac / win / linux, and one that works on those three + a ton of
| obscure architectures / old systems I'd definitely choose the
| first one - every additional platform supported invariably
| means that :
|
| - you have to give up some features or reimplement them
| yourself (because you _want_ that feature anyways) thus more
| possibilities of bugs, e.g. the amount of times I 've seen
| people reimplementing badly some POSIX functions or stuff like
| clock_gettime on windows
|
| - you have to duplicate code, say DLL / so loading if you have
| some plugin system (plus a mess of #ifdefs because of shit like
| macOS having a non-functional pthread_cancel, etc...)
|
| - in some cases this may mean that the program author needs to
| add some run-time indirections, e.g. to call platform
| functions, which may have a performance cost.
|
| - most likely the build system will be some terrible autotools
| mess which has not been updated in 15 years and does need 50
| changes before working on a modern linux distro (had that
| merely a week ago) + a batch script for windows
|
| - maybe some performance / technical improvements /
| simplifications would not be available because they would break
| compatibility with whatever EBCDIC IBM platform with two users,
| thus making the software worse, condemning us to the "state of
| the art" of the oldest supported platform
|
| etc etc...
| einpoklum wrote:
| > If I have a choice between using a software that works on
| mac / win / linux, and one that works on those three + a ton
| of obscure architectures / old systems I'd definitely choose
| the first one
|
| The first option probably means they are assuming the
| terminal behavior of the common terminal apps desktop users
| on one of the two/three main platforms are using. But if
| they're making that assumption, they might as well assume
| they can use a proper GUI and go with that.
|
| The whole point of terminal programming is that you live
| within the abstraction which is the terminal. The fact that
| you're thinking about _systems_ rather than _terminals_ is
| the problem.
|
| It's perfectly ok to have your app refuse to run on a
| terminal which lacks certain capabilities (annoying, but ok):
| You check for whatever you need from the terminal using
| Terminfo(https://en.wikipedia.org/wiki/Terminfo), and die
| gracefully if necessary. What's not ok is saying "Oh, I'm
| running on Windows, so XYZ must be true about the terminal
| I'm in, I'll just go ahead and assume that's the case".
|
| Also - what you consider "obscure and esoteric systems", for
| many other people is just "systems".
| ttt0 wrote:
| I didn't bother to comment on this, but these are my
| thoughts as well. From briefly looking through the source
| code, it seems like the only way this library cares about
| the capabilities of the terminal is just checking if '256'
| or 'truecolor' is in TERM variable, and that's it.
| jlokier wrote:
| Even terminal programs that just write to stdout depend on the
| OS to some extent.
|
| On Windows, writing to a terminal window has different effects
| depending on the type of terminal. The classic Windows Console
| doesn't understand VT codes but there are API calls to do the
| same things (position cursor, change attributes etc). Recent
| versions of Windows Console can be told to understand VT codes,
| but require an API call to enable VT interpretation, then they
| understand a subset. Windows Terminal isn't the same as Windows
| Console. Then there's running things under Mintty, or Cygwin
| Terminal. Control+C behaves differently under those than under
| the Windows Console. Then there's running things under "winpty"
| in a Cygwin Terminal, which uses a hidden Windows Console and
| translates the resulting character matrix as best it can to
| terminal codes. There are other terminal emulators too.
|
| Linux terminals have a lot of diversity regarding which VT
| codes they interpret, but at least there's a common subset for
| most of them. There's also some variation about codes for
| keypress, such as modifiers with function keys.
|
| If it uses terminfo or termcap to work with various terminals,
| there are some OS dependencies regarding what capabilities are
| likely to be indicated.
|
| The color capability varies. Sending 24-bit color to some
| terminals will not have the desired effect on others.
|
| Unicode support varies among terminals, and this toolkit uses
| plenty of Unicode in the demos: Radio buttons, check boxes, box
| drawing characters, and the bar graph demo. What counts as a
| wide character (two cells) also varies.
| mofosyne wrote:
| I be curious to see if there is a Terminal User Interface that
| can also have a GUI mode as well if opened directly rather than
| in a terminal.
| enriquto wrote:
| what does it mean "opened directly"?
| dllthomas wrote:
| I agree that it's not well defined, but I'd guess that a good
| rule of thumb is "fd 0 isn't isatty, and the process has the
| info (from env vars or arguments) necessary to open
| graphically" with an additional switch for overriding in
| either direction.
| SuperNinKenDo wrote:
| That's how Emacs works, although it uses (your choice of a set
| of) GUI toolkits. Not sure if you mean one single toolkit that
| covers both and looks identical. I guess Emacs would still
| mostly qualify.
| tyingq wrote:
| Those existed for a while when both DOS and Windows were
| popular at the same time. Foxpro was one example.
| agumonkey wrote:
| Maybe we're about to see react like semantics driving multiple
| backends, cli, local gui, html5 webapps..
| vbsteven wrote:
| That is basically what Flutter is. Renders to desktop, mobile
| and web, only tui is missing there.
| agumonkey wrote:
| I thought flutter web uses wasm/canvas and not html am I
| wrong ?
| vbsteven wrote:
| No you are right, but that's irrelevant to my point. The
| point being that Flutter is an example of a "react-like"
| framework to write UI that renders to multiple backends.
| agumonkey wrote:
| not really, it's important to me that we don't flatten
| things into a canvas rendering system, the idea is to
| remap abstract UI structures onto various projections
| (terminal, html, else)
| vbsteven wrote:
| I see. We're talking about different levels of
| abstraction.
|
| There are two approaches there. One is to project
| abstract UI onto platform controls (React Native), the
| other is to use "drawing" (Flutter). Both have their pros
| and cons.
|
| The main drawback of abstracting over controls is that
| each platform works very differently and the abstraction
| quickly starts leaking. Also some of the targets don't
| have any controls like the terminal. All you can do in a
| terminal is draw text in rows and columns.
|
| That is why most (not all) cross platform frameworks
| abstract on the drawing level. Gtk, Qt, Flutter, Druid,
| Dear ImGui and many more.
| amelius wrote:
| It looks incredibly nice, but ... I still think a text UI that
| looks like a GUI is combining the worst of two worlds.
| jbaber wrote:
| As one of the very few ed fans. I must say I love vim too.
| jbaber wrote:
| and mutt
| xixixao wrote:
| Except if you need to run the app on remote server.
|
| VS Code shows how utterly difficult it is to get a GUI working
| well in that scenario.
| pjmlp wrote:
| RDP, XWindows and VNC have worked for quite a few decades
| now.
|
| My first experience with remote XWindows was using IBM X
| Windows terminals in 1994.
| kevin_thibedeau wrote:
| It's nice to be able to configure a kernel without a GUI
| available. TUIs have their place.
| pjmlp wrote:
| Yeah like using Turbo Vision and Clipper based UIs in
| 1992.
| aninteger wrote:
| What scenario are you talking about, or what does VS Code
| have to do with anything?
|
| Did you mean running VS Code on a remote server and
| forwarding it to the local machine? X11 based forwarding?
| zxzax wrote:
| You probably just want to use the Remote SSH extension in
| VS Code. That should work a lot better than X11 forwarding,
| and it should be a lot easier than rewriting the whole GUI
| to use the terminal.
| 0xTJ wrote:
| Have you ever used (h)top? It's great at-a-glance view of
| what's going on, from the command line.
| vbsteven wrote:
| Htop is an example of a good TUI but it doesn't really look
| like a traditional "drawn" GUI.
|
| I think that is the distinction that parent is making.
|
| In a TUI environment (ignoring mouse support) traditional GUI
| elements and layouts often don't make sense. Like one of the
| examples with all the radio buttons in small boxes.
|
| The good TUI apps like htop, newsboat, mutt, vim/emacs, tmux
| all have mostly line-and-column oriented simple layout
| primitives.
| [deleted]
| ZoomZoomZoom wrote:
| What's wrong with radio buttons in a TUI? The "good" htop
| uses checkboxes which is almost the same and works just
| fine.
| zozbot234 wrote:
| You can use the TAB key and spacebar to navigate TUI
| widgets, there's no need for mouse support. TUI layouts can
| definitely be overdone, but they're also useful in many
| cases.
| kzrdude wrote:
| Htop is great. Lately I've been reaching for a way to get an
| overview of process clusters (like firefox or vscodium like
| to make), and I can see there's an open feature request in
| htop for that. Would be a nice thing.
| amelius wrote:
| top is ok, but I'm always confused about the key-
| combinations, and the view is cropped (command line arguments
| etc.), so a scrollbar or some on-hover popup seems needed
| here.
| colesantiago wrote:
| so you're enjoying typing in commands on the terminal
| repetitively can you still can't see what you're doing?
| pjmlp wrote:
| Turbo Vision was quite good.
| drran wrote:
| But it needs better mouse and keyboard support.
|
| https://github.com/magiblot/tvision
| michaelsbradley wrote:
| Say hello to notcurses:
|
| https://github.com/dankamongmen/notcurses
|
| demo: https://youtube.com/watch?v=dcjkezf1ARY
| pjmlp wrote:
| I fail to see the relation to Turbo Vision.
| michaelsbradley wrote:
| Fair.
|
| Notcurses' principal author aspires for it to provide a
| widget toolkit for TUIs[1], but much of the demo and much
| of the commit log to date is heavily focused on graphical
| capabilities and lower-level details.
|
| It may be that one day it ships with a robust widget
| toolkit; or perhaps someone else will build another
| library on top of notcurses with that as the principal
| focus.
|
| I'm also impressed with the effort put into FinalCut[2],
| but notcurses seems to me to be paving a more interesting
| path forward for TUI development.
|
| [1] https://nick-black.com/htp-notcurses.pdf, see e.g.
| page 3
|
| [2] https://github.com/gansm/finalcut
| Hypergraphe wrote:
| Well, I don't think it can be viewed as a text UI since you
| interact with components and don't type commands. I would say
| it is a keyboard based GUI.
| synergy20 wrote:
| Great project. One of its user git-tui looks well comparing to
| another git-cli (tig).
|
| Wish we have some nice cross-platform GUI with modern c++ works
| across linux/windows/macos too, the only choice used to be Qt.
| Nowadays imgui seems a good alternative.
| gooderist wrote:
| Juce is pretty nice. https://juce.com/
| synergy20 wrote:
| That's geared towards music related GUI apps?
| cjaybo wrote:
| It is, but it contains enough general purpose stuff to be
| useful for non-audio stuff as well. I use JUCE at my day
| job FWIW.
| PaulDavisThe1st wrote:
| gtkmm works across all those 3 platforms, and had modern C++
| before Qt did (e.g. actually using templates and libstdc++
| instead of preprocessors and custom "standard" classes).
| synergy20 wrote:
| https://www.msys2.org/docs/what-is-msys2/
|
| Looks like a nice alternative indeed. it uses MSYS2 for
| windows native build.
| winrid wrote:
| Throw nimlang on top and you could have a really productive
| environment.
| mraza007 wrote:
| Looks incredibly good. I love the animated spinners and the
| graphs.
| notorandit wrote:
| Underestimating the power of TUIs annoying it is.
___________________________________________________________________
(page generated 2021-06-05 23:01 UTC)