4 ms·

The thing is, if you draw boxes in a terminal, you are targeting users that don't care too much about graphical user experience ie. users who feel comfortable a

The thing is, if you draw boxes in a terminal, you are targeting users that don't care too much about graphical user experience ie. users who feel comfortable and happy with a CLI interface. Users who care about colour bleeding don't even try such things in a terminal.

PeterWhittaker 4y ago
Alternatively, you need a controlled interface that constrains what users can do and provides responsive, comprehensive validation, but you cannot use a GUI because of the excessive attack surface. It is easier to code a relatively more secure constrained TUI login shell with ncurses than with a full GUI library.
- nuancebydefault 4y ago
  Thanks for introducing the term TUI to me, it appears to be applied more commonly than I thought. I'm at HN to interact and learn.
- woojoo666 4y ago
  What's the excessive attack surface on a GUI?
  - PeterWhittaker 4y ago
    All of the supporting libraries and services, e.g., DBUS. TUIs tend to have much simpler library dependencies and far fewer system dependencies.
    - worthless-trash 4y ago
      No cross site scripting. No CORS.
ale42 4y ago
I would say this is not completely true. I spend a lot of time using CLI applications, but I _do_ care about how the terminal contents look!
- nuancebydefault 4y ago
  Would you care about the colour bleeding, that was solved by using other characters?
  - JulianWasTaken 4y ago
    You're implying (or assuming) that users who use terminals don't care about visual perfection or design or something. I'm not sure what makes you think that way, I certainly answer "yes" to your question about whether bleeding would bother me. We care about visual warts just as much as in other environments :)
    - nuancebydefault 4y ago
      Maybe I'm seeing it too much black and white -- CLIs vs GUIs, while there are intermediates like TUIs. Why I think that way... I always had the feeling that people opting for CLI alternatives more look at the formal content, less so the way it is presented.
      - altairprime 4y ago
        I prefer terminals because I can express my commands clearly through them. I prefer polished UIs because they help sharpen my focus away from their flaws and into my work. I prefer command line tools with polished UIs. I enjoy color highlighting. I run my editor in 256color mode. I wish a restricted set of CSS was available through libncurses via ESC[ commands, with optional downgrade via term cap to Unicode characters like these one-eighth ones, so that we didn’t all have to suffer quite so much “UI is optional” default neglect from command line tool designs. (One that includes features for terminals newer than decades ago! Like tables, and borders :)
  - 4y ago
ironmagma 4y ago
There’s definitely a set of cases in which CLI users would care about this sort of thing. For example, if you’re using Vim or another editor and want to maximize usable screen space.
saghm 4y ago
Doesn't this also imply that if the CLI experience were able to be improved graphically enough, people who care about that sort of thing would be more open to using it?
- nuancebydefault 4y ago
  Yes maybe, but would that solve any problem?
  - saghm 4y ago
    If someone wants to design apps for people and prefers writing CLIs, having a wider potential set of users is helpful to them. For a maybe unrealistic example, a lot of people complain about the proliferation of Electron as a solution for cross-platform GUIs due to the resources it requires, but developers still use it because it makes their job easier. Maybe putting more effort into GUI frameworks that don't use so much memory is one way to mitigate this?
    - nuancebydefault 4y ago
      It is very difficult for me to get in sync to this line of thought. CLI's are to hard to interact with, GUIs consume too many resources, so let's go back 30 years in time and use TUIs and improve them by e.g. other unicode chars? Why not just use a simple GUI framework instead, tkinter enters my mind?
    - wruza 4y ago
      I don’t think so. Electron is only useful because it is basically a browser plus some local features, so your gui code stays mostly isomorphic. If you step away from it, you lose this benefit. Many existing desktop gui libraries are already memory-friendly and in abundance, no effort required. In theory, one could use a special protocol to support some gui library in it “natively” rather than at html-like level. If interested, take a look at gtk-server for example (not as a library example, it doesn’t fit here, but as an idea/inspiration).
vidarh 4y ago
I literally just posted an image from my terminal based editor where I very much cared about this: https://imgur.com/a/LudA5nY https://imgur.com/a/LudA5nY
- JasonFruit 4y ago
  I don't get what problem that image shows. (I'm design-blind.)
  - vidarh 4y ago
    It doesn't show a problem. It shows using the technique in the linked article to get a border without the background colour showing on both sides of the line.
    - nuancebydefault 4y ago
      Could you please share more of your editor? Is it for personal usage only?
      - vidarh 4y ago
        The github repo [1] is wildly out of date, and it probably won't even run on other peoples systems at the moment as one of my experiments with it is to keep the editor itself as tiny as possible and leverage other tools for as much as possible. As such, it relies on bspwm for multi-window support, and on rofi for file-selection, theme selection etc., and helper scripts not in the repo. It's currently smaller than my Emacs config used to be... More so than the editor, which I'm kinda treating as my config more than a finished app, I'm gradually splitting functionality into a bunch of gems so that the editor itself will feel even more like just configuration... Here's another screenshot [2] showing part of the integration with Rouge for syntax-highlighting, and showing how it's rendering comments by recursing into Rouge's Markdown mode, which again recurses into Rouge's Ruby mode. The "LayeredLexer" class it shows is used to enable that. EDIT: It's my main editor, by the way, and it persists open buffers, and shares them between the user interfaces using Drb. Currently I have 1969 buffers open... [1] https://github.com/vidarh/re https://github.com/vidarh/re [2] https://imgur.com/a/1mTLAPs https://imgur.com/a/1mTLAPs
xani_ 4y ago
Eh, not really. Main advantage of terminal stuff is near-zero dependency and working over SSH, if in addition to that it's pretty (in "more readable" way), why not ? Web UI in comparison is always sluggish, usually required extra login method (instead of just sshing into client, or having CLI client with credentials saved) and in modern days require hundreds of megabytes of deps to even make the JS to run it
- wruza 4y ago
  Iirc you can ssh-forward a port to a remote localhost-only web server and visit local http://localhost:port http://localhost:port to use it. Something like `ssh -forward 2345:2345 -exec “http-server -p 2345 /path/to/mysite” myhost`, but with real options instead of my pseudo ssh cli. Don’t get me wrong, I’m not fond of the modern web either, but setting up something like a chat-like shell in a browser-over-ssh sounds like a pretty straightforward and lightweight job. Edit: correct args would be ssh -L 2345:server:2345 user@server '/home/user/bin/my-web-shell -p 2345'
  - FullyFunctional 4y ago
    That totally breaks the flow. I often spends hours working remotely over ssh+tmux, running Emacs, htop, etc. in a full-screen terminal. Having to suddenly switch to a Browser just to interact with a pretty UI is a terrible flow-breaking trade-off. (OT: and anytime I have to bring up a browser I for "some reason" end up distracted from what I was doing.) I do wish terminal graphics support was a little better. A terminal (like iTerm 2 [0]) that supports inline graphics allows your terminal to display plot etc in a graphical form without having to exit it. In MGR [1] this was the _only_ way to display graphics, even interactive, and I think it had a lot of merit. [0] https://iterm2.com/documentation-images.html https://iterm2.com/documentation-images.html [1] https://en.wikipedia.org/wiki/ManaGeR https://en.wikipedia.org/wiki/ManaGeR
    - zokier 4y ago
      I wish there was builtin support for webapps that was at least as integrated as X forwarding is on ssh. Basically what I'm imagining is some standardized way of tunneling http in unix sockets, and then ssh setting up the sockets and some env var. Then when application connects to the socket ssh client would open new browser window similar to PWA. There are many flaws with such approach, webapps being often crappy being of course one of them. But the redeeming factor is that practically all the tech already exists, this would need just minimal glue to make it reality, while many other approaches are more of a pipe dream.
russellendicott 4y ago
I spent a few months trying to build a TUI client server UI framework targeting such users. http://uggly.bytester.net http://uggly.bytester.net

PeterWhittaker 4y ago

Alternatively, you need a controlled interface that constrains what users can do and provides responsive, comprehensive validation, but you cannot use a GUI because of the excessive attack surface. It is easier to code a relatively more secure constrained TUI login shell with ncurses than with a full GUI library.

nuancebydefault 4y ago
Thanks for introducing the term TUI to me, it appears to be applied more commonly than I thought. I'm at HN to interact and learn.
woojoo666 4y ago
What's the excessive attack surface on a GUI?
- PeterWhittaker 4y ago
  All of the supporting libraries and services, e.g., DBUS. TUIs tend to have much simpler library dependencies and far fewer system dependencies.
  - worthless-trash 4y ago
    No cross site scripting. No CORS.

ale42 4y ago

I would say this is not completely true. I spend a lot of time using CLI applications, but I _do_ care about how the terminal contents look!

nuancebydefault 4y ago
Would you care about the colour bleeding, that was solved by using other characters?
- JulianWasTaken 4y ago
  You're implying (or assuming) that users who use terminals don't care about visual perfection or design or something. I'm not sure what makes you think that way, I certainly answer "yes" to your question about whether bleeding would bother me. We care about visual warts just as much as in other environments :)
  - nuancebydefault 4y ago
    Maybe I'm seeing it too much black and white -- CLIs vs GUIs, while there are intermediates like TUIs. Why I think that way... I always had the feeling that people opting for CLI alternatives more look at the formal content, less so the way it is presented.
    - altairprime 4y ago
      I prefer terminals because I can express my commands clearly through them. I prefer polished UIs because they help sharpen my focus away from their flaws and into my work. I prefer command line tools with polished UIs. I enjoy color highlighting. I run my editor in 256color mode. I wish a restricted set of CSS was available through libncurses via ESC[ commands, with optional downgrade via term cap to Unicode characters like these one-eighth ones, so that we didn’t all have to suffer quite so much “UI is optional” default neglect from command line tool designs. (One that includes features for terminals newer than decades ago! Like tables, and borders :)
- 4y ago

ironmagma 4y ago

There’s definitely a set of cases in which CLI users would care about this sort of thing. For example, if you’re using Vim or another editor and want to maximize usable screen space.

saghm 4y ago

Doesn't this also imply that if the CLI experience were able to be improved graphically enough, people who care about that sort of thing would be more open to using it?

nuancebydefault 4y ago
Yes maybe, but would that solve any problem?
- saghm 4y ago
  If someone wants to design apps for people and prefers writing CLIs, having a wider potential set of users is helpful to them. For a maybe unrealistic example, a lot of people complain about the proliferation of Electron as a solution for cross-platform GUIs due to the resources it requires, but developers still use it because it makes their job easier. Maybe putting more effort into GUI frameworks that don't use so much memory is one way to mitigate this?
  - nuancebydefault 4y ago
    It is very difficult for me to get in sync to this line of thought. CLI's are to hard to interact with, GUIs consume too many resources, so let's go back 30 years in time and use TUIs and improve them by e.g. other unicode chars? Why not just use a simple GUI framework instead, tkinter enters my mind?
  - wruza 4y ago
    I don’t think so. Electron is only useful because it is basically a browser plus some local features, so your gui code stays mostly isomorphic. If you step away from it, you lose this benefit. Many existing desktop gui libraries are already memory-friendly and in abundance, no effort required. In theory, one could use a special protocol to support some gui library in it “natively” rather than at html-like level. If interested, take a look at gtk-server for example (not as a library example, it doesn’t fit here, but as an idea/inspiration).

vidarh 4y ago

I literally just posted an image from my terminal based editor where I very much cared about this: https://imgur.com/a/LudA5nY https://imgur.com/a/LudA5nY

JasonFruit 4y ago
I don't get what problem that image shows. (I'm design-blind.)
- vidarh 4y ago
  It doesn't show a problem. It shows using the technique in the linked article to get a border without the background colour showing on both sides of the line.
  - nuancebydefault 4y ago
    Could you please share more of your editor? Is it for personal usage only?
    - vidarh 4y ago
      The github repo [1] is wildly out of date, and it probably won't even run on other peoples systems at the moment as one of my experiments with it is to keep the editor itself as tiny as possible and leverage other tools for as much as possible. As such, it relies on bspwm for multi-window support, and on rofi for file-selection, theme selection etc., and helper scripts not in the repo. It's currently smaller than my Emacs config used to be... More so than the editor, which I'm kinda treating as my config more than a finished app, I'm gradually splitting functionality into a bunch of gems so that the editor itself will feel even more like just configuration... Here's another screenshot [2] showing part of the integration with Rouge for syntax-highlighting, and showing how it's rendering comments by recursing into Rouge's Markdown mode, which again recurses into Rouge's Ruby mode. The "LayeredLexer" class it shows is used to enable that. EDIT: It's my main editor, by the way, and it persists open buffers, and shares them between the user interfaces using Drb. Currently I have 1969 buffers open... [1] https://github.com/vidarh/re https://github.com/vidarh/re [2] https://imgur.com/a/1mTLAPs https://imgur.com/a/1mTLAPs

xani_ 4y ago

Eh, not really. Main advantage of terminal stuff is near-zero dependency and working over SSH, if in addition to that it's pretty (in "more readable" way), why not ? Web UI in comparison is always sluggish, usually required extra login method (instead of just sshing into client, or having CLI client with credentials saved) and in modern days require hundreds of megabytes of deps to even make the JS to run it

wruza 4y ago
Iirc you can ssh-forward a port to a remote localhost-only web server and visit local http://localhost:port http://localhost:port to use it. Something like `ssh -forward 2345:2345 -exec “http-server -p 2345 /path/to/mysite” myhost`, but with real options instead of my pseudo ssh cli. Don’t get me wrong, I’m not fond of the modern web either, but setting up something like a chat-like shell in a browser-over-ssh sounds like a pretty straightforward and lightweight job. Edit: correct args would be ssh -L 2345:server:2345 user@server '/home/user/bin/my-web-shell -p 2345'
- FullyFunctional 4y ago
  That totally breaks the flow. I often spends hours working remotely over ssh+tmux, running Emacs, htop, etc. in a full-screen terminal. Having to suddenly switch to a Browser just to interact with a pretty UI is a terrible flow-breaking trade-off. (OT: and anytime I have to bring up a browser I for "some reason" end up distracted from what I was doing.) I do wish terminal graphics support was a little better. A terminal (like iTerm 2 [0]) that supports inline graphics allows your terminal to display plot etc in a graphical form without having to exit it. In MGR [1] this was the _only_ way to display graphics, even interactive, and I think it had a lot of merit. [0] https://iterm2.com/documentation-images.html https://iterm2.com/documentation-images.html [1] https://en.wikipedia.org/wiki/ManaGeR https://en.wikipedia.org/wiki/ManaGeR
  - zokier 4y ago
    I wish there was builtin support for webapps that was at least as integrated as X forwarding is on ssh. Basically what I'm imagining is some standardized way of tunneling http in unix sockets, and then ssh setting up the sockets and some env var. Then when application connects to the socket ssh client would open new browser window similar to PWA. There are many flaws with such approach, webapps being often crappy being of course one of them. But the redeeming factor is that practically all the tech already exists, this would need just minimal glue to make it reality, while many other approaches are more of a pipe dream.

russellendicott 4y ago

I spent a few months trying to build a TUI client server UI framework targeting such users. http://uggly.bytester.net http://uggly.bytester.net