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

111–120 of 208 posts

Re: TermKit - a graphical terminal replacement

#111

Post by ChuckMcM »

Excellent exploration of alternatives to the old 'terminal' application. It would probably help for context to explore the Bell Labs 'BLIT' terminal and the Digital Equipment Corp VT340 (color graphic terminal) and the Tektronix 4010/4014/4064 terminals. These had capabilities that augumented the basic terminal stuff and made it prettier at least to use them.

The humorous thing for me is seeing the discussion which essentially devolves into creating a new windows type metaphor but with a lot of keyboard shortcuts.

It may sound pedantic but consider that the terminal is the terminal because terminals define a keyboard driven user interface. A user interface is a 'vocabulary' which describes actions. Its vocabulary scales from a communication channel that is 300 baud to one which has multi-megabaud connectivity. You can create a different vocabulary (which is what the other terminals above did) and get additional features.

And you can create an entirely new vocabulary if you're willing to change the minimum connectivity channel bandwidth as well (I doubt TermKit would work well over 300 baud for example). There was some good work done on this in the 80's with 'visual shells' on the PC and of course there is a ton of work that IBM did in creating optimized terminal environments (with visuals no less) on 3270 terminals which were in many ways a pre-cursor to todays IDE tools, although perhaps more like Eclipse. Their environment which ran airline reservations was a good example of optimizing the vocabulary (key strokes) against the variety of tasks an agent might need to do.

So rather than calling this a graphical terminal replacement (which it isn't) calling it a visual UI which can be driven entirely by the keyboard might be better. I think that fundamentally the "thing" about terminals that everyone sort of 'gets' is that you don't have to use a mouse, you always know where your 'focus' is, and there are millions of key combinations which you can use to express certain actions. For some, that is simply 'living in emacs' for others it could be something like this.

Re: TermKit - a graphical terminal replacement

#112

Post by tvon »

unconed wrote: post #21
telemachos wrote: post #18

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, probabl…

To address some of your concerns: - Monospace fonts for code is definitely in. Try catting a .js file, it will get syntax highlighted. Most likely, it doesn't recognize the mime type of your file. It's using the old mime.types DB + some custom additions... also, the highlighter I'm using only has so many languages defined. I looked for the most comprehensive / least fail one. - Regarding vim... I admit I just don't l…

Regarding liking vim, I have no issue with typing "edit foobar.txt" and having a local MacVim open up :)

Most of what TermKit is doing doesn't immediately appeal to me (as a longtime shell junkie of sorts), but one thing I would love to have in a terminal is tooltips, or popups of some sort. For example, say I get a 40 line stack trace, I'd like to just see one line (the exception, where it was thrown from) but have the option to learn more by clicking on a line in the terminal. Basically how exceptions are reported in the browser in Django or Rails, but in the terminal.

Re: TermKit - a graphical terminal replacement

#113

Post by jessedhillon »

unconed wrote: post #25
unconed wrote: post #21

Earlier quoted context omitted.

To address some of your concerns: - Monospace fonts for code is definitely in. Try catting a .js file, it will get syntax highlighted. Most likely, it doesn't recognize the mime type of your file. It's using the old mime.types DB + some custom additions... also, the highlighter I'm using only has so many languages defined. I looked for the most comprehensive / least fail one. - Regarding vim... I admit I just don't l…

And on another note... it's been hilarious how people have been questioning my professional credentials just because I want to make something more usable. I've implemented over a dozen RFCs, can match regexps with the best of them and do know which end of a pipe does what ;).

I love the idea. But as someone who also loves vim, to hear that your vision of a new terminal excludes a tool as powerful and expressive as vim makes me sad, because it means that apparently I won't be able to benefit from this new terminal. I'll watch with interest, however.

Re: TermKit - a graphical terminal replacement

#114

Post by klochner »

Tycho wrote: post #96

I find Unix usability standards generally pretty insane. Funny he should post this, as on the train today I was thinking of making a program I'd call 'SmartTerm' or something which would basically be a more usable, graphically augmented terminal for beginners (or people who just can't stand interfaces which depend on memorization and patience). Some things I find nuts about the current terminal is OS X (at least the…

You can edit the user prompt[1] in most shells as well as the window title[2] in xterm. There's also a command-line editing mode in bash[3].

   [1] http://www.linuxselfhelp.com/howtos/Bash-Prompt/Bash-Prompt-HOWTO-2.html
   [2] http://tldp.org/HOWTO/Xterm-Title-3.html
   [3] http://www.catonmat.net/blog/bash-vi-editing-mode-cheat-sheet/

Re: TermKit - a graphical terminal replacement

#115

Post by munificent »

timtadh wrote: post #50
unconed wrote: post #21

Earlier quoted context omitted.

To address some of your concerns: - Monospace fonts for code is definitely in. Try catting a .js file, it will get syntax highlighted. Most likely, it doesn't recognize the mime type of your file. It's using the old mime.types DB + some custom additions... also, the highlighter I'm using only has so many languages defined. I looked for the most comprehensive / least fail one. - Regarding vim... I admit I just don't l…

While, I understand your dislike of Vim, Vi, Nano, Emacs, etc. (I can't work in them for extend periods of time either do to hand problems) They remain essential tools for many programmers and system administrators. Sometimes, you don't want to have the file pulled down and edited in a local edit and pushed back even if it is seamless. The benefits of inplace editing on remote machines is invaluable. I think this is…

> They remain essential tools for many programmers and system administrators.

So maybe TermKit isn't the app for them.

> However, it must be fully backwards compatible with the full unix toolchain to be useful.

"Must"? If this app does something useful for you, great. If not, that's fine too. Every app doesn't need to be used by every person.

Re: TermKit - a graphical terminal replacement

#116

Post by wickedchicken »

As far as I can tell you have to rewrite all your applications to use this. So he's not really advocating "a cool new terminal," he's advocating a "new Unix programming toolset, with accompanying terminal, to replace the BSD/GNU tools." This is great, and I wish you all the best of luck, but it looks like you're just rewriting Applescript.

Also, the reason Unix tools don't toss around JSON/XML/MIME is for sheer simplicity. It's a zen thing, something you OSX guys wouldn't understand.

Catting a png and getting a picture is nice though.

Re: TermKit - a graphical terminal replacement

#117

Post by wooster »

This comment thread, both here and on the blog post, is the best example of stop energy being directed at forward motion I've seen in a long, long time:

http://www.userland.com/whatIsStopEnergy

Kudos to unconed for doing something remarkable. I look forward to seeing where it goes from here.

Re: TermKit - a graphical terminal replacement

#118

Post by wladimir »

krakensden wrote: post #83
wladimir wrote: post #27

Earlier quoted context omitted.

I'm also a bit disappointed on how most people here react. I personally think your idea is great and pretty futuristic. I would certainly use a tool like this. Also it's open source so if a specific detail (such as the font) bugs them it can simply be changed. I've had similar ideas (based on Python) but never got around to executing them. Keep up the good work and don't let the angry bearded UNIX dinosaurs get to yo…

It's not futuristic, it's retro. I've seen three or four of these be announced with great fanfare, and then dropped. No one cares enough, the backwards compatibility is never good enough, and it's almost certainly too slow.

I wouldn't be surprised if Webkit was just as fast or even faster in rendering than your average Linux terminal emulator.

About caring enough, yeah, that depends, maybe the world is ready for this now :) At least it isn't some overengineered XML grotesquery this time.

Re: TermKit - a graphical terminal replacement

#119

Post by ianb »

ChuckMcM wrote: post #111

Excellent exploration of alternatives to the old 'terminal' application. It would probably help for context to explore the Bell Labs 'BLIT' terminal and the Digital Equipment Corp VT340 (color graphic terminal) and the Tektronix 4010/4014/4064 terminals. These had capabilities that augumented the basic terminal stuff and made it prettier at least to use them. The humorous thing for me is seeing the discussion which e…

I bet TermKit would actually work awesome over 300 baud. The two-tier approach -- a backend that executes commands and a frontend that displays stuff -- is going to be pretty efficient (if you are only running the backend remotely). Well... perhaps the chattiness of something like filename completion will be a bit of a problem, but it'll still probably work better that more directly interactive systems because it's working with a more abstracted protocol than a terminal does.

Re: TermKit - a graphical terminal replacement

#120

Post by wickedchicken »

bernardwilson wrote: post #43

I had a similar idea about 10 years ago, but never got around to implementing it. I'm amazed at the amount of hatred directed towards this - as if the terminal could in NO WAY be improved?!. But clearly it can. For example - wouldn't it be nice to have a terminal status bar with your CWD / git branch / etc in, without cluttering up space before $? Yep, you can use screen, and that destroys your ability to use the scr…

> wouldn't it be nice to have a terminal status bar with your CWD / git branch / etc in, without cluttering up space before $?

You can already do this. http://www.faqs.org/docs/Linux-mini/Xterm-Title.html

> Wouldn't it be nice to show the intended completions in a popup as you're typing (like web browsers do)?

This can probably be written as an extension to bash/tcsh/zsh to use the pop-up completion facilities of vim. If you want nice webapp-looking ones, you might be able to get away with terminal escape codes and use a perl script (this is how rxvt lets you click on http links automatically).

> can the result not be folded into a single line showing the summary, that I could expand if I wished?

An interesting point, and I was going to counter with a small one-liner using 'tee,' but I couldn't think of a good one quickly that does what you really want: 'auto-collapse.' The problem with this is that often with giant lines of output you really only want to look at the last few to see what happened. Otherwise your output is typically some kind of streaming log (you do not want auto-collapse for this) or a poorly written program. "walls of text" suck and are usually an indication of something you expect to have a lot of output (looooong makefile) and can do a less accordingly, or an unexpected error. If it's an error you want to see what it is, so you're going to click on the 'expand' button -- an extra click every time on an all-typing interface kind of sucks.

Post reply on HN