TermKit - a graphical terminal replacement • Hacker News Board

Re: TermKit - a graphical terminal replacement

#191

Post by Cloven » Thu, May 19, 2011, 3:43 PM UTC

thasmin wrote: post #62

timtadh wrote: post #50

Earlier quoted context omitted.

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…

There is potential for TermKit to send files to your client's Vim, which opens a lot of possibilities. For example, it would be easy to have files from two different servers open. It would also reduce the number of places you need your configuration files. TermKit's author may dislike Vim, but I suspect that he's helped its users in the long run.

vim (and other editors) have lockfiles, recovery files in case of session crashes, and assume directory locality (e.g., oops I opened the wrong file; :r filename).

Re: TermKit - a graphical terminal replacement

#192

Post by gcb » Thu, May 19, 2011, 4:57 PM UTC

it kind of defeats it's own purpose.

cat a.png -- show the image in a tiny terminal, but I have a billion pixel screen.

why not just open it on the image viewer window?

you advocate this even for editing plain text in vim!

think that if you had learned to use X your days would be more productive... maybe not as cool...

Re: TermKit - a graphical terminal replacement

#193

Post by jrockway » Thu, May 19, 2011, 5:58 PM UTC

ak217 wrote: post #177

jrockway wrote: post #157

Earlier quoted context omitted.

Pretty sure Emacs has menus: http://jrock.us/emacs-menus.png

It does. The problem is, the terminology in the menus is completely inscrutable (i.e. many commands are named unintuitively), the menus are poorly organized, they have a small subset of all the commands, etc. I've never been able to learn any of the shortcuts from the menus.

In the end, it's your fault because you don't want to learn. Emacs does not have "cut" and "paste", it has "kill" and "yank". They are different terms because they have different semantics.

Enjoy programming in Notepad.

Re: TermKit - a graphical terminal replacement

#194

Post by steviesteveo » Thu, May 19, 2011, 6:41 PM UTC

tomkarlo wrote: post #159

roqetman wrote: post #54

Earlier quoted context omitted.

It is amusing how we hackers, who are supposed to embrace change, become as Luddite as anyone else when our sacred tools are questioned. Personally I see room for this and a whole lot more. I'd like to see an amalgam of this and the traditional terminal (easy way to pull up a traditional terminal if you need it). There is no need to "replace"; I think this makes a fine addition to a hackers workspace.

Bloomberg found the same thing when they tried to redesign their terminals for traders - existing users were so invested in their knowledge of the "incantations" of the old interface that they were hugely resistant to a UI with a more modern learning curve and interaction. It's very hard to make a product that essentially devalues things that your customers spent a lot of time learning. You're probably better off ign…

The thing about changes involving a "more modern learning curve and interaction" is that it's replacing something that already worked and users knew how to use.

I'm quite bad for upgrading for upgrading's sake but I can understand why, of all people, traders at Bloomberg didn't want any kind of learning curve on their terminals.

Yes, it's clearly better but users don't always want to change to something that does what they already do in a more modern way.

Re: TermKit - a graphical terminal replacement

#195

Post by tomkarlo » Thu, May 19, 2011, 10:27 PM UTC

steviesteveo wrote: post #194

tomkarlo wrote: post #159

Earlier quoted context omitted.

Bloomberg found the same thing when they tried to redesign their terminals for traders - existing users were so invested in their knowledge of the "incantations" of the old interface that they were hugely resistant to a UI with a more modern learning curve and interaction. It's very hard to make a product that essentially devalues things that your customers spent a lot of time learning. You're probably better off ign…

The thing about changes involving a "more modern learning curve and interaction" is that it's replacing something that already worked and users knew how to use. I'm quite bad for upgrading for upgrading's sake but I can understand why, of all people, traders at Bloomberg didn't want any kind of learning curve on their terminals. Yes, it's clearly better but users don't always want to change to something that does wha…

That doesn't mean you have to stop innovating. It just means that your customers might not be the people who are already using what you want to replace.

Re: TermKit - a graphical terminal replacement

#196

Post by 9999 » Thu, May 19, 2011, 10:46 PM UTC

colomon wrote: post #190

9999 wrote: post #108

Earlier quoted context omitted.

"if I did, I'd probably use Finder instead." The thing that strikes me as very, very cool about this project is that you might not need the Finder at all any more.

See, here's the thing: I like Finder. It's not perfect, but sometimes it is very handy. Even if TermKit ends up implementing the complete functionality of Finder, I'm not sure why I'd particularly like to have that functionality in my terminal window. And if it's only implementing the one Finder view I virtually never use? Forget about it. You know what would rock my world? A "lsf" command that emulated "ls" as much…

I've always thought Raskin's ZUI held some promise as an alternative UI paradigm. I'm pretty much a quicksilver addict now and use that to kind of combine the command line and GUI desktop worlds a little bit more at least.

Re: TermKit - a graphical terminal replacement

#197

Post by Rhapso » Fri, May 20, 2011, 2:07 AM UTC

It is pretty (and I want it for linux so I could use it!), but I think the real useful idea here is the separation of data out, and display out. If we could have that on a regular shell it would add a lot of usability. For this idea alone, my hat is off to you sir.

Re: TermKit - a graphical terminal replacement

#198

Post by pnathan » Fri, May 20, 2011, 2:15 AM UTC

This is interesting and a cool proof of concept. I don't believe that, as you show it, it is something I'd want to live in.

I virtually live in a full-screen emacs (on CLI or GUI). Emacs provides a somewhat nicer shell world than straight up Terminal.app. Emacs has copy & paste, a fully editable window display and its own command history.

Why do I bring this up? Because I feel that your application as currently demoed is not going to help me. I don't want to see GUI icons in general.

What I do like is your connection to the OS display layer. The ability to render out a PDF-inshell is pretty nice. Without having to go grub around for the right configuration, I can't just go "load foo.pdf" and have it pop up automatically.

So I really look forward to see what kind of cool explorations you do.

Re: TermKit - a graphical terminal replacement

#199

Post by planckscnst » Fri, May 20, 2011, 2:49 AM UTC

The author talks about the hazards of parsing text streams, then talks about parsing ls, which is impossible to parse because there is no way of differentiating a newline in a filename from one that delimits the end of a line of output.

Re: TermKit - a graphical terminal replacement

#200

Post by boohiss420 » Fri, May 20, 2011, 5:20 AM UTC

Why is the focus on the "terminal" as an application? This isn't about the terminal; it is about changing the convention by which many small programs interact with one another. To fetishize the "terminal" aspect of this is to ignore the fact that these tools are used most often in non-interactive ways. Should these tools use a different contract? Maybe. There have been much better thought out attempts to do so.