[HN Gopher] Application-specific terminals
       ___________________________________________________________________
        
       Application-specific terminals
        
       Author : cweagans
       Score  : 44 points
       Date   : 2023-09-19 16:15 UTC (1 days ago)
        
 (HTM) web link (www.cweagans.net)
 (TXT) w3m dump (www.cweagans.net)
        
       | neilv wrote:
       | My `xmonad.hs` has key bindings like this, to switch to a window
       | with a particular program running in it, or start the program if
       | it isn't running:
       | 
       | ((mod4Mask, xK_p), raiseNextMaybe (spawn "urxvt -name htop -e
       | htop") (className =? "URxvt" >> title =? "htop"))
        
       | Pingk wrote:
       | I feel like I'm misunderstanding something?
       | 
       | 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...
        
         | [deleted]
        
       | the_gipsy wrote:
       | Just use a window manager that offers something better than alt-
       | tab. This works for any window type, e.g. specific browser
       | windows etc.
       | 
       | Imagine having to use a different browser just so that your OS
       | allows you to switch with a shortcut...
        
       | politelemon wrote:
       | > Kitty also had a command line flag to allow setting the window
       | class
       | 
       | 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'.
        
         | cweagans wrote:
         | Most of the terminals that I've looked at have a `--class` flag
         | (gnome-terminal, wezterm, alacritty, and kitty all have it).
         | 
         | 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!
        
         | friend_and_foe wrote:
         | Well if you want to do this with a terminal that doesn't you
         | can just use a pipe.
        
           | padthai wrote:
           | Would you mind to elaborate? It is the first time I hear a
           | pipe can be used for setting the class/title.
        
         | eadmund wrote:
         | A lot of older X11 apps support -class for this.
         | 
         | 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.
        
       | sigmonsays wrote:
       | desktop linux user here, I use i3. A tiling window manager allows
       | me to always have my terminal on the right workspace that's 1 key
       | away.
       | 
       | 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.
        
       | eviks wrote:
       | > Third-party GUIs can be nice, but they generally provide very
       | little value over a TUI
       | 
       | What value does this messy method to reimplement GUI bring?
        
         | xorcist wrote:
         | Are you looking for an honest answer?
         | 
         | Keyboard centricity, and the decreased usage latency that
         | follows.
        
         | friend_and_foe wrote:
         | You can run them remotely over SSH, for one.
         | 
         | 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.
        
           | eviks wrote:
           | >A personal computer is too powerful to operate with a single
           | finger.
           | 
           | 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
        
         | rollcat wrote:
         | I've said it before and I will say it every chance I get: TUIs
         | are poorly disguised GUIs, and the whole premise of TFA seems
         | to be here to support this notion.
         | 
         | 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.
        
           | marcosdumay wrote:
           | TUIs have conventions that grant them high usability and
           | accessibility.
           | 
           | 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.
        
             | rollcat wrote:
             | > 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.
             | 
             | 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.
        
         | cweagans wrote:
         | If I was only running neovim, this wouldn't make much sense.
         | However, I can use this method for _any_ command line
         | application. Since it 's essentially just re-using my existing
         | terminal, I can also re-use as much of my terminal emulator
         | configuration as I'd like. I can also rely on the known
         | performance characteristics of my terminal emulator. In
         | particular, a number of the Neovim GUIs are energy hogs (either
         | due to some unoptimized thing that uses a lot of CPU or the
         | specific method that is used for rendering on the GPU).
         | 
         | 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.
        
           | eviks wrote:
           | > I can use this method for any command line application
           | 
           | 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?
        
             | cweagans wrote:
             | > Which apps do you use actually it for?
             | 
             | 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.
        
               | eviks wrote:
               | > 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.
               | 
               | 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
        
               | cweagans wrote:
               | I suppose you could do that (though I'm not sure if
               | Info.plist is included in code signing or not -- that
               | might have an impact for signed apps).
               | 
               | That doesn't solve it in a generalized way though, which
               | is what I was going for here.
        
               | eviks wrote:
               | it's not signed (yet?), edited a few apps without them
               | complaining
        
       | PappGaborSandor wrote:
       | [dead]
        
       | BaculumMeumEst wrote:
       | Why do we keep doing this shit to ourselves?
        
       | Steltek wrote:
       | I went through a phase like this a long time ago. Mobile kills
       | the entire idea. Sure, you can get Termux or an ssh client going
       | but then what? It's not like Mutt has a hidden touch friendly
       | interface implemented through vt100 codes.
       | 
       | The modern 2023 guide would be discussing how to spawn PWA/webapp
       | windows and integrate them like Android and ChromeOS.
        
         | cweagans wrote:
         | I'm not sure why mobile kills this idea or why it even matters.
         | I'm not going to be running neovim or mutt on my mobile device
         | because I don't often use a mobile device to write a
         | substantial amount of code or do anything beyond surface-level
         | email triage.
         | 
         | 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).
        
       | cespare wrote:
       | I've done this for a few years as well. I use a terminal+tmux for
       | most work including quickly editing files here and there but for
       | some reason when I get to "proper" focus-mode programming my
       | brain just wants a separate "application" to look at. And usually
       | the terminal is on my secondary monitor while the "editor"
       | terminal is full-screen on the main monitor.
       | 
       | 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.)
        
       | panki27 wrote:
       | Or use a terminal multiplexer like tmux instead of "terminal
       | tabs". Never leave the terminal, except for the browser.
        
         | cweagans wrote:
         | My terminal emulator has tabs and splits and saved sessions
         | already. That doesn't really solve the problem though. I want
         | something that I can cmd+tab to and not dig through a pile of
         | tabs.
        
           | panki27 wrote:
           | I auto rename the tab to the program that is running
           | currently. So visually scan the window list for vim, then hit
           | the prefix followed by the number of the window.
           | 
           | 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).
        
       ___________________________________________________________________
       (page generated 2023-09-20 23:01 UTC)