Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ftxui: C++ Functional Terminal User Interface

github.com

Post reply on HN
Print view View original

51–60 of 72 posts

Re: Ftxui: C++ Functional Terminal User Interface

#51

Post by jcelerier »

einpoklum wrote: post #48

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 mor…

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

Re: Ftxui: C++ Functional Terminal User Interface

#52

Post by jlokier »

einpoklum wrote: post #48

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 mor…

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.

Re: Ftxui: C++ Functional Terminal User Interface

#53

Post by drran »

pjmlp wrote: post #32
amelius wrote: post #4

It looks incredibly nice, but ... I still think a text UI that looks like a GUI is combining the worst of two worlds.

Turbo Vision was quite good.

But it needs better mouse and keyboard support.

https://github.com/magiblot/tvision

Re: Ftxui: C++ Functional Terminal User Interface

#54

Post by einpoklum »

jcelerier wrote: post #51
einpoklum wrote: post #48

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 mor…

> 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 t…

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

Re: Ftxui: C++ Functional Terminal User Interface

#55

Post by vbsteven »

agumonkey wrote: post #26
vbsteven wrote: post #23

Earlier quoted context omitted.

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.

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)

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.

Re: Ftxui: C++ Functional Terminal User Interface

#56

Post by ttt0 »

einpoklum wrote: post #54
jcelerier wrote: post #51

Earlier quoted context omitted.

> 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 t…

> 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 as…

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.

Re: Ftxui: C++ Functional Terminal User Interface

#58

Post by michaelsbradley »

pjmlp wrote: post #50
michaelsbradley wrote: post #46

Earlier quoted context omitted.

Say hello to notcurses: https://github.com/dankamongmen/notcurses demo: https://youtube.com/watch?v=dcjkezf1ARY

I fail to see the relation to Turbo Vision.

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

Re: Ftxui: C++ Functional Terminal User Interface

#59

Post by kragen »

p1131 wrote: post #57

Looking at the source, I think it "renders" and reprints the whole "frame" everytime... In which case it might be bad...

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.
Post reply on HN