Myra: a widget library for MonoGame, FNA and Stride

A widget set that covers the usual game screens

The feature list names the widgets, and the list is the best argument for the library. There is Label, Button, ToggleButton, CheckButton and RadioButton for the basic input row, TextBox for anything typed, Image and Separator for layout furniture, ComboView and ListView for collections, Menu and TabControl for navigation, Slider, ProgressBar and SpinButton for numeric values, Grid plus the two stack panels and Panel for arrangement, ScrollViewer and SplitPane for larger surfaces, with the split pane supporting an arbitrary number of splitters, TreeView for hierarchies, and then the heavier end with Window, Dialog, FileDialog, ColorPickerDialog and PropertyGrid. That last group is unusual in a game UI library, because a property grid and a colour picker are desktop ideas, and their presence tells you the library leans toward a form-like interface rather than a HUD. A game with a loadout screen, a settings menu and a debug console fits that. A game whose entire interface is a heads-up display over a moving scene does not, and would be better served by drawing text and sprites directly.

MML is the declarative layer, and it is a file you can review

The second feature is the Myra Markup Language, an XML-based declarative language to describe the interface, and this is what makes the library a design tool rather than just a set of classes. Instead of constructing the widget tree in code, the layout lives in an .xmmp file, and the readme links an example of the all widgets sample. The practical consequence is that the interface becomes data. A designer can open the file, a designer tool can write it, and a code reviewer can diff it, and none of that requires the person making the change to know C#. The MML file is also what the WYSIWYG designer, MyraPad, produces, and what the newer MCP server reads and writes. That last point is worth spelling out, because it is the reason the library is interesting in 2026. The Myra.Mcp package is described as a headless Model Context Protocol server so that AI coding agents such as Claude Code and Codex can validate, read and save Myra .xmmp layouts through the real engine, and can discover the widget vocabulary.

Skinning, and the fact that the default look is borrowed

The third feature is skinning, and the details matter more than the headline. The default skin is borrowed from VisUI, which is a MonoGame port of a Windows Forms visual library, and it can be replaced with a custom skin loaded from XML, with an example of a custom stylesheet in the samples. The consequence of the default being borrowed is that a game using it out of the box will look like a desktop application, which is fine for a management screen and wrong for anything with a strong art direction. The sample list shows how much room there is to move, with a Commodore 64 skin among the gallery images, samples for custom brushes, for rounded corners, for scaling, for a debug console, and samples for a data grid, a notepad, an object editor and a non-modal window. There is also a sample that integrates a charting library and one that integrates a 3D scene, which suggests the widget layer can host foreign renderers. The custom widget samples are per widget, with arrow, log view and data grid variants, which tells you the extension point is a widget rather than a fixed set.

MyraPad, and the engine-agnostic build

Two of the features are about how you work rather than what you ship. MyraPad is a standalone WYSIWYG MML based UI designer, which is what makes the markup approach practical, because designing a layout in a text file without a visual tool is miserable and designing it in the engine without a file is worse. The second is Myra.PlatformAgnostic, described as a version of the library that could be used in any C# game engine, and the samples show what that means in practice, with platform-agnostic samples for MonoGame, for OpenTK, for Raylib, for Silk.NET, for Silk.NET.TrippyGL and for OpenTK. The point of that package is the dependency surface. A game built on one of those engines cannot use the normal Myra package without pulling in a rendering backend it does not have, so a separate build without the backend is the way to use the widget layer elsewhere. It is also the reason the library is a MonoGame and Stride library first, since those are the engines where the full package works.

How the samples are laid out, and what they tell you

The samples directory is the most informative part of the repository, and its shape describes the library's capabilities more precisely than the feature list does. There is a sample for every widget, an Android variant of it, samples for asset management, custom brushes, the custom stylesheet, the custom widget variations, a data grid, a debug console, a fixed size layout, a grid container, non-modal windows, a notepad and an object editor. Several of those are not widgets in the list at all, which means they are combinations, and a grid container, a fixed size layout and a scaling sample together describe the layout system: containers that nest, widgets that can be pinned to a size, and a mechanism for scaling the interface. The platform-agnostic samples sit alongside, and the two engine-specific ones for the ObjectEditor and DataGrid. The credits list the projects the work draws on, which includes MonoGame, FNA, Stride, MonoGame.Extended, VisUI, LibGDX, a bitmap font library, the stb single header libraries and a text copy helper, and the repository root carries a licence file for each of the third party pieces alongside the main licence.

How it is built, and how it is distributed

The build is a plain .NET solution workflow, and the readme keeps it short. To build from source you clone the repository and open a solution from the build folder, and the repository root has that build directory, a Directory.Build.props file for shared MSBuild properties, a docfx directory for the documentation generation, an assets-raw directory for the source artwork, a samples directory and the src directory holding the packages. The packages published to NuGet are visible from the badge and the names used in the feature list, with Myra, Myra.Mcp, Myra.PlatformAgnostic and MyraPad as the separate artefacts, plus a Myra.MonoGameExtended licence file at the root indicating a variant that depends on that library. The release cadence is steady, with 1.6.8 on 2026-10-18, 1.6.7 on 2026-10-05 and 1.6.6 on 2026-09-11, so patch-level changes are landing weekly or better, and the project also publishes a beta build through its own workflow. There is a Discord for support and a documentation site at the MyraUI GitHub pages address. Sponsorship is offered through a few channels, including a Telegram wallet and a TON cryptocurrency address.

Editorial conclusion

Myra is a good fit for a game developer who has a menu, an inventory or a settings screen to build and does not want to hand-place and hand-theme every control, since the widget set covers the common cases and the MML markup lets a layout live in a file a designer can edit. It is the wrong tool if you are building a custom-rendered interface that does not follow a desktop metaphor, since the widgets and the skin are built around one, and it is the wrong tool if you need a UI that scales to a hundred widgets in a scrolling view, where the immediate-mode friendliness of the underlying engine tends to break down. It is also the wrong tool if you are on an engine outside the three it targets, since the platform-specific packages are the point of the library. Before adopting it, look at the all widgets sample to see how much of the look you want to keep, and remember the default skin is borrowed from VisUI, so a game that has its own art direction will want a custom one. The project is MIT licensed, the last push was on 2026-10-18, and the current release is 1.6.8 from the same day.

Frequently asked questions

Official sources

1. License: MIT
2. MyraUI/Myra on GitHub
3. Project website
4. README
5. Releases