Well gang, there’s always room for improvement, so here’s a little version bump for you tab lovers:
Turns out widgets work better when they can think for themselves. Keys, mouse, overflow. Backwards compatible, opt in for more automatic input handling.
Release notes: Release v1.1.5 · kahliburke/Tachikoma.jl · GitHub
The think tanks have been upgraded - 100% more alpha channel.
Tachikoma.jl v2.0 is out! This is a major release that reworks the pixel rendering pipeline and introduces a type-safe widget styling system.
Three breaking changes that couldn’t be done incrementally:
RGBA everywhere. The pixel pipeline previously used ColorRGB with a background sentinel to represent transparency — fragile and error-prone. v2.0 uses ColorRGBA throughout. Transparency lives in the alpha channel where it belongs. The bg parameter is gone from every encoder.
Widget styling via type dispatch. TabBar and Button used a growing list of kwargs that was becoming unwieldy. v2.0 replaces this with type-parameterized decorations:
TabBar(labels; tab_style=TabBarStyle(decoration=BoxTabs(box=BOX_HEAVY)))
Button("Submit"; button_style=ButtonStyle(decoration=BorderedButton()))
Subtype TabDecoration or ButtonDecoration to create custom looks. Old kwargs removed — clean break.
More widgets will be reworked with additional styling in the future, but this should not require any breaking changes to the API.
FloatingWindow on_render gains a frame parameter, enabling pixel graphics inside floating windows.
Multiple render_rgba! calls per frame are alpha-composited into a shared framebuffer. A text mask algorithm splits sixel output into rectangles that avoid covering terminal text — so Makie plots in floating windows can have visible titles. Previously impossible with sixel.
The same type system is built in natively for terminals compatible with the kitty gfx protocol.
If you’re not using one of these terminals that support these features, well go get one of them, you’re missing out! Windows users should specifically check out the kitty support in recent versions of VSCode.
to_rgb/to_colortype conversion for Makie/Colors.jl interop. Auto-activates, zero cost if unused.set_light_mode!().flash_style function and flash_frames duration (thanks @ronisbr!).Feedback and issues welcome!
As an example of the functionality the new RGBA system allows, this is possible in Sixel now. In the attached demo I’m using a new Makie.jl backend that’s a work in progress. Keep an eye out for it soon – TachiMakie.jl.
It’s also possible and pretty straightforward to connect the pixels generated by GLMakie to the pixel rendering support as @Ronis_BR has done with his very cool satellite sim system described in this topic - INPE's satellite simulator UI is now powered by Tachikoma.jl, and it is amazing! - #2 by Ronis_BR
Wow, looks like some awesome features!
I’m unfortunately (?) a long-time user of iTerm on macOS; which terminals on macOS would you recommend that support this?
I use iTerm2 all the time. Also kitty and ghostly are good. I just meant if you were on Windows mainly. Also the standard Apple Terminal.app is not great.
The video animation I posted above was done in iTerm2.
Fantastic work. Looking forward to playing around with it. 
I have been using Tachikoma.jl in ghostty and the experience is just amazing! Ghostty is a little faster than Kitty in macOS probably due to the Metal integration.
@Ronis_BR has been sending fun requests my way, a little earlier today he asked if there was a way to have a sort of virtual terminal space that would extend beyond the bounds of the displayed characters. While Tachi already had ScrollPane for scrollable text content, he said he wanted to be able to do this with arbitrary widgets.
Well it only took about 130 lines of code to create a new widget type which allows embedding arbitrary widgets inside of a virtual terminal space with mouse support for panning inside. Check it out!
The instructions for using the demos/Tachikoma do not work on win11.
using Pkg
Pkg.activate("demos/TachikomaDemos")
Pkg.instantiate()
using TachikomaDemos
launcher() # interactive menu
When I run those commands at https://github.com/kahliburke/Tachikoma.jl#demos
from the win11 REPL for julia LTS (1.10.9), I get the following:
julia> using Pkg
julia> Pkg.activate("demos/TachikomaDemos")
Activating new project at `C:\Users\me\demos\TachikomaDemos`
julia> Pkg.instantiate()
No Changes to `C:\Users\me\demos\TachikomaDemos\Project.toml`
No Changes to `C:\Users\me\demos\TachikomaDemos\Manifest.toml`
julia> using TachikomaDemos
ERROR: ArgumentError: Package TachikomaDemos not found in current path.
- Run `import Pkg; Pkg.add("TachikomaDemos")` to install the TachikomaDemos package.
Stacktrace:
[1] macro expansion
@ .\loading.jl:1842 [inlined]
[2] macro expansion
@ .\lock.jl:267 [inlined]
[3] __require(into::Module, mod::Symbol)
@ Base .\loading.jl:1823
[4] #invoke_in_world#3
@ .\essentials.jl:926 [inlined]
[5] invoke_in_world
@ .\essentials.jl:923 [inlined]
[6] require(into::Module, mod::Symbol)
@ Base .\loading.jl:1816
It seems a little odd that you don’t need a specific directory to use
the activate call.
This was amazing! I tried here and it is so smooth. I remember that I faced so many problems to design something similar in TextUserInterfaces.jl with NCurses.jl.
Thank you very much @kahliburke !!
It looks like it might be something related to the way paths, directories are handled but if you are able to activate the project at the correct location, the demos should function.
Honestly Windows is a bit of a sore spot for this project. I have put some effort into making it functional, at least modestly so, on Windows. However it’s not my development environment and I haven’t had a good testing setup for digging into issues. I have tested and seen Tachikoma work on Windows, so I know it’s not a lost cause.
One issue with Windows is that the terminal support is generally far behind the Unix world and many of the things I want to do with this framework depend on the modern capabilities of terminal applications like iTerm2, kitty, ghostty, Wezterm, etc. There just isn’t the support for some of the more advanced features out of the box on Windows.
If you’d like to assist me in improving the Windows support, I would of course love it to run great as widely as possible, but I honestly could use the help. I’ve been responsive to bug reports and PRs on GitHub, please file an issue, submit a PR, contact me here in chat, etc. if you want to use this and are willing to invest the time. Regardless thank you for the feedback, I look at every issue mentioned.
I think “new project” here indicates that nothing was found at the given path. Maybe it should be something like Tachikoma/demos/TachikomaDemos (or you’d need to cd to the root of the Tachikoma project before issuing your command).
First window management and now panning? I was going to say “guys, we already have window managers/compositors, you’re not going to beat that” but I suppose it could be useful to provide a GUI over ssh 
Also, it can be really useful to have terminal UIs up when you’re spending a lot of time primarily in IDEs like VSCode, or Emacs. There is also a very interesting intersection of these primarily text based UIs with the agentic AI coding assistants. Because the UI itself is in the natural representation system of these tools, I am finding them to be very good at constructing UIs for a variety of purposes. I have several projects in the works at the moment that are built on top of Tachi and it’s proving to be, for me at any rate, a productive experience.
Yes that would probably be the primary use case I would envision for Tachikoma for my workflow. BTW I’ve started testing Tachikoma in Emacs, and my first impression (based on demos) is that vterm seems to be useable (although not as fast as e.g. kitty).
That’s good to learn, thanks! I haven’t tested there at all. Do any of the pixel graphics demos function?
I think there might be a difference in behavior between Julia 1.10 and 1.12 here? Hoping that you were able to navigate through that?
Not sure exactly what you refer to here…
The “Chart” demo works well if that’s what you mean. I can try to run another demo and report back here if there is anything specific you’d like me to try.
I agree that the instructions break on Win11. TBH, that’s fairly easy to work around. Happy to provide further input if requested.
However, there are also problems with event handling on Win11. Running demos using both WezTerm and Windows Terminal, some events are not captured properly:
Ctrl-M is interpreted as Char(13), i.e. as :returnRunning demos in a WSL (openSUSE-Leap-16.0) instance (in Windows Terminal) works exactly as expected.
I’d be happy to contribute to discovering ways to deal with this.
I’m not surprised, like I said, I haven’t had the testing environment to really dig into it. If you’re interested in improving compatibility here, I’m certainly open to the help. As for input testing, I have a testing helper script which I used, alongside Claude code, to help work out some of these terminal related nuances in the Mac/linux space. I’ll ping you on chat about it.