INPE's satellite simulator UI is now powered by Tachikoma.jl, and it is amazing!

[Ronis_BR]

Hi!

Some of you know that one of our biggest accomplishments here at the Brazilian National Institute for Space Research (INPE) was to build a validated satellite simulator that is being used in all phases of the attitude and orbit control subsystem (AOCS) development. I always knew that one day I will need a proper TUI to allow me to debug the algorithms more easily than wait for execution and analyze the results.

Hence, 7 (SEVEN!) years ago, I started to code TextUserInterfaces.jl, which is a NCurses wrap with a TUI framework on top. However, due to a lack of time, poor decisions, and technical limitations of the NCurses library, I could never really have something good.

Then, @kahliburke released Tachikoma.jl, which is a terminal framework to build TUIs comparable to Bubbletea and Ratatui. I tested a little bit, and it was amazing. The number of features available there is mind-blowing. Thus, I decided to migrate my old UI project from TextUserInterfaces.jl to Tachikoma.jl. The result is just amazing:

The world map is rendered using GLMakie. The OpenGL frame buffer is copied directly to the Tachikoma.jl widget and shown using the Kitty graphics protocol. The rendering is happening almost in real-time, meaning that I have no noticeable slowdown in the simulation speed given the TUI rendering steps. The ability to show images like this made me abandon the UI project I had using Genie.jl. Genie.jl is amazing, but it is significantly slower to show this kind of information.

Another very good point is how everything in Julia is integrated. I need three packages only to show this world map: GeoMakie.jl, GLMakie.jl, SatelliteAnalysis.jl. Hence, if I want to see the simulation without the waiting time for loading everything, I can just use Tachikoma.jl and the Julia extensions take care of everything.

I think this is a very nice use case of how the Julia ecosystem can be integrated to achieve amazing results. I also want to thank @kahliburke for the amazing work in Tachikoma.jl!

[Ronis_BR]

The integration with PrettyTables.jl was so easy

[Ronis_BR]

Being able to use Kitty graphics in the terminal with almost no slowdown as we have in Tachikoma.jl is a huge win! I can already imagine so many cool things we could do with this kind of feature.

[sschmidhuber]

That looks awesome.
What were the main reasons for you to implement the UI as TUI instead of a GUI or a Web based solution?

[Ronis_BR]

Thanks!

I tried a few different approaches. Here’s what I learned:

1. The first idea was to use QML.jl. However, it turns out that QtGraphs is licensed as GPL. Hence, the entire simulation would need to comply with GPL when shipping it, which is a no-go.
2. Then, I switched to Genie.jl. It was easy to build the UI and to integrate CairoMakie.jl to show the plots. However, it was really slow to update all the values in some views. Maybe it is related to exchanging the value between the frameworks?

Finally, I tried Tachikoma.jl, and since it is entirely built in Julia and does everything in the terminal, displaying data and creating new features in the UI is really easy. This was the first approach in which I see the simulator almost without performance degradation.

[prittjam]

and how do you plot? is it possible to use Makie in Tachikoma?

[kahliburke]

@prittjam Yes, and I also fixed the issue with GLMakie earlier today. I’m also working on a new backend TachiMakie but it’s not quite ready yet.

[ArchieCall]

I love the name! Wow.

[Ronis_BR]

In Tachikoma.jl you can easily copy the GLMakie framebuffer and show it using Kitty graphics. Hence, it is blazing fast! Way faster than using CairoMakie.jl.

[prittjam]

yes very nice work and thanks! I am using Kaimon now.

[prittjam]

Ive never tried the world of terminal graphics. Is there some catch? e.g. is it possible to marry a tui with graphical displays? This could be very nice for scientific programming where a TUI may be very clear and straightforward. But still you can display 2d and 3d visualizations.
I wonder how this style compete with something like CimGUI, which is also tailored for such things.
What makes a TUI compelling over CimGUI?

[Ronis_BR]

Right now, using Tachikoma.jl, you can have pretty much everything in the terminal if you use a modern emulator (like Ghostty). However, when @kahliburke release the Makie backend, everything will be way easier since it will be straightforward to use Makie to draw those kind of figures.

[kahliburke]

I don’t want to take over @Ronis_BR’s thread here, so we could always split this off or move to the Tachikoma.jl announcement thread to continue this, but I’ll answer here for now. (mods – feel free to move if you want)

@prittjam

What makes a TUI compelling over CimGUI?

Well, first, I think it’s fine to have multiple options for things, your needs and use cases may be different. So I’m not trying to promote a “one-size-fits-all” approach. ClmGui.jl is really good as well, I’ve experimented with it a bit for some other projects.

Some advantages of the TUI approach from my perspective:

• Robust in a lot of situations involving SSH and remote servers.
• It’s just kind of quick and nimble to get up and running.
• Agentic AI works in textual representation, TUI fits this naturally and agents seem to ‘grok’ it and be efficient with it.
• It’s a natural fit with Julia’s REPL and terminal based tooling.
• It’s fast and responsive with little effort.

My goal is actually to try to blend a few of these approaches together and allow them to communicate with one another so we can have the best of multiple worlds. I haven’t looked specifically at how TUI could somehow blend with ClmGui.jl but it would be an interesting exploration … ?

[prittjam]

well if you pull off performant Make in a TUI then that will be a compelling and unique setup. it seems a lot has been done. what about state management? I guess CimGUI is stateless and polls on every iteration of the event loop. what are the plans on Tachikoma.jl? Contrast CimGUI with Qt, e.g..

[goerz]

@prittjam

Ive never tried the world of terminal graphics. Is there some catch?

There are definitely a few catches:

• You have to run one of the “modern terminal emulators” that support these. Fine for power users. But if you have to manage less-technical users, it’s already difficult to get them to do anything that involves the terminal. If you want them to now use a “modern” terminal (i.e., not the terminal emulator that is pre-installed on their system), that’s a whole different story.
• There are often “bugs” (or misunderstandings of poorly specified protocols) in the various terminal emulators that make graphics display not always work exactly as expected.
• It can be difficult to get this working through SSH. You need to fiddle with environment variables being forwarded.
• It is extremely difficult to get this to work inside a terminal multiplexer like tmux. You’d need the correct version of tmux, configure forwarding of escape sequences, worry about TERM environment variables, etc.

Basically, terminals are a surprisingly complex system, and image support is extremely “brittle”. But when you can get it to work, it’s awesome!

If your workflows don’t include SSH or tmux, it’s usually pretty doable, and more than worth looking into

[prittjam]

thanks for the reply. Yes I think the ask to download a modern terminal emulator seems trivial for us but is actually a big ask for users or clients of the app. and even though a TUI workflow may actually be more elegant, users may just be put off because its the terminal. Still i think the biggest block is the extra download/setup.