61–70 of 72 posts
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.
Not modern c++ last time I checked but active development for sure.
Overuse of shared_ptr (what we call "Java Disease") is probably forgiveable in a UI toolkit. Even protected data members, often frowned upon in O-O circles, are probably OK, here. A note to the author (and, you know, everybody): the "#ifndef xxxx/#define xxxx" two-step is no longer necessary or useful; "#pragma once" is supported everywhere now.
Can I just say that the Ftxui source code is beautifully laid out, and is much more readable than I am used to seeing in Free Software projects? This library has absolutely exemplary presentation. [Edit: I see it uses clang-format. More projects should use that.] Overuse of shared_ptr (what we call "Java Disease") is probably forgiveable in a UI toolkit. Even protected data members, often frowned upon in O-O circles,…
https://stackoverflow.com/a/34884735
> (Historical note: The only reason I didn't rip #pragma once and #import out of GCC when I had the authority to do so, ~12 years ago, was Apple's system headers relying on them. In retrospect, that shouldn't have stopped me.)
Can I just say that the Ftxui source code is beautifully laid out, and is much more readable than I am used to seeing in Free Software projects? This library has absolutely exemplary presentation. [Edit: I see it uses clang-format. More projects should use that.] Overuse of shared_ptr (what we call "Java Disease") is probably forgiveable in a UI toolkit. Even protected data members, often frowned upon in O-O circles,…
I am terrified by #pragma once due to issues with relative include paths sometimes being mixed with absolute ones in various situations (none of which I personally cause). I recommend reading this post on StackOverflow by a GCC/autoconf maintainer on why he believes it is actually impossible to make it work correctly. I imagine it is thereby not in the standard, despite being widely implemented, "for good reason". ht…
I find the argument unpersuasive for the same reasons commenters there did. The case for C++ is stronger because the set of current C++ compilers (which nowadays have integrated pre-processor) is much smaller than of C compilers that could be encountered in the wild.
Doing complicated things with header files and paths is inherently fragile, pragma or no pragma. So, don't do them. Absent fragile header file or include-path games, there is no problem.
In the foreseeable future, #include will begin to fade from C++ code, and with it #pragma once, include guards, and any sort of worries about them. (Then we might start to worry about module name collisions, instead.)
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 really fundamentally disagree that there is a "whole point" to terminals (or any other kind of things we use when we use computers). They are just tools which are able to perform things and one should really not ascribe any kind of semantic layer to them, as this is always a very very brittle abstraction. Just look at things in terms of what they are able to do, not what they are called.
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 t…
Every terminal compatible with the main subset of the various VT specifications should be compatible with FTXUI. If someone can prove this wrong, I must fix this ;-)
I own a Linux machine so this is the "main" target. Support is quite strong. However, I don't own a Windows machine and it's quite painful for me to test on it. Windows support has been added by contributors mostly. That's the reason I say it is still "experimental". The various Windows terminal requires some Windows specific calls to enable VT interpretation, as explained above.
FTXUI can be compiled toward WebAssembly and executed against xterm.js terminal. This proves you can use FTXUI against a compliant terminal and not really depends on OS calls. https://arthursonzogni.com/FTXUI/examples/
There are some function depending on the systems:
- Windows diverges a bit (see above)
- Getting terminal dimensions.
- Getting terminal support for colors.
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/...
Mouse support was introduced only 30 days ago: https://github.com/ArthurSonzogni/FTXUI/pull/85 The combinaison of:
- The "frame" element - allowing you to draw inside a virtual area potentially larger than the real one.
- The "select"/"focus" element - to scroll the content of the "frame" toward the selected element.
- The "Menu" component.
isn't currently working satisfyingly. I should work on this.
Looking at the source, I think it "renders" and reprints the whole "frame" everytime... In which case it might be bad...
Yes, that's correct. The whole frame is printed. As said above, as long as you are careful about flickering, this is fine.
This runs very smoothly. So I would say "premature optimization is the root of all evil" for now.
Note that in case of many events sent in a row, we don't render a new frame after every events. We first empty the list of pending events and only render once when it is empty. This ensure there are no lags.
If there is a need, this can be added easily. We just need to ensure this doesn't regress performance. Sending a single chunk representing the whole frame can sometimes be cheaper than sending several diffs at various locations of the screen.
Also, FTXUI support not only rendering to the alternate buffer (fullscreen mode), but it can also render inline. In case of terminal window resize, printing the whole frame avoids garbages to remain, which is nice.
Earlier quoted context omitted.
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 li…
Earlier quoted context omitted.
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 t…
Author of FTXUI here. Thanks for this answer! This is exactly the right reasons. Every terminal compatible with the main subset of the various VT specifications should be compatible with FTXUI. If someone can prove this wrong, I must fix this ;-) I own a Linux machine so this is the "main" target. Support is quite strong. However, I don't own a Windows machine and it's quite painful for me to test on it. Windows supp…
Second, I suggest you get in contact with Thomas E. Dickey, the maintainer of libncurses and terminfo, to see how he tests that library - on something like 15 different platforms.
Finally, over time, consider relaxing your set of terminal requirements - either with workarounds or with limitation of functionality for less-capable terminals.