Amazing work. This kind of API has potential to be a real game changer. Imagine what this style interface could do for things like Image, Audio and Video processing. Can't wait to watch see this progress.
TermKit - a graphical terminal replacement
141–150 of 208 posts
Re: TermKit - a graphical terminal replacement
#142This a cool project, albeit not my cup of tea. Sure, the terminals out there need a little work, but I'm skeptical about bringing too much of the "gui world" in. There are, however, some concepts that are worth copying and that are in fact doable in current terminal environments. What I would like to see is more innovation in the world of console programs. There are lots of things to do in terms of auto-completion, n…
"Notmuch is an answer to Sup. Sup is a very good email program written by William Morgan (and others) and is the direct inspiration for Notmuch. Notmuch began as an effort to rewrite performance-critical pieces of Sup in C rather than ruby. From there, it grew into a separate project. One significant contribution Notmuch makes compared to Sup is the separation of the indexer/searcher from the user interface." http://…
why should indexer/searcher be coupled to email files in particular, instead of dispatching on MIME types? why should the datamodel be something ad-hoc instead of RDF?
http://blog.whats-your.name/post/2011/02/14/sifting-thru-you...
Re: TermKit - a graphical terminal replacement
#143Awesome project.
Browser technology is on a tear recently, and terminals are ripe for innovation. For a newborn project, this is an impressive mashup.
The number of dismissive people in this thread shows how disruptive this idea is!
Re: TermKit - a graphical terminal replacement
#144Re: TermKit - a graphical terminal replacement
#145I love this! It has fundamental conceptional flaws. But hell, finally someone is rethinking the terminal, please continue working on this! Here's the direction I would propose: It must be 100% backwards compatible. This is not optional, anything else is a non-starter. Likewise trying to re-invent the entire unix userspace toolchain is a terrible idea. So why not do it the UNIX-way and how terminals have always done i…
I hear what you're saying, but respectfully I disagree.
To me, it's like suggesting that the iPhone would be better if you added a physical slide out keyboard to make it more old-school; sure, you could do that, and would probably score popularity points with unconvinced customers.
But you would compromise tons of secondary aspects of the device to do so.
If TermKit would have a "traditional" mode of operation, and let you switch back to it, it would mean that TermKit has failed in being a comprehensive tool. I hope I can get around that.
Re: TermKit - a graphical terminal replacement
#146This is interesting, but I have doubts. He wants to fix the terminal by 'separating the "data" part from the "human" part'; in practice, using separate visualizers for human display. This puts me another degree of separation away from my raw data and forces me to trust the accuracy of the visualizers.
You already trust the accuracy of your visualizers: your eyes. Is it space or a delimiter? Is that a quote or a backtick?
Re: TermKit - a graphical terminal replacement
#147Ironically enough, this reminds me a lot of eshell, the shell implemented in Emacs lisp. Since it runs in a rich environment, it can augment a lot of standard unix functionality with really useful features, and you can extend it in a language that's not insane.
For example, grep/find results are hyperlinked, you can pipe commands directly to buffers (or even lisp functions) rather than just files, and such. In fact, now I'm tempted to add the ability to cat an image and have it display inline; should be pretty easy to implement in elisp.
Re: TermKit - a graphical terminal replacement
#148More proof that people who don't understand UNIX are condemned to reinvent it, poorly.
People keep saying that, and then fail to tell me any solid reason why I'm wrong.
Re: TermKit - a graphical terminal replacement
#149Earlier quoted context omitted.
"Notmuch is an answer to Sup. Sup is a very good email program written by William Morgan (and others) and is the direct inspiration for Notmuch. Notmuch began as an effort to rewrite performance-critical pieces of Sup in C rather than ruby. From there, it grew into a separate project. One significant contribution Notmuch makes compared to Sup is the separation of the indexer/searcher from the user interface." http://…
why should indexer/searcher be coupled to email files in particular, instead of dispatching on MIME types? why should the datamodel be something ad-hoc instead of RDF? http://blog.whats-your.name/post/2011/02/14/sifting-thru-you...
That's something that they are working on. One example of a useful application is a text ebook collection.
Re: TermKit - a graphical terminal replacement
#150As a UI designer, even though I've just begun working with terminal, I can't say I like this too much. Don't get me wrong, it looks GREAT, but much as I expected, it goes against a lot of ideas and based on some of the comments, strips a bit of functionaity (a huge no no). I think Steven's intentions are solid, but he's sort of playing with fire on this one. Cool idea, though.
Of course he is playing with fire, that's the only way to do real innovation. Remember that this is just a proof of concept, and a very compelling one.