Hacker News Reader

Comment by nuancebydefault | Hacker News Reader

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.

View on HN

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!

Would you care about the colour bleeding, that was solved by using other characters?

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 :)

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.

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 :)

Yes, the content has less distractions and is more legible when it has solid uniformity and consistency. Bleeding colors create a distraction and may run up against other content, potentially degrading legibility.

Personal anecdote, I’ve spent half of my youth in turbovision-like interfaces and never experienced anything like what you described, never even thought of it before this thread. Not that subj is bad, but to me it feels like a strange problem to solve.

Same here for turbovision interfaces and similar. I've never found them bad. But when I've seen that an alternative was possible by changing the VGA character generator, I found that more aesthetically pleasing.

> it feels like a strange problem to solve.

Seen this way, why bother creating nicely-looking GUIs? It would be the same strange problem to solve.

I wouldn’t in a slightest.

Kids these days… Give them a chance and they will escape font-weight:200 saddlebrown-on-lavenderblush for tui “to look classy”.

When I was using MS-DOS, boxes were typically done with line-drawing characters that are basically the same that can be used in terminals nowadays, i.e. with color bleeding. But then I learned that it was possible to avoid that, by creating some custom characters (still staying in text mode on an EGA/VGA) to have the lines exactly at the border of the character boxes. It was looking much better, and I still believe that.

Now, I'm not saying that my eyes hurt when I see boxes with color bleeding in a terminal. I've seen so many in years of TUI under DOS that I find them to be absolutely normal. But when I see a nicely done TUI, possibly in an unexpected or creative way, I find it more pleasing to use. It is the same as for a GUI: why not keep Windows 3.1 window decorations, if those details are not so important? The fact that it is in a terminal or not does not make any difference.

Aesthetics are medium-agnostic, they are valid both for TUIs and GUIs.

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.

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.

What's the excessive attack surface on a GUI?

All of the supporting libraries and services, e.g., DBUS. TUIs tend to have much simpler library dependencies and far fewer system dependencies.

No cross site scripting. No CORS.

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.

I literally just posted an image from my terminal based editor where I very much cared about this:

https://imgur.com/a/LudA5nY

I don't get what problem that image shows. (I'm design-blind.)

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.

Could you please share more of your editor? Is it for personal usage only?

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

[2] https://imgur.com/a/1mTLAPs

Thanks for the elaborate explanation! Ps what do you mean by perstisting the open buffers, are they at any time in sync with a file, or are the buffers shared via another mechanism?

The editor is client-server using Drb (I'm considering changing the use of Drb; Drb is very easy to get running but you get little control over the interface; it's a bit too good at being transparent)

Originally I did it as a quick way of ensuring I didn't lose data when I started using it, as Drb will forward exceptions as well, so the backend just won't crash, so as long as you don't do anything which corrupts the buffers you're good. Instead the frontend may crash (and throw me into a Pry repl, where I can query the backend and make sure I can recover the buffers), and I can just restart the frontend on the same buffer and keep working. (In practice it mostly crashes when I am using it to edit itself)

As an extra precaution I made it serialise all the open buffers to disk regularly. So I can just shut down my machine and next time I open all the buffers are still there (like Emacs etc. it'll warn me if the file has been edited since the buffer was opened).

Eventually this also gave me multi-frame support "for free" in that splitting the buffer vertically or horizontally just spawns a new instance of the editor and attaches to the same buffer (and then you can open whatever you want in it)

Is that ruby code? I don't see any drawn boxes, just syntax-highlighted code?

It's the Ruby source of the editor the screenshot is of. There's no full box there, but the border between the line numbers and the main area uses this "method" of using one of the characters with blocks along the edges to create a border with one colour between two different coloured regions, using U+258B (Left Five Eights Block). I took my inspiration from that from my C64 days. This is a decades old method.

Ah cool. It took me a while to understand. So the problem it solves is: you can start a new colour without being constrained to the grid of the fixed-width characters. That way you can save a bit of space.

Yeah, and get neater borders/shading etc.

I realised too late that it's hard to see the border on imgur, here's one using a different theme which makes it a lot easier to see the transition:

https://imgur.com/a/fO7WVc1

On a tangent... I'm so happy that at my current job I don't need to read/write ruby... I never got used to its peculiarities.

Hah, we're very different there - I love Ruby, it's the most user friendly Smalltalk I've found.

I spent a few months trying to build a TUI client server UI framework targeting such users.

http://uggly.bytester.net

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?

Yes maybe, but would that solve any problem?

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?

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?

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).

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

Iirc you can ssh-forward a port to a remote localhost-only web server and visit local 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'

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

[1] https://en.wikipedia.org/wiki/ManaGeR

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.

I always think, these guys are wizards, when seeing their backtick and pipe laden commands. When i want to access a codebase via ssh, i simply boot vscode and search for ssh connect. Then I see the complete tree in seconds, can change files, can search with regexp, whatever without stackoverflowing (literally and figurative). The command to build (compile/link) and test is usually just typing make or so in the ssh terminal. As alternative to scp, i simply right click a file or directory that i want to transfer without thinking about slashes, root dirs, credentials etc.

> Web UI in comparison is always sluggish

At this point, I am 95% convinced that the reason web UI's are oftentimes perceived as sluggish is the easy access to custom animation/transition on the web platform. As a result, developers tend to overdo animations, or set the transition too long, resulting in a subpar experience.

Reply on news.ycombinator.com