Re: [dev] TermKit

Sometimes I would like to display some graphics inside terminal window.
We could draw directly in terminal's window or place graphics inline
with text. I would prefer second method.
One of the key features of text terminals is monospaced font - that
makes everything easier to align and easier to code. As I said I would
like to display some graphics, but I don't want to give up on grid
aligned display. I would prefer to display graphics within text.

Applications of this approach:
- list graphical files with thumbnails
- display images from remote host
- display images from mail attachments

But for this to make sense program in many cases needs to know width
and height of image in terminal characters.
Implementation? Maybe whole image in one chunk: escape sequence, width,
height, binary image data.
Or maybe many chunks in size of character: escape sequence and binary
data. Aspect ratio would be the most important factor, besides that
terminal could scale chunks.

I hope that you can understand me. ;)

On Fri, 20 May 2011 13:26:56 +0100
Connor Lane Smith <cls_AT_lubutu.com> wrote:

>Hey,
>
>On 20 May 2011 12:51, David Tweed <david.tweed_AT_gmail.com> wrote:
>> Certainly the general implementation, the language and the
>> architecture do seem nasty. OTOH, it always depresses me that it's
>> kind of taken as a virtue that the interactive shell and the terminal
>> are know almost nothing about each other
>
>fwiw, I agree. TermKit appears to be a very glossy turd, but there are
>certainly outstanding issues in our terminals, which is why in Plan 9
>they tried to fix them by pairing a plaintext-only Rio term with
>graphical windows which actually replace the spawning term. It's not
>perfect, but the plaintext / graphics dichotomy does make things
>simpler in some ways.
>
>I think the way to solve this problem is not to add structure to pipes
>(which tend to be simple to use *because* they have no real
>structure), but to allow commands to draw directly to the terminal if
>they wanted. So the standard input / output piping system would remain
>unchanged, and all commands -- except those which rely on unhygienic
>escape codes, like curses -- would work just like normal.
>
>However, if the command would like it could communicate directly to
>the term and say "show this diagram", or whatever. The term would
>basically be an ever-downward-scrolling canvas, which shows mostly
>text but may occasionally display simple graphics too. It would need
>some experimentation to find out what the best system would be, but
>ultimately it's just the Plan 9 approach except the drawn information
>is printed onto the term itself, and thus scrolls with it, rather than
>replacing the term entirely.
>
>This doesn't inherently solve every problem you mentioned, David, but
>it would probably be a good first step toward an innovative new
>terminal, and would be less vain than TermKit's approach.
>
>Thanks,
>cls
>
Received on Fri May 20 2011 - 16:25:56 CEST