491–500 of 580 posts
Earlier quoted context omitted.
Or for those coding in Python there's Textual: https://textual.textualize.io/ Or for Go coders there's BubbleTea: https://github.com/charmbracelet/bubbletea Why? Because TUI!
> Textual Please, don't. One of the main benefits of TUI is being able to freely copy text, I hate opening Textual application and being dropped into this canvas like state.
Earlier quoted context omitted.
A lot of us do the vast majority of our non-browser work on remote systems. GUIs are objectively bad for this
That's an indictment of ssh workflows not GUIs. RDP works fine but it's based on a full desktop experience. Despite having the technology, we don't have the ability to remote in and run a single graphical program in a single window with the same ease. We need something as seamless as Parallels for remote remote apps. But I guess we just settled on web apps.
Earlier quoted context omitted.
Not if you just stick to the basic built-in 30-year-old HTML GUI elements ( , , , , , for layout, etc., maybe also some modern standards like flexboxes) which are very fast, lightweight, east to code, and uniform. The problem to me is every website tries to do some custom javascript monstrosity with their own graphics to keep up with the latest fad. When just sticking to the basics, I find the web is a great cross-pl…
Sure. Except that nobody ever does just stick to those elements.
Earlier quoted context omitted.
The approach you're describing (redesign the protocol) is one path. Another is to sidestep the protocol entirely by using a platform that already owns its rendering surface and happens to run in a terminal: my preference is Neovim. Let me get the caveats out of the way first: this only makes sense if you already live in Neovim. The whole ergonomic case is muscle memory you already have. If you're not a Neovim user, y…
I have built a pretty full version of that idea in rust (codex tui2). There's a while tonne of downsides that make it basically impossible to really get to 100% good on this. > Under the hood it's still a terminal app, but from the UI author's perspective you're not fighting terminfo, CSI sequences, or varying terminal support. You get proper cursor tracking, scroll regions, and editable text areas out of the box. Al…
Earlier quoted context omitted.
GUI programs can also use the keyboard.
A lot of us do the vast majority of our non-browser work on remote systems. GUIs are objectively bad for this
VSCode SSH extension is one of the most widely developer-used proof against this. Windows' RDP is the other one where many engineers and POS personnel have experince using them. Many electrical and mechanical engineers still use Windows RDP at my work to run simulations. The connection is responsive enough to survive their home-to-office VPN connection. I set up complex chemical simulation software that is accessed by clients of a HPC cluster over 1000s of kms away.
VScode has a really efficient protocol that communicates only that's required, Windows RDP can declaratively send UI component changes as long as one uses Win32 or WPF. It can also reasonably compress the data to even survive dial-up levels of bad data.
We use multi-attendant video conferencing day to day with whiteboarding extensions. If there is will, efficient and amazing remote-GUIs are easy.
Earlier quoted context omitted.
> TUIs run on any OS with minor patches to support quirks, GUI frameworks need a lot of work. TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform. Have you tried to write a GUI program lately? I suspect things may have changed. I can write one using Qt, EGUI, etc (Or many other options), and it will just work on Windows, Mac, Linux/Wayland, and Linux/X. Basi…
they wont work on android though. thats the main reason i started using more TUIs myself. i needed to be able to run a bunch of python scripts on linux, windows and android/termux. or if any of the linux phones ever matures, or sailfish, then the same scripts will run thereas well, probably without any modifications needed
Mobile has significant paradigm changes that makes using both terminals and traditional GUIs harder anyway though. I do expect the need for completely different cross-platform libraries for mobile UIs.
Earlier quoted context omitted.
It's a fine point if made in isolation, but TUIs tend to be more technical and useful simply because they require using a terminal at all. GUIs tend to be made for the non-technical iPhone audience. So while I'm not fundamentally opposed to graphics, I'm absolutely opposed to the "average user" culture surrounding it. I don't care about the "normal person", I don't want "user experiences" that hide the computer, I wa…
> GUIs tend to be made for the non-technical iPhone audience. Except for, you know, every serious professional application ever.
I was visiting a radio test lab in last February for our new product. They use a professional software which was written in WPF. The assistant there was flying with the keyboard shortcuts.
I recommend every self-describing Unix or terminal fan to watch videos of photo or video editors / VFX people on YouTube. They are hella fast.
Earlier quoted context omitted.
I was suggesting something that could be done without changing the protocol itself. From what I undestand, the terminal is essentially a concatenative text buffer extended with control commands allowing you to move the cursor (pen) to draw more sophisticated stuff, and update UIs. The logical way to extend this would be to allow genericdrawing commands over the protocol, at which point the whole thing starts sounding…
The problem succinctly is when the terminal emulator only sees cell values and instructions it can't do anything more with things. Two really good examples are implementing accessibility well, and scrolling / changing things above the terminal pane without rewriting the whole history.
Not sure how you're planning on doing that, can you incrementally extend the current model, or will it require a completely new protocol?