10 ms·

TermKit: A Rich Graphical Terminal (2011)

67 points by isaacimagine 5y ago

xialvjun 5y ago
Developers of terminals are moving forward to strong type (like power-shell, nu-shell etc). I think this is the future. Besides, the strong type terminal should be the base of the graphical terminal, but I don't think we need a graphical terminal.
lproven 5y ago
This was an interesting idea. It just strikes me that there is no reference to any of the earlier ideas in extending the xNix terminal/command-line interface. I am thinking of the BLIT terminal: https://en.wikipedia.org/wiki/Blit_(computer_terminal) https://en.wikipedia.org/wiki/Blit_(computer_terminal) Arguably that extended to 8½: https://en.wikipedia.org/wiki/8%C2%BD_(Plan_9) https://en.wikipedia.org/wiki/8%C2%BD_(Plan_9) ... and thence Rio: https://en.wikipedia.org/wiki/Rio_(windowing_system) https://en.wikipedia.org/wiki/Rio_(windowing_system) ... and thence 9wm: https://en.wikipedia.org/wiki/9wm https://en.wikipedia.org/wiki/9wm ... which leads to eight or more further references and starts to need a map. :-) The other ancestor which seems relevant being the Oberon TUI, which informed and inspired Plan 9: http://ignorethecode.net/blog/2009/04/22/oberon/ http://ignorethecode.net/blog/2009/04/22/oberon/ ISTM that there is or are lots more relevant things to the general concept of "let's extend the shell to that it makes intelligent use of graphics, pointing-device input and so on" such as Symbolics OpenGenera, and come to that, Interlisp, but then you disappear down pathways (Wirthian languages, Lisps etc.) that tend to turn off xNix folks.
desi_ninja 5y ago
Termkit showed great promised but the progress of the project fizzled out later. Technical limitations maybe ? Because definitely not lack of contribution. This had a lot of eyeballs
- ilaksh 5y ago
  Definitely lack of contribution. Regardless of that particular project, it's a really useful set of ideas. People just did not adopt them for other projects. The thing that most people will possibly never understand is that the reason people do things is generally not rational. And often the better an idea is, the less likely it is to be adopted soon. So the fact that something doesn't become popular does NOT mean it doesn't have technical merit or legs. Actually it often means the opposite. Humans, including programmers, are very similar to sheep. And I don't mean that in a joking way. I mean literally their behavior, including what tools they use for programming, is largely decided subconsciously by the activity of the other humans around them.
  - naikrovek 5y ago
    it's not even subconscious most of the time. "this is what everyone does, so I'll do that, too."
satiric 5y ago
This isn't a bad solution, and something like this is sorely needed. I completely agree with the idea that the limitations of technology from 40 years ago shouldn't be holding us back nowadays. It's no coincidence that all the major development in unix-like operating systems happened in the days when there was only 1 unix-like operating system, and it was controlled by 1 organization. The greatest failure of Linux is that it's not an operating system, but a kernel upon which dozens of operating systems are built. It seems to me like the number one reason why people don't use Linux is that there is no central authority over user experience, and thus no way to get everyone to standardize to something. This is not even remotely a problem with Windows and Mac OS! And you can see the problems with this architecture when you realize how ancient and arcane the terminal UX is. But until we ditch it, we'll be stuck in the land of POSIX forever.
- michaelsbradley 5y ago
  when you realize how ancient and arcane the terminal UX is. But until we ditch it, we'll be stuck in the land of POSIX forever (which isn't necessarily a bad thing). Developers of terminal emulators have been trying to move things forward, though I imagine there's little chance of the ancient/formal standards evolving. Kitty seems to be leading the pack of late: https://sw.kovidgoyal.net/kitty/protocol-extensions/ https://sw.kovidgoyal.net/kitty/protocol-extensions/ It seems the way it will work these days is that the maintainer/s of a popular terminal emulator put some careful thought and effort into an extension; maintainers of others then recognize the benefit and follow-up with feedback and complementary implementations that over time might drive toward a de facto standard.
  - hnlmorg 5y ago
    I'm on the fence about some of Kitty's extensions. The file transfer of TTY extension, for example, strikes me as adding little benefit over SSH but while also creating a new risk vector as it means we can no longer trust even printing to the screen. I'm also not fond of the hyperlink extension that some terminals are adopting. We already know of the risk with emails and hyperlink URLs pointing to different locations (eg <a href="not.google.com">google.com</a>) the last thing we need is the terminal to also be exploitable. I think some CLI users are looking at websites lustfully and wanting to emulate some of those features and while I'm all for improvements (better image support is always the obvious example but I'm all for inlining other forms of documents too) we definitely shouldn't be taking all the webs features wholesale without having a serious pause for consideration about the risks they might introduce. Particularly when a lot of organizations are still reliant on SSHing into remote servers.
dang 5y ago
Related: Is TermKit dead? Why? - https://news.ycombinator.com/item?id=4787211 https://news.ycombinator.com/item?id=4787211 - Nov 2012 (1 comment) Why did TermKit die? - https://news.ycombinator.com/item?id=3154553 https://news.ycombinator.com/item?id=3154553 - Oct 2011 (1 comment) TermKit - a graphical terminal replacement - https://news.ycombinator.com/item?id=2559734 https://news.ycombinator.com/item?id=2559734 - May 2011 (200 comments) TermKit - Next Generation Terminal/Command Application - https://news.ycombinator.com/item?id=2542068 https://news.ycombinator.com/item?id=2542068 - May 2011 (2 comments)
euroderf 5y ago
There's no releases at the github repo. Maybe there's a mac build available somewhere? Building fails on my mac, because javascript.
naikrovek 5y ago
this seems like it could have died solely because non-web developers (almost all of whom use terminals daily, and would pay attention to this) are pretty quick to realize just how awful JavaScript is, compared to the languages they use day to day. the fewer places that JavaScript can escape to, the better, and terminals adopting anything that looks like web tech is such an alarmingly bad idea that I don't even know where to begin to address any arguments for that approach. TermKit deserved to die because of its JavaScript nature alone.
- slightknack 5y ago
  Like you, I am not a huge fan of JS, but I'd like to say that the ideas behind TermKit — namely having a shell with richer graphical interaction (e.g. cat works for images too), semantic awareness and tokenization of commands, rich autocomplete, etc. — were ahead of their time. Maybe it's expected that TermKit-the-project died, but I don't think that TermKit-the-idea should: whether it be bringing features from the project as extensions to existing terminals (cat for images would be nice), or building a new TermKit built on modern graphics libraries powered by WASM/Lua/bring-your-own scripting language.
  - naikrovek 5y ago
    I am all about the larger intent behind TermKit, but intent alone cannot carry a project to success. A successful replacement for current textual shells will not look anything like the textual shells we have today; everything will be reimagined and will make sense, and will be very foreign to you and I. A shell with graphics tacked on is not the revolution needed in this space. Waveform Graphics, Sixel and ReGIS (please look those up if you are not familiar) came to DEC terminals in the 1970s and 1980s, and still do not have widespread adoption. The addition of graphics isn't enough on its own, with or without new programs to blend the border between text and imagery. A true leap is required to gain market share in this space. Simple evolution of the existing shell experience is just simply not enough. TermKit, Waveform Graphics, Sixel, and ReGIS effectively prove this. I can not say that I know what whatever replaces our current terminals will be, but it will not look like TermKit. Or ReGIS, or Sixel.
hnlmorg 5y ago
To those who are wishing something would fill this void, I'm working on something that does overlap with this. I've already matured the shell somewhat over the last ~8 years. That shell can inline images, manage and manipulate different document formats and convert between them, understanding data types and structures like Powershell but works natively with POSIX CLI tools (which Powershell cannot). Last year I also started playing around with WASM and building a terminal emulator in it. The idea being if I can manage the terminal emulator then I can add more features / friendlier UI/UX that might compliment non-CLI users who have been tasked with using the terminal; while power users still have access to the features of the $SHELL in their preferred terminal emulator. There is definitely overlap between what I'm doing and TermKit. The idea of doing it this way means I'm still leveraging the foundations already in common use. Opinions about whether they're ready to be deprecated aside, it's the standard everyone already uses so trying to displace that would be an even big hurdle than even just trying to displace Bash. But at least if the standards are reused and extended it does mean people can pick and chose the items that work for them rather than forcing them into an "all or nothing" type scenario. I'm not far down the terminal emulator route yet and it's definitely a task that is bigger than the time I personally have to commit to it. So I welcome any time and/or support anyone is willing to donate. I should write a blog post about this at some point too.... The shell (in it's current form): https://github.com/lmorg/murex https://github.com/lmorg/murex (docs on Github too but also accessible via https://murex.rocks https://murex.rocks )
- MediumFalse 5y ago
  This looks quite interesting! Thanks will check it out.
vanderZwan 5y ago
I've been using Terminology[0], which has some of these features. That's not why I'm using it though, it just happens to have the lowest latency of all terminal emulators that still does fancy font rendering on my machine. [0] https://www.enlightenment.org/about-terminology https://www.enlightenment.org/about-terminology
- georgia_peach 5y ago
  Thanks for this. I didn't know Terminology had so many tricks! Reading their extended escapes as I write this.
sgt 5y ago
I see plenty colors on my screen already. My shell doesn't need colors. The terminal is a dark place, but it's cosy and it's surrounded by a colorful macOS desktop. The shell is a portal that takes me to the joys of Unix.
georgia_peach 5y ago
Kitty, iTerm, Mintty, Wezterm, & many others support an escape code for base64-encoded images (gif/jpg/png). Most GUI terms also support sixel--which is highly inefficient, but gets the job done. None of that is as slick as this, but I consider that to be a good thing.
- thechao 5y ago
  Is Sixel highly inefficient? It's palettized, and encodes a 6b value in an 8b code. It'd be nice if terms supported "inline PPM"; those are (on average) only somewhat larger than their equivalent BMP. (Worst case is 2x, roughly.) If we had an "ASCII QOIF", you could dramatically beat BMP, most of the time, and be within 33% of a PNG, in many cases.
  - georgia_peach 5y ago
    What it gives with RLE, it takes back with overpainting to have multiple colors on the same line. It is a hot mess.
  - georgia_peach 5y ago
    Also, what is QOIF?
    - isaacimagine 5y ago
      quite okay image format: https://qoiformat.org/ https://qoiformat.org/
rbanffy 5y ago
Terminals are actually very rich interfaces - over decades they have developed features, such as Tektronix and ReGIS graphics, type features (double height, double width), alternative fonts, multiple windows, single-voice sounds, smooth scrolling (cute, but not that useful), and Sixel graphics. All these have been available since terminals were actual boxes on our desks with CRTs built-in. All that is described in the developer manuals for them. Unfortunately, most of these features are not supported by our terminal applications (Apple's Terminal supports double width and height, at least, and xterm can do Tektronix graphics) and libraries such as ncurses allow us to write software using many of those features having to understand the control sequences (most terminals today look like xterm). If we could push for support to these features, we'd have an already proven, probably supported by ancient software that we run today but that we never saw as intended, set of standards and functionality we could rely on. If all terminals, for instance, supported sixel graphics (a horrible standard, BTW) or DRCS (a meh one), we wouldn't need font support for character graphics (Unicode v13 has new Teletext block graphics, and 4x2 mosaics will be added soon, and libraries such as VTE implement those without font support) or "powerline" symbols.
Per_Bothner 5y ago
DomTerm (https://domterm.org https://domterm.org) attempts to provide similar possibilities as TermKit. However, it starts with the position that it should also (and perhaps first) be a fully-functional modern mostly-xterm-compatible terminal emulator. On top of that we add rich html text, images, logical structure, "shell integration", and more.
- Per_Bothner 5y ago
  It you like TermKit's pretty-printing of JSON, check out: https://domterm.org/saved/dt-prettynested.html https://domterm.org/saved/dt-prettynested.html Try re-sizing the window width (to trigger smart re-breaking), and clicking the little triangles (to show/hide sub-trees of the output). The actual pretty-printing is application-specific (for example the PrintNested java program at the top), but the output contains certain escape sequences to mark logical structure, optional indentation, and show/hide buttons. Note this is basically a log of a terminal session from a few years ago, but saved as HTML, along with JavaScript to respond to the window-resize and show/hide actions.
spacexsucks 5y ago
Having used emacs exwm, i3, and awesome for last 3 years straight, you dont need any of this on Linux. This is all there. Just use 'feh' if you want to 'cat' and iamge. Like wise for ffprobe, etc This for macs and winodows with literally dumb UX for development

67 points by isaacimagine 5y ago

Developers of terminals are moving forward to strong type (like power-shell, nu-shell etc). I think this is the future. Besides, the strong type terminal should be the base of the graphical terminal, but I don't think we need a graphical terminal.

lproven 5y ago

This was an interesting idea. It just strikes me that there is no reference to any of the earlier ideas in extending the xNix terminal/command-line interface. I am thinking of the BLIT terminal: https://en.wikipedia.org/wiki/Blit_(computer_terminal) https://en.wikipedia.org/wiki/Blit_(computer_terminal) Arguably that extended to 8½: https://en.wikipedia.org/wiki/8%C2%BD_(Plan_9) https://en.wikipedia.org/wiki/8%C2%BD_(Plan_9) ... and thence Rio: https://en.wikipedia.org/wiki/Rio_(windowing_system) https://en.wikipedia.org/wiki/Rio_(windowing_system) ... and thence 9wm: https://en.wikipedia.org/wiki/9wm https://en.wikipedia.org/wiki/9wm ... which leads to eight or more further references and starts to need a map. :-) The other ancestor which seems relevant being the Oberon TUI, which informed and inspired Plan 9: http://ignorethecode.net/blog/2009/04/22/oberon/ http://ignorethecode.net/blog/2009/04/22/oberon/ ISTM that there is or are lots more relevant things to the general concept of "let's extend the shell to that it makes intelligent use of graphics, pointing-device input and so on" such as Symbolics OpenGenera, and come to that, Interlisp, but then you disappear down pathways (Wirthian languages, Lisps etc.) that tend to turn off xNix folks.

desi_ninja 5y ago

Termkit showed great promised but the progress of the project fizzled out later. Technical limitations maybe ? Because definitely not lack of contribution. This had a lot of eyeballs

ilaksh 5y ago
Definitely lack of contribution. Regardless of that particular project, it's a really useful set of ideas. People just did not adopt them for other projects. The thing that most people will possibly never understand is that the reason people do things is generally not rational. And often the better an idea is, the less likely it is to be adopted soon. So the fact that something doesn't become popular does NOT mean it doesn't have technical merit or legs. Actually it often means the opposite. Humans, including programmers, are very similar to sheep. And I don't mean that in a joking way. I mean literally their behavior, including what tools they use for programming, is largely decided subconsciously by the activity of the other humans around them.
- naikrovek 5y ago
  it's not even subconscious most of the time. "this is what everyone does, so I'll do that, too."

satiric 5y ago

This isn't a bad solution, and something like this is sorely needed. I completely agree with the idea that the limitations of technology from 40 years ago shouldn't be holding us back nowadays. It's no coincidence that all the major development in unix-like operating systems happened in the days when there was only 1 unix-like operating system, and it was controlled by 1 organization. The greatest failure of Linux is that it's not an operating system, but a kernel upon which dozens of operating systems are built. It seems to me like the number one reason why people don't use Linux is that there is no central authority over user experience, and thus no way to get everyone to standardize to something. This is not even remotely a problem with Windows and Mac OS! And you can see the problems with this architecture when you realize how ancient and arcane the terminal UX is. But until we ditch it, we'll be stuck in the land of POSIX forever.

michaelsbradley 5y ago
when you realize how ancient and arcane the terminal UX is. But until we ditch it, we'll be stuck in the land of POSIX forever (which isn't necessarily a bad thing). Developers of terminal emulators have been trying to move things forward, though I imagine there's little chance of the ancient/formal standards evolving. Kitty seems to be leading the pack of late: https://sw.kovidgoyal.net/kitty/protocol-extensions/ https://sw.kovidgoyal.net/kitty/protocol-extensions/ It seems the way it will work these days is that the maintainer/s of a popular terminal emulator put some careful thought and effort into an extension; maintainers of others then recognize the benefit and follow-up with feedback and complementary implementations that over time might drive toward a de facto standard.
- hnlmorg 5y ago
  I'm on the fence about some of Kitty's extensions. The file transfer of TTY extension, for example, strikes me as adding little benefit over SSH but while also creating a new risk vector as it means we can no longer trust even printing to the screen. I'm also not fond of the hyperlink extension that some terminals are adopting. We already know of the risk with emails and hyperlink URLs pointing to different locations (eg <a href="not.google.com">google.com</a>) the last thing we need is the terminal to also be exploitable. I think some CLI users are looking at websites lustfully and wanting to emulate some of those features and while I'm all for improvements (better image support is always the obvious example but I'm all for inlining other forms of documents too) we definitely shouldn't be taking all the webs features wholesale without having a serious pause for consideration about the risks they might introduce. Particularly when a lot of organizations are still reliant on SSHing into remote servers.

dang 5y ago

Related: Is TermKit dead? Why? - https://news.ycombinator.com/item?id=4787211 https://news.ycombinator.com/item?id=4787211 - Nov 2012 (1 comment) Why did TermKit die? - https://news.ycombinator.com/item?id=3154553 https://news.ycombinator.com/item?id=3154553 - Oct 2011 (1 comment) TermKit - a graphical terminal replacement - https://news.ycombinator.com/item?id=2559734 https://news.ycombinator.com/item?id=2559734 - May 2011 (200 comments) TermKit - Next Generation Terminal/Command Application - https://news.ycombinator.com/item?id=2542068 https://news.ycombinator.com/item?id=2542068 - May 2011 (2 comments)

euroderf 5y ago

There's no releases at the github repo. Maybe there's a mac build available somewhere? Building fails on my mac, because javascript.

naikrovek 5y ago

this seems like it could have died solely because non-web developers (almost all of whom use terminals daily, and would pay attention to this) are pretty quick to realize just how awful JavaScript is, compared to the languages they use day to day. the fewer places that JavaScript can escape to, the better, and terminals adopting anything that looks like web tech is such an alarmingly bad idea that I don't even know where to begin to address any arguments for that approach. TermKit deserved to die because of its JavaScript nature alone.

slightknack 5y ago
Like you, I am not a huge fan of JS, but I'd like to say that the ideas behind TermKit — namely having a shell with richer graphical interaction (e.g. cat works for images too), semantic awareness and tokenization of commands, rich autocomplete, etc. — were ahead of their time. Maybe it's expected that TermKit-the-project died, but I don't think that TermKit-the-idea should: whether it be bringing features from the project as extensions to existing terminals (cat for images would be nice), or building a new TermKit built on modern graphics libraries powered by WASM/Lua/bring-your-own scripting language.
- naikrovek 5y ago
  I am all about the larger intent behind TermKit, but intent alone cannot carry a project to success. A successful replacement for current textual shells will not look anything like the textual shells we have today; everything will be reimagined and will make sense, and will be very foreign to you and I. A shell with graphics tacked on is not the revolution needed in this space. Waveform Graphics, Sixel and ReGIS (please look those up if you are not familiar) came to DEC terminals in the 1970s and 1980s, and still do not have widespread adoption. The addition of graphics isn't enough on its own, with or without new programs to blend the border between text and imagery. A true leap is required to gain market share in this space. Simple evolution of the existing shell experience is just simply not enough. TermKit, Waveform Graphics, Sixel, and ReGIS effectively prove this. I can not say that I know what whatever replaces our current terminals will be, but it will not look like TermKit. Or ReGIS, or Sixel.

hnlmorg 5y ago

To those who are wishing something would fill this void, I'm working on something that does overlap with this. I've already matured the shell somewhat over the last ~8 years. That shell can inline images, manage and manipulate different document formats and convert between them, understanding data types and structures like Powershell but works natively with POSIX CLI tools (which Powershell cannot). Last year I also started playing around with WASM and building a terminal emulator in it. The idea being if I can manage the terminal emulator then I can add more features / friendlier UI/UX that might compliment non-CLI users who have been tasked with using the terminal; while power users still have access to the features of the $SHELL in their preferred terminal emulator. There is definitely overlap between what I'm doing and TermKit. The idea of doing it this way means I'm still leveraging the foundations already in common use. Opinions about whether they're ready to be deprecated aside, it's the standard everyone already uses so trying to displace that would be an even big hurdle than even just trying to displace Bash. But at least if the standards are reused and extended it does mean people can pick and chose the items that work for them rather than forcing them into an "all or nothing" type scenario. I'm not far down the terminal emulator route yet and it's definitely a task that is bigger than the time I personally have to commit to it. So I welcome any time and/or support anyone is willing to donate. I should write a blog post about this at some point too.... The shell (in it's current form): https://github.com/lmorg/murex https://github.com/lmorg/murex (docs on Github too but also accessible via https://murex.rocks https://murex.rocks )

MediumFalse 5y ago
This looks quite interesting! Thanks will check it out.

vanderZwan 5y ago

I've been using Terminology[0], which has some of these features. That's not why I'm using it though, it just happens to have the lowest latency of all terminal emulators that still does fancy font rendering on my machine. [0] https://www.enlightenment.org/about-terminology https://www.enlightenment.org/about-terminology

georgia_peach 5y ago
Thanks for this. I didn't know Terminology had so many tricks! Reading their extended escapes as I write this.

sgt 5y ago

I see plenty colors on my screen already. My shell doesn't need colors. The terminal is a dark place, but it's cosy and it's surrounded by a colorful macOS desktop. The shell is a portal that takes me to the joys of Unix.

georgia_peach 5y ago

Kitty, iTerm, Mintty, Wezterm, & many others support an escape code for base64-encoded images (gif/jpg/png). Most GUI terms also support sixel--which is highly inefficient, but gets the job done. None of that is as slick as this, but I consider that to be a good thing.

thechao 5y ago
Is Sixel highly inefficient? It's palettized, and encodes a 6b value in an 8b code. It'd be nice if terms supported "inline PPM"; those are (on average) only somewhat larger than their equivalent BMP. (Worst case is 2x, roughly.) If we had an "ASCII QOIF", you could dramatically beat BMP, most of the time, and be within 33% of a PNG, in many cases.
- georgia_peach 5y ago
  What it gives with RLE, it takes back with overpainting to have multiple colors on the same line. It is a hot mess.
- georgia_peach 5y ago
  Also, what is QOIF?
  - isaacimagine 5y ago
    quite okay image format: https://qoiformat.org/ https://qoiformat.org/

rbanffy 5y ago

Terminals are actually very rich interfaces - over decades they have developed features, such as Tektronix and ReGIS graphics, type features (double height, double width), alternative fonts, multiple windows, single-voice sounds, smooth scrolling (cute, but not that useful), and Sixel graphics. All these have been available since terminals were actual boxes on our desks with CRTs built-in. All that is described in the developer manuals for them. Unfortunately, most of these features are not supported by our terminal applications (Apple's Terminal supports double width and height, at least, and xterm can do Tektronix graphics) and libraries such as ncurses allow us to write software using many of those features having to understand the control sequences (most terminals today look like xterm). If we could push for support to these features, we'd have an already proven, probably supported by ancient software that we run today but that we never saw as intended, set of standards and functionality we could rely on. If all terminals, for instance, supported sixel graphics (a horrible standard, BTW) or DRCS (a meh one), we wouldn't need font support for character graphics (Unicode v13 has new Teletext block graphics, and 4x2 mosaics will be added soon, and libraries such as VTE implement those without font support) or "powerline" symbols.

Per_Bothner 5y ago

DomTerm (https://domterm.org https://domterm.org) attempts to provide similar possibilities as TermKit. However, it starts with the position that it should also (and perhaps first) be a fully-functional modern mostly-xterm-compatible terminal emulator. On top of that we add rich html text, images, logical structure, "shell integration", and more.

Per_Bothner 5y ago
It you like TermKit's pretty-printing of JSON, check out: https://domterm.org/saved/dt-prettynested.html https://domterm.org/saved/dt-prettynested.html Try re-sizing the window width (to trigger smart re-breaking), and clicking the little triangles (to show/hide sub-trees of the output). The actual pretty-printing is application-specific (for example the PrintNested java program at the top), but the output contains certain escape sequences to mark logical structure, optional indentation, and show/hide buttons. Note this is basically a log of a terminal session from a few years ago, but saved as HTML, along with JavaScript to respond to the window-resize and show/hide actions.

spacexsucks 5y ago

Having used emacs exwm, i3, and awesome for last 3 years straight, you dont need any of this on Linux. This is all there. Just use 'feh' if you want to 'cat' and iamge. Like wise for ffprobe, etc This for macs and winodows with literally dumb UX for development