Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TermKit - a graphical terminal replacement

acko.net

Post reply on HN
Print view View original

11–20 of 208 posts

Re: TermKit - a graphical terminal replacement

#11

Post by barrkel »

It's funny, his 'ls' by default prints out an information-sparse grid of icons (only showing 10 items with a horizontal scrollbar?), whereas when I use the command-line, I'm looking for exactly the opposite of a GUI - an information-dense table of text. I agree with the commenter that -r-xr-xr-x - or even 0555 - is far better than "you can't touch this" (which doesn't describe who can't touch it, and in what ways). His "rich display" is actually a display of poverty - it conveys less information than text.

The typing of file / stream data is interesting, but I don't think it's realistic - it requires all tools to change virtually overnight to preserve the headers. And it's not enough just to preserve headers; what if you pump stuff out to a temporary file and read it in a few milliseconds later? What about compound files, with data chopped out of them? If you want pretty pictures, syntax highlighting etc., ISTM better to have an enriched terminal communication protocol along with a couple of viewer programs which can render data formats to it, rather than change the whole world to type every data flow everywhere.

Re: TermKit - a graphical terminal replacement

#12

Post by MatthewPhillips »

Maybe I'm an old fogey but I'll stick with xterm and iterm. Having a terminal where I can have the same experience whether logged into a *nix box, on osx, or sshed into a remote server is far more appealing than being able to cat images or having a pretty progress bar. If I want to make json more readable I can just pipe it through one of the many json formatting scripts.

It might just be me but I find cocoa to be a bit boring and dated looking. Unix terminals are timeless. A nice tiling windows manager with 5 terminals is still one of the most beautiful set ups.

Re: TermKit - a graphical terminal replacement

#13

Post by sehugg »

Very cool. I'm always amazed at how much one can do with a properly composed pipeline and a Makefile or two. The power of pipes + the interactivity of a spreadsheet -- that's what I want in my next gen shell. I'll be interested in seeing how this experiment plays out.

And I do see it as an experiment, not a threat to our way of life. I like to think that the UNIX command-line environment is a local minimum.

Re: TermKit - a graphical terminal replacement

#14

Post by mhd »

None of the examples really sound all that exciting. I see the Unix shell more of a text file manipulation toolkit, so apart from some corner cases I'm not sure if adding MIME types etc really would add much value for the usual tasks. If you're adding too much structure to things, you might as well go all the way and base everything around a programming language or framework (cf. Oberon, Powershell, Lisp Machines).

I agree that emulating a terminal from the late 70s isn't exactly the peak of programming. Character-addressed terminals are just another way to get (cheap) WIMPy GUIs.

Re: TermKit - a graphical terminal replacement

#15

Post by mikemaccana »

barrkel wrote: post #11

It's funny, his 'ls' by default prints out an information-sparse grid of icons (only showing 10 items with a horizontal scrollbar?), whereas when I use the command-line, I'm looking for exactly the opposite of a GUI - an information-dense table of text. I agree with the commenter that -r-xr-xr-x - or even 0555 - is far better than "you can't touch this" (which doesn't describe who can't touch it, and in what ways). H…

On the other hand, ls isn't showing you the file type, and will never show you content. And you're mixing presentation with content, which is poor engineering - see the guys coming up with regexs to handle time because the only way time is presented to them is as text,

Good shells have prompted object pipeline based tools before - PoSH is only a few years old. And it's still possible for older tools to run with no degradation in quality from their previous environments.

This is really compelling.

Re: TermKit - a graphical terminal replacement

#16

Post by mikemaccana »

wladimir wrote: post #9
bruceboughton wrote: post #8

Earlier quoted context omitted.

From the article it sounds like most of the heavy UI is implemented using webkit and HTML/CSS/JS. Wouldn't this make it reasonably easy to port to *nix?

I have no clue, I looked in the github repos very quickly and saw all kind of scary .m files and I gave up :) If it's mainly HTML/js/webkit based then it would not be hard to port it to a portable window toolkit such as Qt4 (which has a QWebKit widget...).

Doesn't the article say it's TK? Which means it's already got X bindings.

Re: TermKit - a graphical terminal replacement

#17

Post by barrkel »

mikemaccana wrote: post #15
barrkel wrote: post #11

It's funny, his 'ls' by default prints out an information-sparse grid of icons (only showing 10 items with a horizontal scrollbar?), whereas when I use the command-line, I'm looking for exactly the opposite of a GUI - an information-dense table of text. I agree with the commenter that -r-xr-xr-x - or even 0555 - is far better than "you can't touch this" (which doesn't describe who can't touch it, and in what ways). H…

On the other hand, ls isn't showing you the file type, and will never show you content. And you're mixing presentation with content, which is poor engineering - see the guys coming up with regexs to handle time because the only way time is presented to them is as text, Good shells have prompted object pipeline based tools before - PoSH is only a few years old. And it's still possible for older tools to run with no de…

ls shows file type by coloring - check out ~/.dircolors/dircolors/LS_COLORS and ls --color=auto - and kind by extension - ls -F. Showing things like thumbnails seems to me to be of limited use. When I want to see the directory in all its glory, I'll do the moral equivalent of "cygstart/open/whatever .". That'll give me a proper shell window designed for viewing content with thumbnails etc., rather than trying to stick it into the terminal. I've had enough experience with things like dodgy video decoders crashing the shell's thumbnail preview mechanism to know I don't want that stuff anywhere near my terminal unless I specifically ask for it.

Powershell - I do indeed wish Unix shells worked a little more like it for jobs like parsing ps output portably across platforms, but it has poor performance for what I use the shell for, because it doesn't run each pipeline process as a separate process or thread - everything is single-threaded. I frequently run sed, awk, grep, sort over multi-GB files and rely on processes and job control (fork-join through mktemp, & and wait, and xargs -P) to make it work quickly.

But if, as I mentioned, the terminal supported a richer communication protocol - one smart enough to show render full 32-bit images including alpha - then a version of ls could be written that does what his ls command does, without needing to go as far as he does.

Re: TermKit - a graphical terminal replacement

#18

Post by telemachos »

After seeing something about this yesterday, I said on Rstat.us/Twitter that I thought it was pretty but disagreed with the whole premise. I still do, I think, but I'm very impressed with how reasonable Steven's response was. He wrote me and asked pretty much "Why?" I said essentially "Unix philosophy" and attached the link that ended up in his blog post.[1] He wrote back and at some point he wrote this post, probably replying to all the people who were taking snipes at him. So this is a long way around to say, kudos for being gracious and serious in the face of people glibly writing off your hard work.

Having said that, I'm still not sold on the concept - yet. I've played with it a bit this morning. Obviously it's still pretty alpha (more than one seize up or crash), but that's fine. My larger problem is in figuring out how it would fit into my daily work flow. After trying it out now, here are some concrete issues:

+ No monospace fonts for code. The output of cat looks like teeny-tiny website font. Things are no longer "lined up". That's bad.

+ I can't use any applications that take over the terminal (irssi, mutt, vim, less). Steven says as much - it's not part of his design - but for me it's a big problem. It means that even if I embrace TermKit, I still need those 1980s terminals.

+ No scripting language built in. As bad as shell scripting might be, I get an absolute ton done with it. I don't want to give that up unless something will make up for all that "getting shit done".[2]

+ TermKit (maybe?) forces me to change habits I can't afford to lose. One small, but I think important, example: If you try to run this:

    awk '{print $1}' file.txt
TermKit doesn't echo the single quotes. That is, you can type them, but they don't show up on the screen. I'm not really sure what to do with that. Does that mean I should stop typing them? Does that mean that I still must type them, but TermKit strips them because they aren't pretty? Does TermKit allow me to do it either way? I'm going to need to remember how to quote things when I log into a remote machine over ssh, so if TermKit will force me to change habits, that's a big, big problem. (After a few experiments, it seems like the single quotes are still required. Without them, TermKit tokenizes the stream differently. If that's the case, why refuse to echo them to the screen?)

[1] http://www.faqs.org/docs/artu/ch01s06.html

[2] Cf. Ryan Tomayko's Shell Haters talk: http://shellhaters.heroku.com/

Re: TermKit - a graphical terminal replacement

#19

Post by [deleted] »

mikemaccana wrote: post #16
wladimir wrote: post #9

Earlier quoted context omitted.

I have no clue, I looked in the github repos very quickly and saw all kind of scary .m files and I gave up :) If it's mainly HTML/js/webkit based then it would not be hard to port it to a portable window toolkit such as Qt4 (which has a QWebKit widget...).

Doesn't the article say it's TK? Which means it's already got X bindings.

[deleted]

Re: TermKit - a graphical terminal replacement

#20

Post by unconed »

mikemaccana wrote: post #16
wladimir wrote: post #9

Earlier quoted context omitted.

I have no clue, I looked in the github repos very quickly and saw all kind of scary .m files and I gave up :) If it's mainly HTML/js/webkit based then it would not be hard to port it to a portable window toolkit such as Qt4 (which has a QWebKit widget...).

Doesn't the article say it's TK? Which means it's already got X bindings.

TK just means TermKit, sorry.
Post reply on HN