Terminal emulator with glumpy backend

[zokrezyl]

I know that this is not the best channel to make a little announcement, but I thought you may be interested to add reference to the project somewhere in the source code or your website:

I am happy to share with you that your gloo-terminal was a great inspiration. I took that example to the next level, combined glumpy with libvterm and the result is a real (almost) full featured terminal emulator. The project wants to be something much more than a dump terminal emulator, but details will come on the projects github place. It is in a very early stage, but/and any suggestions, critics are more than welcome on: https://github.com/zokrezyl/asciterm/issues/2)

https://github.com/zokrezyl/asciterm

[rougier]

That's fantastic ! It is something I wanted to do at some point but never found the time to. You might also want to have a look at kitty (https://sw.kovidgoyal.net/kitty/) for inspiration on useful feature.

[zokrezyl]

Am happy you like it. I know about kitty. I proposed these ideas to the kitty author but he seemed to be extremely uncomfortable with them. At the end I am happy that libvterm exists, the Neovim guys and other teams are taking care about the good health of libvterm. Just added a new commit for the custom escape sequence processing. This allows "client" programs to cat/display OpenGL (and in future all sorts of extensions) programs in the terminal,

[rougier]

I made a proof of concept for such terminal a few years ago but unfortunately, I cannot get my hand on the sources. Roughly, I made a GL backend for I Python such that you were able to run IPython inside the term.

[zokrezyl]

How was the guest (iPython) feeding the "OpenGL" to the terminal (host), through escape sequences?

[rougier]

There was a special command to display (and interact) with an OpenGL context.

[zokrezyl]

Not sure I understood. When I am talking about a terminal I am thinking about two processes: one process (host) that is doing the rendering and the other process (guest) is sending "stuff" to render. How were you thinking to send those commands from the guest. Or you had a program that felt like terminal and was doing rendering itself.

[zokrezyl]

@rougier , wonder if you could help me with this: https://github.com/zokrezyl/asciterm/issues/5

Basically I would like to make the terminal available for both groups glumpy and vispy users... Thus need to find the smallest common denominator. The idea is to allow asci escape sequences that work on both and other ones that work only on vispy or glumpy

Thanks in advance.

[rougier]

Both glumpy and vispy manipulate the viewport coordinates whute heavily in some circumstances and I'm not sure there's an easy nor automatic way to "convince" them they have to use a mini-window. Maybe at the GL level it is possible but I'm not even sure.

[zokrezyl]

Hi @rougier . solved the viewport in a very simple way, honestly inspired by the viewport transform of glumpy... This now works for both glumpy and vispy backends. Have a look at the demo gif:

https://github.com/zokrezyl/asciterm

[rougier]

Impressive ! I remember transforming a GL context into a static image each time I open a new one but obviously you don't need to. Do you plan mouse interaction ?

[zokrezyl]

Yes, already experimenting with mouse. It will be possible to inject the mouse pointer relative and absolute positions along with absolute and relative time etc. as uniforms in both shaders, both explicitly (declaring 'uniform vec2 mouse' or implicitly based on program attributes sent as ansi escape sequence. Did not give any thought though on how to make the mouse position along with other info available to the client program, or any other data.

[zokrezyl]

https://github.com/zokrezyl/asciterm/blob/master/examples/voronoi.py : example on how to use the mouse. Using some specific "dollar" macros you both make some uniforms available and prepare the code for "viewporting"