OSS Power-Ups: XenoAtom.Terminal.UI
In a Nutshell
**XenoAtom.Terminal.UI is a high-performance, reactive terminal UI framework built with a layered architecture of ANSI sequences, input abstraction, and visual tree management, achieving efficient diff rendering, bindable properties via source generation, and 60 FPS updates through dependency tracking rather than full recomputation.** **Development relied almost entirely on AI coding agents—nearly 1,000 prompts producing 600k characters of code—enabling rapid completion of multiple stalled OSS projects including logging, command-line, and static site libraries in weeks instead of years.** **The core insight is that AI agents transform solo OSS sustainability by making complex side quests feasible overnight, increasing what one developer can ship while requiring strict guardrails to prevent code drift.**
These notes were generated by AI and may contain inaccuracies.
The session begins with the introduction of Alexander Mitel as VP of engineering at Data Galaxy, described as a C# .NET OSS author, language and compiler specialist, SIMD, HPs, HPC architecture expert, Microsoft MVP, and former demo scene participant. The OSS Power-Ups format was created by JetBrains to address sustainability issues in the open source ecosystem, where organizations benefit from OSS projects but contributions are often insufficient. The sponsorship model provides $100 per month for two years, plus sharing of strengths beyond monetary support and raising awareness through platform provision.
Alex mentions being honored to present his project and feeling stressed about presenting it publicly for the first time. The host confirms correct pronunciation of "Alexandre" as "Alex" is acceptable.
The handle "xoofx" has no specific background story. The "fx" component relates to special effects in movies or games, while "xoo" draws from the Yahoo naming convention with double "o" at the end. The creator sought a distinctive name and settled on this combination.
The demo scene originated in the 1980s as an old community focused on computers. It began with "cracktros" - small visuals with music placed before cracked games. These evolved into standalone live demos combining music, coding, and graphics. The format provided a creative way to work with computers without needing to release full games. Demos run live on CPU, handling all animations and graphics, and fostered collaboration between people with different skills like music and graphics.
The left demo shown was created for the Amiga 500 in 1991 when Alex was approximately 17 years old. The graphics, including mountains, were taken from the popular game Shadow of the Beast by Psygnosis. The demo was programmed entirely in 68K Motorola assembler with thousands of lines of code. It featured interactive elements where users could access a menu at the bottom using the mouse to change parameters like ball movement, 3D movement, and lighting configuration. The demo contained three distinct parts.
The right demo shown was a 4K (4 kilobyte) PC demo created in 2010, with music composed by a friend who also contributed to music in the 1980s and 1990s. This marked a return to the demo scene after nearly 20 years, requiring relearning with assistance from a younger developer.
Notable projects mentioned include MarkTick and Skribban. The pronunciation of Skribban follows French pronunciation. The name originates from Spanish, referring to a small desk, and was chosen for its distinctive quality. Skribban was originally a scripting language for templating.
GitHub contribution statistics show 600 to slightly above 1,000 contributions per year in past years, increasing to 2,300 contributions this year. This increase is attributed to AI agent usage. All contributions have been personal open source work during spare time, with zero company-related contributions.
Alex began using AI agents two years prior but initially only for assistance on tedious tasks rather than full project building. During holidays, he experimented with prompt engineering to build entire projects without directly touching code. This approach proved successful and enabled completion of many unfinished projects and ideas.
The presentation covers the XenoAtom.Terminal.UI framework, designed as a modern terminal UI framework rather than nostalgic or Dimoxin-based. The talk consists of two parts: the framework itself and the experience of building it with AI coding engines. The presentation mixes slides with live demos.
Alex has created numerous colorful open source projects, many niche despite some being popular. Performance enthusiasm drove the development of XenoAtom.Terminal.UI with performance considerations from the start.
The UI framework concept originated from a private prototype developed over 10 years, with attempts made every two or three years. Previous attempts focused on developing UI frameworks using Direct2D with proper GUI frameworks featuring hardware acceleration and GPU support. The goal was to create a modern, pleasant coding-first experience.
The paradigm addressed was UI recomputation when changes occur or data changes, fundamentally affecting API design and controller library experience. Approaches considered included SwiftUI's declarative functional approach, though the requirement to create both view descriptions and runtime views was rejected due to allocation concerns for .NET.
The desired approach combined WinForms/WPF-like properties with SwiftUI-like component plugging capabilities, creating a coding-first, reactive, and efficient control UI. The terminal UI format was chosen as a simpler problem space compared to previous GPU-based prototypes that required solving complex optimization and math library issues.
Development began with three separate libraries rather than a monolithic approach. The first library handles ANSI sequences for terminal colors and markup similar to Spectre.Console or Python's Rich library. This was completed in approximately one day during holidays.
The second library provides platform-agnostic abstraction over input events including mouse and keyboard events, functioning as a modern System.IO.Console class with additional input capabilities and markup integration.
The third library contains the actual UI framework with visual tree, bindings, layout, and developed controls. This layered approach proved beneficial for AI coding agent development by providing clear boundaries between components.
Mouse and keyboard events are accessed through the VT100 terminal protocol, which is normalized across operating systems including macOS and Linux when terminals support VT100 compatibility. The Windows Terminal work enabled similar ANSI escape sequence experiences across platforms.
Commands are sent as escape sequences using the escape character (one one B) that terminals interpret as commands rather than displayable characters. These sequences enable color changes and request mouse event access, with input reading capturing the resulting control ANSI escape sequences that require decoding into proper mouse and key events.
Working with terminal output to override content above the current line initially involved overriding the whole buffer, but this approach breaks when the terminal is resized. An escape sequence exists to clear individual lines, though resizing becomes complicated without using alternate screens.
When not using the alternate screen, resize handling becomes difficult due to scrolling that occurs. The cursor can move when writing, making state tracking more difficult to maintain. This complexity makes live interfaces challenging when staying in the terminal with access to the entire history of written content.
Many console apps switch to the alternate screen for this reason. The alternate screen is what appears when using applications like VI or Vim, switching to an entirely separate screen that restores the original screen upon exit.
The demo showcases a vertical stack containing a border, a rule for separation, a text block, a progress bar, and a horizontal stack with buttons and text. A callback allows plugging in exit logic or launching side tasks and long-running operations.
The reactive model uses a state class with an initial integer value that gets used across multiple components. The text box displays the value, the progress bar uses the value for display, and buttons modify the value through increment, decrement, and reset operations.
The reactive model allows a variable to be used fluently in strings and output. Changes to the state automatically update the display across all components. The demo shows the counter text and buttons working with mouse interaction, including increment, double-click, and reset functionality.
Resizing the terminal shows text wrapping behavior. The framework enables a code-first experience without registering events or reading values manually for bi-directional updates.
Clicking buttons triggers only the specific callback and progress bar rendering. The UI description remains fixed without allocating new objects when buttons are pressed. This differs from Swift UI's approach, which requires behind-the-scenes reuse to prevent excessive object allocation.
The objects function similarly to WPF or Avalonia objects with properties that can be modified. Styles can be applied to elements like borders, such as creating rounded corner support.
WinForms requires invalidation when setting values that change rendering. WPF and Avalonia require flags on properties to specify usage in measure and render operations.
Text block properties use a bindable attribute that gets implemented by the XAML Atom runtime through an incremental source generator. The generated code routes value setting and reading through a manager that tracks reads and writes, dispatching events to the appropriate places.
The system tracks usage by starting tracking before measure core calls and ending tracking afterward. During this session, dependencies are collected from reads during the measure method. The bindings list contains all properties used during measurement.
Knowing reads and tracking writes enables triggering the proper method when properties change, rebuilding controls that depend on the modified property.
Computed visuals inherit from visual and can switch controls based on state values. The UI content can be dynamic not only within text boxes but also through dynamic visuals. This resembles immediate mode UI, allowing conditional logic with if-else statements based on state values.
State functions as bindable values that track both writes and reads. When state changes, the system knows which values were read, enabling efficient rebuilding of UI components.
The layout system follows Swift UI and CSS patterns, providing richer sizing options than WPF. Swift UI can return minimum, natural, and maximum sizes, and this similar system enables building rich layouts.
Rendering optimizations include dirty rectangles that only process changed portions of the screen, avoiding full component tree traversal. A cell buffer pipeline acts as a character-based pixel system with attached colors, background colors, and styles.
Diff rendering compares previous and new buffer versions, sending only the computed differences to the terminal. Special commands maintain terminal synchronization without flickering.
Alpha blending is simulated through the intermediate cell buffer by mixing background and foreground colors, creating the visual effect despite terminal limitations.
Text correctness handles wide emojis and special characters using system text methods plus additional code for character width calculation. A debugger overlay displays rendering frame information, measure time, arrange time, and render performance metrics.
The controls demo includes a Markdown control rendering tables, GitHub-style alert controls, and code blocks without syntax highlighting. A Markdown editor provides code-editor-like visual feedback. Markup support enables displaying logos and UI elements using Nerd fonts.
The data grid supports sorting with multiple sort criteria, editing, navigation, emojis, actions, enable/disable functionality, and freezing rows. All parameters are bindable, allowing configuration of editing behavior, screen selection, and column selection.
The code editor handles 500,000 lines of code smoothly with line numbers, comments, and navigation. A fake syntax highlighter demonstrates the concept, though full highlighting requires developing a dedicated .NET library.
Other controls include color pickers, masking options, prompt editors used in coding agents, alpha blending demonstrations with backdrop filters, resizable elements, info/success/warning/error notifications, and tooltips.
The color system uses Root Loops, a project by Han Volk that provides configurable color palettes. The entire configuration can be copied to Windows Terminal for consistent theming. Parameters include sugar and artificial colors, ensuring natural colors with proper contrast levels.
The library ports the entire Root Loops system, enabling quick theme application without manual color configuration.
A regular text widget is available for creating logos, such as a JetBrains logo with proper capitalization of the letter B. A command palette provides search functionality and breakdown capabilities.
Plans exist to support images using the Kitty image protocol. A specification has been prepared, though implementation requires substantial changes across the XenoAtom stack, including XenoAtom terminal and XenoAtom terminal UI. The 6L protocol is also referenced for Windows terminal compatibility. Feature parity will vary across terminals, meaning users will experience different capabilities depending on their terminal choice. Development is driven by practical need for an AI coding agent requiring image copy-paste functionality.
Gradients provide color and animation capabilities within the UI framework.
A long lock control integrates with XenoAtom.Logging, an open source logging library from the same project. Logs can be directed directly into the log control. Performance testing shows the log control uses almost zero CPU after optimization work.
The debug layer displays pre-prepare, measure, arrange, and render phases. When no changes occur, nothing is measured, arranged, or rendered. Moving or scrolling triggers CPU usage for re-measuring and re-rendering. Full screen changes also trigger these operations. The UI runs at minimum 60 FPS, implemented like a game engine.
A Windows API introduced for Windows 10 and effective in Windows 11 provides timer precision beyond the standard 1-millisecond sleep period, which actually defaults to 15 milliseconds. This timer achieves 0.3 precision, enabling constant 60 FPS that cannot be achieved with Thread.Sleep from System.Threading.
A bug in the year control select caused an update loop that continuously rebuilt and re-rendered everything. Adding metrics revealed the issue - full rendering was occurring when it should have been zero. The debug layer proved essential for identifying such problems, particularly when developing pixel-drawing UIs.
Control-F12 triggers PNG screenshot generation directly from the terminal application. A side extension library uses SkiaSharp to re-render the cell buffer as if it were the terminal, simulating terminal rendering without capturing the actual terminal output. The same font is embedded to maintain visual consistency. This enables automatic screenshot generation for documentation websites.
Screenshots are generated automatically by running the controls demo via command line. This eliminates manual screenshot creation for websites with numerous controls. The AI coding agent can verify output by comparing regenerated screenshots against expected results, checking that control changes produce correct visual output.
ASCII cinema functionality allows recording and replay using tape files. Version numbers can be updated directly in replay files rather than regenerating entire recordings.
The extension enables direct screen capture from the library for website screenshots, AI verification pipelines, and diff verification after changes. This serves as a verification pipeline for ensuring changes don't break existing functionality.
Specifications are written most of the time, with plans created as checklists for time-intensive features. The agent performs coding work followed by verification. Line-by-line review is avoided; instead, diffs between commits are examined and invariants are verified. Development required hundreds of prompts rather than single-prompt completion.
For Terminal UI development, nearly 1,000 prompts were written, totaling 600,000 characters. The library contains 7 megabytes of text, creating a 1:10 ratio where each character typed generates 10 times more output in code and documentation. GitHub timeline reflects this - one month of AI-assisted work equals one year of previous productivity.
Work occurs from 6:00-9:00 AM, 6:00-9:00 PM, and sometimes late evenings, running concurrently with full-time employment. Night work is assigned before sleep, morning reviews occur, daytime work assignments happen, and end-of-day checks are performed.
A Ralph loop variant was implemented allowing specification of message duplication count with bounds. The UI enables sending the same message multiple times (e.g., 10 iterations) within defined limits.
Codex Pro subscription token limits have never been reached despite intensive usage patterns. The speaker questions whether other users exceed limits through improper AI usage patterns.
The primary challenge is not hallucination but drift - AI agents gradually deviating from intended patterns. Initial issues arose when measure.T and arrange.T marker methods were made public, causing AI to use them everywhere instead of the intended render-measure system. Three to four weeks of generated code required cleanup in one night. Strict rules were implemented through system instructions and runtime guardrails.
The workflow is not waterfall but iterative specification: write spec, implement, verify correctness, modify spec if needed, iterate. Documentation is written only after completion. Self-verifiability is central - the AI must check builds and tests. Runtime guardrails are essential throughout. Top-down documentation must be AI-consumable with appropriate detail levels and navigation links.
Component boundaries must be well-defined to develop XenoAtom, XenoAtom terminal, and related projects separately across different repositories. Multi-repository work is more complex than monorepos but follows standard engineering practices.
Working across many projects motivated AI coding agent development due to overhead of switching between projects, folders, and VS Code windows. Multiple VS Code extensions including GitHub Copilot were initially used.
NuGet artifacts lack skills and documentation for AI consumption. IL Spy or decompilation tools like David Fowler's Microsoft skill are required. NuGet packages need accompanying skills to help AI usage. Multiple pipeline components are unprepared for AI consumption including code navigation, debugging, coverage, and profiling.
Debugging is performed manually. Coverage checking is manual. A custom profiler created 1.5 years ago cannot be used by AI. Required improvements include table-based recaps of top time-consuming operations, caller identification, and method details. MCP or similar protocols are needed to surface this information for autonomous AI operation.
Current code navigation requires manual read and grep operations, resembling 40-year-old coding practices.
The AI coding agent has been used daily for 2-3 months across all projects. Features include previous message viewing, markdown text copying, timestamps, history tabs, concurrent multi-folder sessions, file referencing with self-links, project and folder opening, thread cleanup, and compacting functionality. The tool will be open sourced upon reaching 1.0 shippability.
AI coding agents provide speed benefits, but the most significant impact for open source projects extends beyond velocity gains.
Open source projects are always full of side projects. This isn't about mind wandering but emerges naturally when building a library and realizing another library is needed first. Everyone doing open source usually goes through this struggle. Sometimes when exploring an idea or needing a change of pace, side quests become valuable. Working on open source during spare time outside of work can be exhausting when development lasts for multiple months. It becomes difficult to stay focused for such extended periods because developers get bored with tiny libraries that take a month or two to build.
AI coding agents make side quests non-fatal because they can be completed overnight very quickly. Solo development and prototyping become super facilitated. More dreams can become true, including projects previously put on hold or never finished, including private projects. In the past three months, the following libraries have been finished with proper websites: Lunet (a static website generator), a logging library, a command line library, Scriban, Mardi, Sharp YAML, and Toml.
AI coding assistance increases the complexity of what can be built. Much bigger software with many more features and complexity becomes possible. This brings questions about whether people have the right skills or whether brains have been trained for this kind of complexity. The limitation now feels like being constrained by one's own imagination.
Many new ideas accumulate over time, with some things finished and others not. The ability to try things out and see how they feel without major commitment becomes valuable. Being able to get hands on projects or experiment with ideas allows for better decision-making about whether to pursue them.
JetBrains terminal support should work with the project, though it hasn't been tested yet. It was confirmed to work in VS Code.
The coding engine is currently being worked on. After months of working with Codex and Co-pilot, the goal is to use a custom tool because the way of working has evolved. There are still many things to add to this project.
One upcoming project involves creating a proper UI with GPU support, not just terminal-based. The Xen Atom project aims to build an experimental OS stack on Linux connected with C# and .NET. All libraries under this umbrella project are small prototypes developed four to six years ago using native AOT C# code called directly by the kernel, not through an Ubuntu distribution.
The goal isn't to claim building an operating system, which would be pretentious, but to experience the learning challenge. Working with the Linux kernel teaches many interesting things. The intention is to create something different from typical Linux distributions that use scripts, shells, and configuration loading. The goal is a more object-oriented approach that's nicer to use, potentially making the operating system more coding agent friendly.
There is interest in experiencing the challenges of UI composition with window layers. While Linux has terminal, X11, or Wayland options, the goal is to try something different with entire code developed in C# .NET. This would provide valuable experience with GPU and graphics work.
The presentation should be submitted to conferences as the content would be valuable to audiences. The live stream link could be provided as reference for conference committees.
Open source is fundamentally about collective work and sharing. It's not about individuals but about sharing work with others to make a better world. The iPhone example illustrates this - Steve Jobs didn't create it alone, but it represents thousands of years of transmitted knowledge. Open source enables sharing code that's usable by everybody, allowing bigger things to be built.
Viewers should check out the project, give it a star, follow on social media, and check the blog with demo scenes. Conference invitations would enable sharing more interesting content with audiences.
Keep JetBrains in your library
Save the videos and channels worth coming back to, and find them again in one place.
