IS InkkSlinger WPF-style UI for MonoGame/DesktopGL

Framework overview

Desktop-style UI primitives in a real-time MonoGame host.

InkkSlinger is a custom UI framework built on MonoGame DesktopGL. Its core direction is WPF-style authoring and runtime behavior: dependency properties, routed events, XML-driven views, resource dictionaries, styles, templates, bindings, commanding, animation, and a broad control set running inside a game loop.

See verified status Build and run
  • 315 framework source files under UI/
  • 988 release tests currently discovered
  • 84 XML view surfaces under Views/

Host

Main app targets net9.0 and uses MonoGame.Framework.DesktopGL.

Authoring

Views are authored as .xml, not .xaml, with code-behind and generated members.

Status

Release build is clean and the release test project currently reports 987 passed, 1 skipped.

Evidence snapshot

Verified directly from source and a local release build/test pass on .

This page is based on the current repository state, not on the stale README, TODO list, or UI folder map. The numbers below come from a direct source audit plus a release build and test run.

Source

315 UI files

Across animation, automation, binding, controls, layout, rendering, text, resources, styling, templating, and XML loading.

Controls

119 control files

Buttons, containers, data grid, input controls, items controls, panels, primitives, scrolling, selection, and adorner infrastructure.

Tests

988 total tests

987 passed, 1 skipped in the current release test run. The test project itself targets net10.0.

What is implemented

The framework surface is broad, and the code is organized like a UI stack rather than a widget demo.

The current tree includes a dependency property system, routed events, dispatcher enforcement, layout composition, resources, styles, triggers, templates, animations, commanding, XML loading, collection views, rich text/document infrastructure, automation peers, and a large set of controls and containers.

Authoring model

XML + source generation

  • Views are stored as .xml with WPF-style x: metadata.
  • x:Name drives generated members and generated InitializeComponent.
  • App.xml is loaded at startup as the application resource root.

Property and event system

WPF-style foundations

  • Dependency properties with metadata, coercion, value sources, and invalidation paths.
  • Routed events with preview/bubble style dispatch.
  • Dispatcher thread verification for UI access.

Styling and templating

Resources, styles, triggers, templates

  • Resource dictionaries and merged dictionary support.
  • Implicit and explicit styles, setters, event setters, and trigger actions.
  • Control templates, data templates, template binding, and visual-state-style behavior.

Binding and commanding

More than one-way text binding

  • Binding, MultiBinding, PriorityBinding, BindingGroup, validation, and update filters.
  • CollectionView and CollectionViewSource surface for filter/sort/group/current-item behavior.
  • Routed commands, command bindings, input bindings, access keys, and menu-mode input tests.

Controls and containers

Broad desktop control surface

  • Buttons, text inputs, password box, slider, progress bar, calendar, and date picker.
  • ListBox, ListView, TreeView, Menu, ComboBox, TabControl, ScrollViewer, ToolTip, Popup, and Frame.
  • DataGrid, DocumentViewer, RichTextBox, Window shell wrapper, adorners, and virtualization primitives.

Text and documents

Rich text is a real subsystem here

  • Shared text layout and runtime font rendering services.
  • Flow-document model, editing operations, serialization, and document layout engine.
  • RichTextBox formatting/navigation/list/table operations and DocumentViewer navigation coverage.

Automation and diagnostics

Not just rendering

  • Automation peers and attached automation properties.
  • Tested patterns include invoke, value, selection, scroll, and expand/collapse.
  • XAML diagnostics and telemetry snapshots exist for input, draw, layout, and retained rendering.

Runtime model

The UI root is explicitly phase-driven.

The runtime is not pretending to be WPF internals. It is a MonoGame-hosted UI pipeline with a WPF-inspired programming model. The current UiRoot update phases are:

  1. Input and events
  2. Binding and deferred work
  3. Layout
  4. Animation
  5. Render scheduling

By default, the runtime enables retained render lists, dirty-region rendering, and conditional draw scheduling. It also exposes metrics snapshots for draw/layout skip counts, dirty-rect coverage, retained rebuilds, visual-tree work, and input routing cost.

The sample host uses a composited UI render target, prewarms typography when possible, and suppresses draws on idle frames when the UI does not need repainting.

Test concentration

The suite is deep in the areas that tend to regress.

  • 12 XAML-focused test files cover parsing, markup extensions, resource loading, and compile directives.
  • 11 automation-focused test files cover peer tree sync plus core provider patterns.
  • 11 render-focused and 11 rich-text-focused test files target retained rendering, invalidation, and document behavior.
  • Additional focused buckets exist for DataGrid, Calendar, DocumentViewer, ScrollViewer, layout, resources, menus, and windows.

Validation surfaces

The repository is framework-first, but it ships with a large set of live demo surfaces.

There are currently 84 XML views under Views/, including a controls catalog host that boots inside the MonoGame app and can instantiate a large catalog of supported controls.

Current boundaries

This is the important part if you want to use the framework seriously.

The repository has enough real surface area to be worth exploring, but it still has clear edges. Those edges are visible in code today and should be treated as current constraints, not future promises.

Platform

Text backend is Windows-only right now

The installed-font catalog and FreeType-backed runtime text renderer both gate on OperatingSystem.IsWindows(). MonoGame uses DesktopGL, but the current text path is explicitly Windows-focused.

Missing controls

Three catalog entries are still placeholders

InkCanvas, InkPresenter, and MediaElement appear in demo/catalog surfaces, but the framework does not currently provide real UIElement implementations for them.

Input scope

No touch or stylus pipeline surfaced yet

The current input stack covers keyboard, mouse, access keys, gestures, focus, and text input. A source search does not show a stylus or touch input surface in the runtime input layer.

Build and run

Current local verification commands.

These are the commands I used to validate the current state of the repo for this page. 

dotnet build InkkSlinger.sln -c Release -v minimal /m:1
dotnet test InkkSlinger.Tests/InkkSlinger.Tests.csproj -c Release -v minimal
dotnet run --project InkkSlinger.csproj