Getting Started
How WPF-style UI maps here
In WPF, you describe a tree of controls in markup, connect data through bindings, and let the framework handle layout, input routing, and rendering. InkkSlinger keeps that mental model, but it runs inside a MonoGame UiRoot instead of a native WPF window.
The shortest useful way to think about it is: WPF-style authoring and behavior, MonoGame as the rendering host. You still build a visual tree, you still use DataContext for bindings, and you still write views in XML. The difference is that MonoGame owns the frame loop and InkkSlinger draws your UI inside that loop.
How the pieces fit together
1. Write a view in XML
InkkSlinger views live in .xml files, not .xaml. You still use WPF-style concepts like x:Class, x:Name, resources, and bindings.
2. Add code-behind if needed
A paired .xml.cs file can set up the view, assign a DataContext, or directly update named controls for simpler screens.
3. Mount the view into UiRoot
MonoGame creates the window and runs the frame loop. InkkSlinger attaches your root view to UiRoot, then handles layout, input, animation, and drawing from there.