[aklug] Re: console applications resource

On Mon, 22 Nov 2010, Christopher Howard wrote:

> Tell me how you really feel. ;) The word "bull-crap" here sounds like a code phrase for "I'd like you to argue with me", so I'll take it as an invitation to a little back and forth:

:-)

> Your rebuttal is full of contradications and half-truths. First of all: strictly speaking, curses doesn't have to be used to fake a graphical interface, but it definitely has been historically. Take the ncurses-mode in Debian's "aptitude": you get drop down menus, text fields, and background colors all through the wonderful wealth of ncurses' interface widgets. It's not a real GUI, but it tries to look like one and therefore is /faking/ a GUI.

Completely untrue. Especially since curses existed *before* X Windows, so I
could accuse GUIs of faking a curses interface. That said, let's talk
reality: Curses is an abstraction layer for implementing portable character
interfaces. The fact that you can use the ASCII character set to simulate
menus, etc., is irrelevant. It's an API. Arguing that people have done
GUI'ish things with it makes it a GUI faker is no more logical than the dude
who wrote an assembler in bash arguing that bash is an assembler faker and
not a shell.

By your definition I could argue that if you use a CLI over telnet it's not
a true CLI. The telnet protocol also uses control codes to negotiate
everything for print support to terminal definitions. Ironically, my
version of telnet *also* links to ncurses. And, gee, so does -- GASP --
your shell! That must mean if you use a shell you must not be doing true
CLI!!!! >;->

> Yes, ncurses-based interfaces are based on character data, but it's hardly "simple". A lot of those characters are special escape codes that do things like changing the foreground and background color of other characters. These escape codes can even produce line borders, arrows, and blinking text. The library even comes with buffer support so you can switch back and forth between screen drawings at convenient times, just like you would in a simple 2D GUI program.

No offense, but you really don't understand what curses is. It can render
characters THAT ARE IN THE ASCII TABLE. Wow. That's an uppity character
interface. You might also note that for those terminals that are limited in
their character sets those particular characters won't show those "lines"
and blinking text, it substitutes approximate characters that the terminal
does support. Once again, that's not graphics, it's just a portable
character interface management API.

As for screen buffers, gee, that's not even unique to UIs. It's just
intelligent buffering to preserve bandwidth on slow serial links. It
flushes only what's changed (assuming the terminal supports a navigable
cursor). And, gee, people figured out that you could maintain multiple
buffers. Wow. An uppity API that can be used in traditional UNIX
semantics.

> I never said that a person couldn't live practically "without X". I just said that it was not entirely honest to claim to live in a "graphics-less" environment when you are using a bunch of programs that strictly speaking aren't Command Line Interfaces.

Bull-crap. :-)

> You say that CLI is king. Really, however, programs like vim, emacs, bsd tetris, and so forth really aren't CLI. They are TUI (Text User Interface) which is a way of faking a GUI with escape codes, using special /graphical/ terminals that are designed to properly interpret them. In a CLI, everything is done at a command-line (e.g., a Bash prompt).

I would suggest that *your* definition of CLI is peculiar to only you, and
the rest of the UNIX world considers CLI differently. CLI is typically
meant to cover all text-only interfaces, line-based, stream-based, or
curses-based. If you can run it on a text terminal, it qualifies. Period.

So, I must therefore plagarize: I reject your reality and substitute my
own.

         --Arthur Corliss
           Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Tue Nov 23 13:34:58 2010