371–380 of 443 posts
CLI. Wtf is a TUI? LLMs say it has some to do with interactivity in a menu or something, but believe me, we had this all in the 80’s. Nothing new here, but the truth is the CLI is better faster and cheaper. Pick all three.
Earlier quoted context omitted.
> cross platform That's one word that should never been used in an design meeting. None of the GUI I've used has managed to do this right. Even Emacs and Firefox. The platform are totally different (and in the case of Linux/Unix, there's a lot of different HIG competing). So trying to be cross platform is a good illustration of the lesson in https://xkcd.com/927/ The best bet should be a core with the domain with a U…
> The best bet should be a core with the domain with a UI shell. And then you swap the shell according to the platform. I've rarely seen that turn out very well. Typically it works ok on whatever desktop main developers use, and not so much on the others. That means using multiple frameworks, witht their own idioms and quirks and having to repeat a lot of work. Unless your UI is very simple it is pretty expensive to…
Yes. It’s more work than dumping Electron on users. Quality often is.
For the record: I have a terminal open at all times, my life is automated trough Bash scripts and I am a VIM / TMUX user. With that background, most TUIs are really two steps back compared to a decent GUI. (Wild west navigation/hotekeys, broken copy and paste, lack of integration with the environment, just to name a few.) The core of the problem is IMHO, that we really lack a decent cross platform GUI platform, which…
> which is really integrated into a programming language or part of the standard library. Not a programming language, but the programming language: C. The toolkit needs to be available as a C API because that lets it a) provide stable API and ABI and b) provide bindings for multiple other languages without having to jump through hoops, especially for other compiled languages (binding Qt to Python might be easy, but b…
I like, that you also added backwards compatibility and ABI stability, two very important and valid points. There is to this day the joke, that the best way to write a binary GUI app for Linux is to target the Win32 API and run it via Wine, if you care for a stable platform. ;-)
For the record: I have a terminal open at all times, my life is automated trough Bash scripts and I am a VIM / TMUX user. With that background, most TUIs are really two steps back compared to a decent GUI. (Wild west navigation/hotekeys, broken copy and paste, lack of integration with the environment, just to name a few.) The core of the problem is IMHO, that we really lack a decent cross platform GUI platform, which…
I think you are right and completely agree with most of your points. > wxWidgets (seems that the community is very small and especially its bindings needed to be resurrected at least once) Which is a damn shame because they are very close to native appearances on both macOS and Windows and are much easier to program than anything Qt. I think it’s the solution I prefer for multi platform GUIs, both as a user and as an…
I also agree, wxWidgets is quite great, although I have to also agree with the comment above, that C++ for a GUI library is just a PITA when used from any other language. AFAIK the consumers from wxWidget (wxPython, wxErlang?, ...) are using a C wrapper around the C++ wrapper to use it.
I think it's the smoldering ruins of the OS vendor self interest collapsing in on itself. There's not a single good universal UI. The best is the browser and it is reasonably successful but the sandbox makes it specifically unsuitable / high friction for doing things that need local access to files, network, etc. And it is ridiculously high overhead if you just want to run something simple. Then remote access is even…
* Are simple to grasp for uses * Efficient to use (not just resource wise) * Look nice on nice terminals
Notcurses (C++) and Ratatui (Rust) did help ncurses (C) a lot.
Earlier quoted context omitted.
It's about the ascii code and terminal code. (Almost?) Every non-printing character can be entered with Ctrl+ . With Control pressed, D is eot (end of transmission), G is bell, H is backspace, I is line feed (next line), L is form feed (new page), M is carriage return (start of line), Z is substitute, and [ is escape.
I is tab ('\x09' or '\t') and J is new line ('\x0a' or '\n'). These Ctrl combinations follow a predictable linear mapping to the control character section of the ASCII table. Basically Ctrl subtracts 0x40, so I is 0x49, Ctrl I is 0x09.
(28 year emacs user)
The current implementation isn't command-line, but a re-implemented GUI in disguise, awkward and even more buggy. Why should I use that over a GUI? I would prefer Electron over those TUI unless I have to SSH.
I think if you look purely at the numbers, the real reason TUIs are popular is claude code, everything else is background noise compared to it. What originally got me excited to build TUIs was the concept of delivering apps over the wire via SSH. SSH apps resemble a browser in that way: no local installs required. It's a major reason why I enjoy hacking on https://pico.sh -- deploying the TUI requires zero user invol…
I don't think that's true, because it appears to me that the upswing in new TUI programs predates Claude Code's takeoff.
> The hardcore, moved to vim or emacs, trading immediate feedback and higher usability for the steepest learning curve I’ve seen The only hard part about vim is to be forced to strecth the finger up to Escape for what is essentially the most essential function in a modal editor: Going back to command mode. The ideal workflow is do a quick edit and go back to command ("normal") mode instantly. The fact that Escape is…
> I don't see where the learning curve is Right here: > modal editor