161–170 of 304 posts
Also wheres the Linux version? You've Mac, windows, and docker. When someone says terminal to me I default to Linux.
Earlier quoted context omitted.
“Modern TUIs may support mouse events” hah! They already did in the 80s…
Yeah, remember good old Norton Commander ( https://en.wikipedia.org/wiki/Norton_Commander ) - not that newfangled clone Midnight Commander, the original? Or the Borland text mode IDEs ( https://ilyabirman.net/meanwhile/all/ui-museum-turbo-pascal-... ), complete with windows, menus, buttons, scroll bars, file dialogs etc. etc.?
This is nonsensical, there is nothing textual about the UIs being shown here. It doesn't stop being a GUI if you have a 1:1 representation of the concept within character cells. The UX actually matters, and TUIs are generally built for effectiveness and power (lazygit being an excellent example). But once you start adding mouse clickable tabs, buttons, checkboxes etc. you left the UX for TUIs behind and applied the U…
Hard disagree. Borland TurboVision [0] was one of the greatest TUI toolkits of the DOS era, had all of these:
> Turbo Vision applications replicate the look and feel of these IDEs, including edit controls, list boxes, check boxes, radio buttons and menus, all of which have built-in mouse support.
Well, I can’t remember if it had tabs.
This is nonsensical, there is nothing textual about the UIs being shown here. It doesn't stop being a GUI if you have a 1:1 representation of the concept within character cells. The UX actually matters, and TUIs are generally built for effectiveness and power (lazygit being an excellent example). But once you start adding mouse clickable tabs, buttons, checkboxes etc. you left the UX for TUIs behind and applied the U…
Earlier quoted context omitted.
It's a TUI if it uses text to build those elements. You can be effective and powerful in any kind of interface, Just like you can be ineffective and weak in any kind of interface. People like TUIs because they're cool, and work over SSH.
Yes. A TUI runs in a text session. A GUI runs in a graphics session. A terminal emulator emulates a text session in a graphics session - and allows you to run TUI/CLI tools. This is apparently controversial?
What do you mean by this? I have never heard these terms before. I can launch and interact with a GUI from a text application, or a text application from a GUI.
Vibe-coded trash, even says so in the Readme. Not sure why this gets voted to the frontpage.
Better get ready for almost all software to use AI assistance in its creation. You can build great things using AI agents, and you can build trash. Your ideological opposition to that is not shared by as wide a percentage of developers as you may think based on some highly self selected online corners.
I too remember running `rails new MyGreatApp` and having hoop dreams of being the next billionaire entrepreneur, but a boilerplate app is a boilerplate app.
Am I the only one who thinks the recent TUI explosion is absolutely not necessary? I mean yes, code editor are great for this but a lot of the TUIs I see are so slow it begs the question why they exist to begin. CLIs are supposed to be remixable and scriptable. I think a better architecture would be to generally keep CLIs work like CLIs and have separate processes that add terminal rendering functionalities for those…
But I wish we'd just make fast GUIs instead of giving up and building TUIs instead.
Earlier quoted context omitted.
The big obvious one is web-based tooling. Your information & settings are stored on a server and you use a web browser to view it via whatever device you're on. For more locally based workflows, we have networked filesystem protocols, automatic syncing between systems, that kind of thing. It's not a 1-1 equivalent of running a remote program and viewing it locally obviously, but it gets the same job done, in a much m…
I don't really feel like web interfaces or syncing are really a substitute tbh, and I'm not sure how they're more flexible. ssh -> run -> gui opens, and the program itself doesn't need to be designed differently to work
But this doesn't work on your phone, or on a Windows or macOS device, right? That's what I meant by flexible, X forwarding fits a pretty narrow set of usecases, while on the other hand keeping programs on the clients and data centrally located on a server allows for a whole lot more options for how to interface with that data.
(To be clear, nothing wrong with X forwarding! It's a cool tech and I'm glad you have a use for it! I'm just arguing that it's fine for Wayland to not try to support that kind of thing, because we've got other ways of working remotely now.)