Application-specific terminals
cweagans.net
cweagans.net
The main complaint was having to dig through terminal tabs to find your vim and not being able to Alt+Tab to it. Surely just detaching that single tab would work just fine? Their solution seems to add a lot of complexity for not much benefit...
There’s a similar problem where some people don’t like to search for email or chat tabs, so they install a “native” (electron) app like teams or slack so that it acts like more than just another browser tab.
What value does this messy method to reimplement GUI bring?
I also like the fact that it's hard to build a terminal application that needs a mouse. I don't want to touch a mouse if I can avoid it, so I run them. A personal computer is too powerful to operate with a single finger.
There's the low resource aspect too. Sure, you can build a TUI that hogs resources, but there's a culture of not doing it, and it's harder to do it even if you try. Contrast that to modern GUI software where it's like the developers look at the minimum requirements as a speed limit, that is, the bare minimum you have to use.
You might've forgotten due to no use, but mice don't use only 1 finger, and they don't prevent keyboard use either.
The comparison to some general GUI state also doesn't make sense - that class of software is miles ahead of the TUI in terms of functionality, so you'd need to limit the comparison to apps that are functionally similar
And sure, having a mouse doesn't preclude you from using a keyboard, but GUI applications are so mouse focused it's impossible to use most of them without a mouse. The 1 finger comment was hyperbole, but it's close enough to true.
I use various buttons and wheels and gestures and click sequences (LR switch tab left, RL switch tab right) and buttons-as-modifiers on a mouse, so not even remotely close
The other point is repeating the same generalization mistake, "most of them" don't even exist in a TUI form, and the level of keyboard customization for keyboard focused interface is often pretty lackluster in a TUI (terminal text editors famous for their customization can't differentiate between left and right modifiers and it's harder to fix that with an external utility because, guess what, it's not a separate app, so usual app detection fails!)
The other nice thing is that when I want to run Neovim, I start an app called Neovim. Not FNvim or Neovide or glrnvim or any of those other things. Neovim. It's a closer match to my intent and I don't have to try to remember some weird app name when I just want to edit code.
Which apps do you use actually it for?
> when I want to run Neovim, I start an app called Neovim
That's what aliases are for (or you could rename the binary?)! Or you could just bind it to shortcut+E for Edit and forget the name of the editor as you'd never type it The last trick could also solve the Cmd+Tab issue as you could set it up to open the in-terminal-editor, and it'll always be faster vs tabbing
P.S.
By the way, do you know the app https://github.com/sveinbjornt/Platypus that can generate app bundles on a Mac?
neovim, mutt, tig, weechat
> That's what aliases are for (or you could rename the binary?)!
Unfortunately, it's not that simple on macOS for app bundles. The human readable name of the app bundle really doesn't matter that much to the operating system -- it's the contents of Info.plist that matter. In order to have a separate app that can be Cmd+Tab'd to, you have to have a separate app bundle, separate app bundle identifier, etc. There's really not a way around it on macOS that I've seen.
(And to be clear, aliases do work on the command line. I'm talking specifically about GUI apps - which is my primary method of separating my different activities. Terminal emulator tabs are not good enough.)
This also doesn't solve the performance problems with any of the various GUI applications, nor does it solve my problem for other applications that I want to run.
> By the way, do you know the app https://github.com/sveinbjornt/Platypus that can generate app bundles on a Mac?
I do! I tried this route first, but it falls apart when you start a GUI application from the script that you supply to platypus. If your script is e.g. `wezterm start`, it'll just start up another instance of a wezterm-branded GUI app in addition to the wrapper app that Platypus spits out.
I meant you could edit the existing bundle for, e.g., FNvim, and change it's bundle id/name/icon to whatever you want instead of having to re-create a bundle for a weztermed neovim (aliases would only work for the launching part)
> but it falls apart when you
That's unfortunate
That doesn't solve it in a generalized way though, which is what I was going for here.
If you want to integrate your TUI program more tightly with the terminal emulator it's running in, how about you rip out those half a dozen layers of abstraction and indirection and compatibility with half-a-century-old hardware that nobody produces anymore, that sit in between your program's display logic and the actual pixels on the screen? You can keep the grid-of-characters display style, but e.g.:
- implement text selection that works in sub-frames
- give your program an icon
- support key combos like Ctrl+Shift+F
- display an inline picture
...all while removing hundreds, probably thousands of lines of code.
GUIs UI conventions never became that powerful, and new GUIs don't even follow most of the useful UI conventions. That's so generalized a problem that the newest GUI toolkits don't even have native support for a lot of the GUI conventions.
That said, yes, without a doubt you can make a GUI that is as usable as a random TUI. You can even make it work well over ssh. And even get shorter code after it's done. You will just have a hard time communicating you did that to people.
Yes, that's unfortunately the status quo. TUI's main saving graces, and the reason why it's actually a popular choice for modern apps, are:
- It works everywhere (once you solve the portability quirks, which are present both at OS level and on each different terminal emulator)
- The API is simple and stupid (paint a character here)
- There's only this many things you can do, so you don't over-engineer your UI
- Accessibility. Screen readers are guaranteed to work (but lack a11y context)
I wish there was a simple and stupid, portable GUI framework that had all of these qualities, without the unnecessary historical baggage. htop or ranger are actually pretty good apps, just wish they weren't chained to an emulator.
The baggage may be unnecessary, but I think the key to the success of TUIs is that the terminal’s interaction mechanism is restrictive. To accomplish this in a similar way in the GUI, I think you need to design a toolkit that intentionally constrains the rendering target and input mechanisms that the GUIs can take advantage of. You might end up with something better, but I think it will be very reminiscent of current terminal emulators.
You could make app launchers with links that run other apps, and even non terminal people would want to use it.
I like to think that software developers are very smart people, and only need a little nudge to steer in the right direction. If all you have is PutRune(x,y,r) and intentionally omit PutPixel(x,y,p), you'll indeed just make a worse terminal emulator.
Any decent UI toolkit focuses on a high-level description of the user interface (that's how you get a11y, basic keyboard navigation, etc almost for free), and only provides the low-level operations as escape hatches. This has to be the default route, even for complex or highly customized interfaces (spreadsheet, DAW, etc).
I think our nudge could be direct support for terminals as a fallback rendering backend. Best of both worlds: you get a well-behaved GUI app, that you can also use over a serial console (with gradual loss of functionality) if things get dire.
I wonder how useful screen readers are in curses-style applications (I don't have any experience with screen readers)? Sure, it can probably read it, but applications like this is essentially just a screenful soup of character blocks. It sounds like it'd make for a very tedious screen reading experience.
High usability is also illustrated by the original post - you can't even switch to a TUI app properly!
A huge part of why I keep my workflow 100% terminal / TUI is because I know I can use anything with a solid shell (even my iPad or my phone) and instantly have my full workflow exactly where I left off with every single program looking and working exactly the same in exactly the same state.
Of course, so does a web app with port forwarding, or ssh -X with a bit of a bandwidth hit.
Keyboard centricity, and the decreased usage latency that follows.
Also terminals vary significantly in input latency (though you might mean something else with "usage" latency), some higher than those of a GUI app https://www.lkhrs.com/blog/2022/07/terminal-latency/
That's quite fortunate/fortuiutous and makes for a nifty shortcut that works so well. Is this common for all terminals, eg does gnome-terminal have a --class that would let it slot in to this .desktop setup?
Tbh the Mac version looks a bit too involved and hinges on or works around specific behaviors, I'm not sure I'd want to go that far as it then ventures into the territory of 'maintenance'.
I use X window classes to differentiate between all of my Firefox instances. No idea if Wayland even supports the idea of window classes (so that I can raise the instance I need with a single hotkey), but if not that’s yet another blocker for me.
https://github.com/fmoralesc/neovim-gnome-terminal-wrapper also exists if you want to go that route. I tried it for a little while and it worked pretty well, but it's not particularly easy to re-use for other applications.
The mac version is a bit of a pain to set up the first time, but it's pretty straightforward after that!
Imagine having to use a different browser just so that your OS allows you to switch with a shortcut...
Op should just invest in setting up a little workspace with a hotkey. I'm sure the same is possible on windows or mac as well.
I used to gvim but realized that I was getting almost no benefit (and occasionally the differences between gvim and my terminal caused minor annoyances).
Two things I do that help in this regard:
I use a tweaked config for the "editor" instance of the terminal that has a slightly different background color from my main terminal. This keeps them separate in my mind.
I use dedicated shortcuts for focusing each application I use (browser, terminal, slack, etc) and the "editor" terminal has its own shortcut. (The --class flag that the post mentions kitty has would be pretty helpful in this regard. My terminal doesn't have that so my shortcuts are based on title, which works well enough most of the time.)
The modern 2023 guide would be discussing how to spawn PWA/webapp windows and integrate them like Android and ChromeOS.
The next version of Safari has the idea of installable web apps on macOS. Chrome has had that functionality available for years. There are also a number of third party apps for macOS that handle creating app bundles that essentially just run web views (e.g. Fluid, Bulldock Browser, etc).
((mod4Mask, xK_p), raiseNextMaybe (spawn "urxvt -name htop -e htop") (className =? "URxvt" >> title =? "htop"))
But if you really need alt-tab, I can see why this won't work (unless you manage to integrate tmux windows into your window manager).