I really think Steven went about marketing this in the wrong way. It really should have been dubbed as a terminal alternative. By calling it a replacement he's just inviting a mass of critique which focuses on what it lacks rather than what it offers over an xterm.
TermKit - a graphical terminal replacement
71–80 of 208 posts
Re: TermKit - a graphical terminal replacement
#72Earlier quoted context omitted.
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 ;).
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.
Thing is, it's not about the tools being sacred. My problem with this is that he's not just solving problems I don't have -- he's solving them in a way that would make my problems worse!
For instance, I very rarely want more informations about the files from an "ls" command; and if I did, I'd probably use Finder instead. On the other hand, not having enough terminal real estate to display the entire directory at once is a very frequent problem. From that perspective, adding icons is a step in the wrong direction.
Thinking about it, if I were playing with making a better terminal, one of my first lines of thought would be things that made it quick and easy to break information out into other windows, because scrolling back and forth in the terminal's buffer is a PITA.
Of course, this new terminal might be exactly what the author needs, and more power to him if it is. There's no need for us all to use the same tools. (Thanks heavens -- I want nothing to do with Emacs or vi!)
Re: TermKit - a graphical terminal replacement
#73Earlier quoted context omitted.
Exactly, I think if you are a hacker you will stick with the shell the way it is, because knowing how stuff works with "zero" abstractions is power. Reminds me of this: http://i.imgur.com/jqIcv.jpg Also I mean as a hacker, not as an entrepreneur.
I think my point is that we've all been so locked into these tools that we've become blind as to where their failing are. I wanted to start TermKit from a fresh slate and only slowly add bits of existing Unix to it, so I could make sure the resulting whole still made sense.
For me, as someone that does all his work in Windows and stays away from consoles as much as possible, this entire discussion is hilarious.
I think your project is cool, it certainly is a fresh take on the console, but the minority of people that like the unix console will be very resistant to anything graphical, and the majority of people that prefer graphical interfaces will just wonder why the hell you still need to do all of that typing. :-)
The fundamental problem with consoles is that it's impossible to explore the interface. You can only use it by knowing the possible commands beforehand.
Hmm.. Perhaps that's something you could explore with Termkit? With the added graphical output, is it possible to show hints for what I can/want to do, given what I've already typed? I dunno, just an idea.
Re: TermKit - a graphical terminal replacement
#74I've toyed around with similar concepts, but went the way of trying to middle-man the input and display of a standard console instead of trying to recreate one. Admittedly that creates some limitations to how integrated things can look without extra work, but it allows for normal interactive programs and really only enhances what was already there. Plus there's the added benefit of being able to run commands even while something interactive is up.
In any case, these kinds of hybrids are inevitable due to the vast room for improvement that exists in desktop and system apps combined with how powerful the web standards have become for UI and interactivity.
Really though, while I think TermKit is a decently executed attempt at this, it alienates some of its audience for obvious reasons. It completely throws away the charm of a shell with visual style choices and breaks powerful features that people expect. That's fine, because even with those departures it can suffice as a casual mode with certain conveniences for times when it makes sense.
Visual styles can be fixed or customized, so that's just shortsightedness by others.
As far as expected features like interactivity and whatever else people feel TermKit lacks, it seems like any hybrid terminal that takes this route should really try to implement a quickswitch that lets you fade between a rich terminal and a standard text console, already at your working directory with the same permissions.
Sure, people could just task switch to another running console, but that segments the whole experience a bit more.
Re: TermKit - a graphical terminal replacement
#75After 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…
My local editor is vim in a terminal. :)
It seems like TermKit could handle curses applications fairly straightforwardly and without modifying those applications. Just set TERM=xterm, and when you see the xterm initialization string, either open a new tab or define a region in the existing tab, and emulate an xterm within that region. (If you use a region in the existing tab, it could have a control attached to it that splits that region out into a new tab.) That would allow existing programs like vim, htop, powertop, and mutt to work perfectly within your terminal.
Personally, I'd like to use this like an enhanced standard terminal. So, for instance, I'd like to have the standard ls output rather than something graphical, but I'd like the filenames in the ls output to act as links, so I can click to open or hover for a preview. And while I want the standard cat command, I'd also like to have the command that displays something inline in the terminal (with the above-mentioned control to move it to a new tab).
Re: TermKit - a graphical terminal replacement
#76I really hope this guy gets hired by Apple. There are some really great ideas here.
Re: TermKit - a graphical terminal replacement
#77Earlier 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...
I'm so impressed with that. If I was getting that much criticism (for something so obviously excellent!) I'd be shaking in my boots. :-(
Re: TermKit - a graphical terminal replacement
#78I 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 it:
Start by emulating a normal terminal (xterm/vt10x). Add support for a special ESC-sequence that switches the terminal into TermKit mode (and another one to switch back).
This way we have a normal terminal, with a bonus-mode.
A simple cli-wrapper could be provided to mix the "magic" in. E.g. to cat a PNG I would: 'cat foo.png | tk_wrap'.
And on the screen that image would magically be embedded below my command line, just like any text output would.
tk_wrap would be small wrapper that first emits the termkit-esc, then the stdin-data (converted to the json meta-format), and finally the termkit-end-esc.
That's the basic architecture that I'd like to see. And from there, sky's the limit.
Re: TermKit - a graphical terminal replacement
#79Earlier 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…
Regarding your quote problem: the idea is that the highlighted token signifies "quoted string". I plan to add regexp tokens, user@host tokens, etc. each with appropriate autocomplete. I thought the current minimalistic approach was ok, but it might be worth to add subtle quotes around the edges to reinforce the idea. That's why it's made out of HTML/CSS...
"quoted string" or 'quoted string'? Big difference. :)
Re: TermKit - a graphical terminal replacement
#80Its good to see modern development in the terminal space. Sure it may be wrong what this guy implemented, but at least its some progress. Lets keep the ideas flowing.