>monospace text just doesn't cut it anymore Maybe in your terminal world, but not mine buddy.
Seriously. But I wish all fonts included a monospaced variant. Why shouldn't I use Helvetica in my terminal?
TermKit - a graphical terminal replacement
61–70 of 208 posts
Re: TermKit - a graphical terminal replacement
#62Earlier 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…
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.
Re: TermKit - a graphical terminal replacement
#63I 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…
There's lots of scope for this kind of thing. My main concern would be whether a single WebKit control is the right way to go - it'd be nice to, for example, embed custom controls within the shell (but this might also be possible).
Yes, that's possible. Webkit embeds JS, and you can do the craziest of controls in JS, communicating with your process through JSON packets (at least, that's how I understand the article). This would need some extension mechanism at the side of the shell, though, but that's not rocket science.
Re: TermKit - a graphical terminal replacement
#64I love the idea of experimenting with graphical output on the console. I've seen images and vidoes running on the terminal (not a terminal emulator) using "framebuffer" consoles. Sadly that typically only worked in full-screen mode. If somebody wrote an ordinary terminal emulator that allowed pixel graphics as part of the normal text flow, and created an easy API for programs to use it, I'd be very happy. TermKit loo…
I think this guy should look into implementing something like this as a compromise.
No, he shouldn't be making compromises at all. He's rightfully aiming at making the shell of the future. Features to comfort people that are stuck in their current ways can easily be backported in later, as we know how they work since the 70's.
Re: TermKit - a graphical terminal replacement
#65Earlier 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…
I'm having a blast and interpreting all the flak as a sign I must be doing something right...
Bingo. If you haven't pissed anyone off, it's because you're not doing anything important. There are people who invested DECADES of their life into a vanilla terminal ... and here you are, fucking with THAT.
Re: TermKit - a graphical terminal replacement
#66This 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…
Either way, large experiments like this are a necessary part of the path there.
Re: TermKit - a graphical terminal replacement
#67The first thing to realise is that the existing UNIX data processing tools deal fall into two categories - those that process (including generate or consume) an ordered sequence of text records (eg. sort, comm, uniq, awk, sed, grep, tr, cut, find, xargs, ls...) , and those that process arbitrary binary data (cat, dd). Most fall into the first category. Now, while it might make sense to use a better interchange format…
And how do we write "cat" to deal sensibly with currently unknown data types, that will be defined in the future?
Progressive enhancement. You get magic for the obvious things and standard behavior for the non-obvious. I still want the power and flexibility of my vanilla terminal, but I want it to do more when it can.
I want to open up a remote terminal to another server, on the other side of the planet, and do a "cat foo.png" so that I can see it. Better yet, I want to do an "ls -la" and have it show me the standard output, plus all the thumbnails of the images in the folder. I want to do a ton of other stuff too. At the same time, if load up some esoteric weird 30-year-old thing I found on the internet that I just compiled ... well, I expect that to work too. That's a must.
Of course, wanting and having are two different things.
Re: TermKit - a graphical terminal replacement
#68This has been tried before with the XUL-based xmlterm around the turn of the century, but it was very slow:
http://www.xml.com/pub/a/2000/06/07/xmlterm/index.html
Interesting to see someone pick this up again.
Re: TermKit - a graphical terminal replacement
#69There's actually a lot that can be done to improve current shells even without breaking the current set of abstractions and tools:
http://en.wikipedia.org/wiki/Fish_shell
Re: TermKit - a graphical terminal replacement
#70ls | grep js? really?