--- section: 37 x-masysma-name: why_terminal title: Why would I prefer Terminal programs over GUI date: 2022/07/23 22:30:56 lang: en-US author: ["Linux-Fan, Ma_Sys.ma (Ma_Sys.ma@web.de)"] keywords: ["kb", "opinion", "note"] x-masysma-version: 1.0.0 x-masysma-website: https://masysma.lima-city.de/37/why_terminal.xhtml x-masysma-owned: 1 x-masysma-copyright: | Copyright (c) 2022 Ma_Sys.ma. For further info send an e-mail to Ma_Sys.ma@web.de. --- Introduction ============ I -- like some other people -- prefer applications that run in a Terminal Emulator (e.g. urxvt) over ones that provide a GUI using a GUI toolkit. While it has often been argued that using _commandline_ applications has advantages over graphical user interfaces (GUIs) -- mostly that commands can be scripted -- this does not in the same sense apply to the typical ncurses/mainframe forms of Terminal User Interfaces (TUIs). While I like commandline programs well enough, I also prefer TUIs over GUIs most of the time. Could there be any reason for this beyond _personal taste_? Partial Reasons =============== Some people claim that it is _faster_ to use TUIs. While there are inefficient and slow GUI programs out there, this problem is not inherent to GUIs although probably more prevalent there. _No animations_: TUI programs use very limited animations. Actually, the only non-toy example that I can think of is progress bars and turning wheels where something computes. OTOH, GUI programs often have some more advanced animations. Most of the time it is possible to configure them at the GUI toolkit level hence this should not be the primary reason for chosing TUI over GUI? Some people claim that TUIs allow you to _perform all operations with the keyboard_ which could also be an advantage in speed. However, some GUI programs have customizable keyboard shortcuts, too and hence allow for efficient keyboard usage. Chosing TUIs is an almost surefire way to avoid programs that heavily rely on mouse control. If one works with the keyboard most of the time already, it may pay off to avoid the change between keyboard and mouse. Some GUI (?) people optimize this by using tenkeyless (TKL) keyboards which reduces the distance between mouse and keyboard to allow for faster switching between the two input devices. Going for TUIs is thus not the only way to achieve a more efficient interaction with the computer. Some people claim that _TUIs are available remotely more easily_ compared to GUI programs. I think that for Linux, there is some merit in this argument. While there is X11 forwarding, its performance can be bad in practical unstable link scenarios. Windows' RDP does a much better job at transporting a GUI experience remotely, though. It hence does not seem that remoting would be limited to TUIs. In practice it is sometimes more feasible to install a TUI program on a remote machine than to do the respective GUI equivalent. Think of installing `mc` on a server (one package, a few kibibytes) vs. installing `thunar` on a server (pulls in the entire GTK framework as a dependency and probably indirectly recommends daemons that one would not want to have on a server). Similar considerations hold for leaving a remotely running program open: You could easily deploy a statically-linked `tmux` to the remote system and keep it open there whereas running a VNC server on the remote system is much heavier and could be complex to deploy if administrative privileges are not available on the remote system. My Reasons ========== _No symbols_: TUI programs use symbols in place of text very sparingly whereas for GUI programs it is common to encode large parts of the interface in little icons and other symbols. I find it easier to digest the text over the symbols and thus prefer TUIs. No touch optimization (or IOW: _Efficient screen space usage_): Some modern GUI programs assign overly large parts of the screen space to UI functions leaving less space to the actual data of interest. Given that I do not normally use touch interfaces, I prefer the more cramped visuals of old-style GUI applications (Think: Windows 2000 and before) in the GUI world. The TUIs I have used so far are all touch-unaware and hence do not make the UI elements any bigger than needed. This often results in a more efficient use of screen space. Examples: * My preferred text editor VIM dedicates only two lines of screen space to the UI, the remainder is taken by the file being edited. * My preferred e-mail client `cone` takes four lines of screen space for the TUI which is still far less than the typical GUI mail client or web browser: Firefox, with menu, tabs and URL bar takes six lines of space for these elements. In TUI world, four would possibly enough, e.g. one for the menu, one for the tabs and one for the URL and maybe one as a separator. * My preferred file manager `vifm` uses three lines for its GUI. The lightweight GUI file manager Thunar takes five lines in comparison. Almost _no responsive design_: Modern GUI applications (websites and others) try to be overly clever regarding the screen space usage: They are already aware that GUI can take too much space and hence change the layout with the intention to show an accepatble amount of data even in the presence of smaller window sizes. In practice this leads to important GUI elements becoming hidden behind “hamburger” menus upon window resizes. This effect is especially problematic with tiling window managers because there, very small windows can naturally occur. In TUI applications, the behaviour is often more predictable: If there is too little space, the respective element gets cut. Functionality stays the same which means it remains possible to trigger the element of interest “blindly”. If one is familiar with the TUI, it saves from enlarging the window for just triggering this one function that one knows how to trigger anyways. All programs have limits if the windows get _very_ small, but for GUI programs the problematic point is often reached earlier. _Integration_: Most of my work is console-based anyways. Many TUI programs allow switching between the TUI and console easily. E.g. one can start a `vim` inside any already running console and one can even start a shell inside many TUI programs -- `:sh` in VIM for instance. GUI programs in contrast do not integrate well in this regard. In my GUI times, _Open Terminal Here_ was my most used feature of a GUI file manager. It is worth noting that this option is not available by default in all GUI file managers making them combersome to work with for my use cases. Another aspect of integration is that with Terminal programs, all the visual details like _font family, font size_ and _colors_ are restricted and enforced by the Terminal emulator. All my terminal windows come with 16 (always equal) colors, Terminus and 18 px character height. All my TUI applications run with dark background by default whereas _Dark Mode_ in GUIs is getting some traction but is not universally available yet. Independently of the TUI program that is running this results in a readable interface. In GUI programs, some fonts are always of different size. Notable offenders are tool tips or status lines that sometimes have much smaller fonts compared to the default. This makes them hard to read. If I were to increase the overall size of the GUI scaling this would make some other parts of the GUI unnecessary big. Having _one_ consistent font size for everything like in the TUI works best for me. If something has to be highlighted there is still bold print and colors available. Also, having a limited choice of colors naturally avoids most of the low contrast issues from GUI programs. For TUI programs it is very uncommon to deviate from sane color choices. I have never encountered a TUI so far that had an intentional “gray on white” color scheme whereas this seems to be common on some websites and in some GUI programs. Unlike in the GUI world, where it is common to have multiple “frameworks” (QT, GTK, ...) that one needs to configure separately to achieve consistent visuals, with TUIs it is all dictated by the terminal emulator. If I want to increase the font size, I have to edit exactly one file and _all_ TUIs (even those running remotely!) will pick it up as soon as I start them in a newly opened Terminal Emulator. Conclusion ========== It seems my only convincing argument for TUIs is _Integration_. I conclude that my reason for preferring TUIs is simply that I am using the terminal a lot already so it pays off in various regards to try staing “home” (in the terminal, on the keyboard) as much as possible. I believe that this is not directly leading to “more productivity” or anything of that sorts. From my point of view, it seems to be largely a “better” feeling and hence in the end really _a matter of taste_. YMMV.