If your program use slow internet like tui I cant write tui program. no problem.
Stop Making TUIs
221–230 of 579 posts
Re: Stop Making TUIs
#222Earlier 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. If you're only targeting macOS/Windows/Gnome/KDE then the solution is easy: just grab a GUI control set and go ham. Then there's remote access: you can spawn an X11 app through X forwarding and have a terrible laggy…
> I think the answer to this is probably to throw all that compatibility mess away > TUIs run on any OS with minor patches to support quirks So, which one is it?
Those two are not contradictory statements
Re: Stop Making TUIs
#223Earlier quoted context omitted.
> I think the answer to this is probably to throw all that compatibility mess away > TUIs run on any OS with minor patches to support quirks So, which one is it?
Those two are not contradictory statements
Maybe not, but they do sit on opposite end of an axis looking something like:
TUI that runs on any OS |----------------| TUI without any compatibility mess
Re: Stop Making TUIs
#224No, thanks. I don't want a mere "user" interface, I want a programmer's interface. I don't like the command line because I'm a "unix nerd", I like it because it lets me rapidly cook up little programs and execute them.
Here's an example I just pulled out of my shell history:
c=3afba1a; reset; laptop "virtdev ssh liblinux -- git -C liblinux format-patch -1 ${c} --stdout" | tee /dev/tty | termux-clipboard-set
I didn't need to think to write this, I just wrote it right there in the terminal using the shell's line editor, just because I needed it, and it completely solved my problem. It's as easy as pressing up on keyboard now, and I can easily turn it into a script if needed. Nobody had to bend over backwards to add monstruous features to the apps to accomodate me. I knew what my computer needed to do, and I made it do it.
In my opinion we need more of this, not less. More unix and less iphones.
Re: Stop Making TUIs
#225No. I like them.
What do you like about them? I disagree, but so many people seem to like them that I assume I'm missing something. The main one I've heard before is that they work nicely over SSH, but I assume there must be more?
I also like them so I can mention some things that spring to mind:
- Some are very good tools that have no clear GUI superiors. Vim, Emacs, Mc for example. GUI wrappers over these don't make them better.
- Efficient, meaning fast and limited in scope so you can learn the whole thing.
- The muscle memory you develop is transferable to any new platform or OS you use.
- Often free and OSS so they can't be taken away, making the muscle memory a long-term investment.
- If you work in the terminal for any other reason there's less context switch.
Re: Stop Making TUIs
#226No, thanks. I don't want a mere "user" interface, I want a programmer's interface . I don't like the command line because I'm a "unix nerd", I like it because it lets me rapidly cook up little programs and execute them. Here's an example I just pulled out of my shell history: c=3afba1a; reset; laptop "virtdev ssh liblinux -- git -C liblinux format-patch -1 ${c} --stdout" | tee /dev/tty | termux-clipboard-set This hug…
I agree, authors whole "The time has come to re-evaluate terminal and command line interfaces." is weird, if anything we should be moving MORE towards terminal and command line usage.
Another example from recent history, I just wanted a easy way to mount all connected drives, so whipped up:
lsblk -l | grep -i part | cut -d " " -f 1 | xargs -I{} sudo mount -m /dev/{} /mnt/{} # automount_all
Meanwhile, a shell alias/function just sits there, easy to see what it does, can control anything in your computer, GUI or not (one way or another), lets you build up your own "database" of tools that all compose together (again one way or another) and finally is easy to put under automated testing.
Re: Stop Making TUIs
#227More TUIs, and with eye candies too! :)
Since I wrote my own terminal multiplexer that puts terminals on infinite zoomable canvas [0] and I just can't get enough of putting weird stuff like asciiquarium, cmatrix or tty-clock all around (tried peaclock but it's slightly too fiddly for my taste). There are fun projects just to run in TUIs like astroterm or weathr, but I'd say that the space is still open to terminal toys.
The only problem I have with TUIs is that they're boring after a while but something that can be solved with often theme switching.
[0]: https://race-term.com (commercial)
Re: Stop Making TUIs
#228Earlier quoted context omitted.
What? 99% of my programs I can open more than one window by just executing the program as normal multiple times, the only ones that enforce a kind of singleton execution are things that also acts as a kind of server, one example is Everything search, but it has a "Open new Search window" for multiple windows. And that is the default, you have to explicit code in a lock/global mutex thing to block multiple instances.…
Anything from WhatsApp to the Settings app on macOS where I might want to, say, compare the wifi network settings for two access points. But the point is that the developer has to build the app in a way that lets you do this. Once again, there is no default with the tools I listed. You decide on how you want windowing to work and then build it. At this point, show me examples of needing a mutex to "block" a multi-win…
I don't get it. Let's say you create a game.exe, a windows application with a single window. User double clicks on game.exe icon on their desktop, and the window opens. User double clicks the icon again, and the game window opens again. If the developer want to prevent two instances of game.exe running at once, they need to actively detect and prevent this behaviour.
Just like you can start vim several times you can start gvim several times and have a few windows. This is the default behavior, and if the developer wants to change this for some reason, they need to put in some effort.
Maybe macOS is special? I'm not familiar with this platform.
Re: Stop Making TUIs
#229Earlier quoted context omitted.
Those two are not contradictory statements
Maybe not, but they do sit on opposite end of an axis looking something like: TUI that runs on any OS |----------------| TUI without any compatibility mess You really can't have both at the same time, either you have great compatibility (which will be a mess), or you don't, to varying degree of course.
Basically any OS can install any compliant terminal emulator, meaning the cases in which you really have to patch your TUI for another OS are few and infinitely more manageable than GUIs
Re: Stop Making TUIs
#230Tabs vs spaces. I’ve always appreciated the positive side of TUIs and appreciated less the positive side of GUIs. I didn’t grow up with a computer at all and in one of my first adult jobs I had to use a TUI at Papa John’s for punching in orders, it was 20x faster than anything I used after it at other restaurants that were GUI driven (keyboard speed wins for me, fit my brain perfectly). I think I learned it in 5 minu…
What you're comparing is really "keyboard-driven" via "mouse-drive". A GUI can be keyboard-driven and as fast as a TUI. The sad truth is that the status quo for GUIs is absolutely terrible, and most were rushed out and not properly tested to check if they're really usable without a mouse.
A GUI requires a lot more work to be keyboard-driven and as fast as a TUI.