.NET Standard UI

.NET Standard UI enables building UI, especially controls, that runs across multiple UI frameworks - WPF, UWP, WinUI, Xamarin.Forms, .NET MAUI, Uno, Avalonia, and more. A .NET Standard UI control is a single .NET Standard assembly, that works on all supported UI frameworks.

.NET Standard UI is similar in some ways to XAML Standard, but this is a binary standard, not just aligned naming conventions. A binary standard is much more useful, at it allows writing shared code. The standard objects can be used from XAML or from code.

The standard includes APIs needed to create controls that use drawn UI - shapes APIs (for the drawing), visual states, layout (e.g. Grid and StackPanel), core input event handling, and core accessibility support. It may grow in the future, but that's the initial scope.

API names most closely match UWP/WinUI, but should be familiar to WPF and Xamarin.Forms develepers as they are pretty similar.

Value Propositions

.NET Standard UI aims to help solve these problems:

Grow the .NET UI control ecosystem - Writing a single control that can target several UI frameworks means it's easier to write controls and they can target a bigger set of users. If I'm writing say a chart control or a fancy radial gauge, no longer do I need to write separate versions for WPF/Xamarin.Forms/UWP/WinUI/Uno or create my own platform wrappers to share code. .NET Standard UI essentially has the wrappers built in, allowing a single control assembly. This helps control vendors, community members that build controls, and Microsoft as it builds out first party controls - cheaper + wider reach should mean more controls in the ecosystem. For Microsoft controls, possibilties include cross platform Fluent UI or controls that interoperate with MS services, like the MS Graph controls here.

Reduce .NET UI Fragementation - Today there are multiple XAML UI frameworks (WPF, UWP, WinUI, Xamarin.Forms, .NET MAUI, Uno, Avalonia, etc.). All are pretty similar, though slightly different. For the most part they don't share code. The naming differences are annoying. The binary API differences mean you can't write code (like controls or tools) that work on multiple UI platforms. .NET Standard UI helps here by taking a subset of the object model (the subset needed to create controls with drawn UI) and standardizing it. Using a subset makes the problem more tractable - it's not a single unified XAML object model for everything (not yet in any case), but it's a significant step in that direction. As the standard is based on WPF/UWP, it means that it isn't a big leap to take an existing WPF/UWP control definition (something like this for instance, contructed out of shape primitives, visual states, and storyboards) and make it a cross platform control.

Architecture and APIs

The API is interface based. For instance, an ellipse is Microsoft.StandardUI.Shapes.IEllipse. Users of the API always use the interface.

In terms of implementation, UI platforms can implement the interface directly OR it can be implemented by a wrapper object (which typically lives in this repo). Having both options available provides maximum flexibility.

For new UI platforms, like WinUI3 and .NET MAUI, ideally they have their native Ellipse object implement IEllipse directly. That helps enforce API naming consistency and is slightly more efficient.

Or the interface can be implemented via a wrapper, which requires no changes to the underlying UI platform at all. That's a good choice for platforms like WPF.

The API interfaces are all defined here. Implementations for the different UI frameworks are created through a mix of code generation from those interfaces and hand coding.

This project is an evolution of my XGraphics project, taking it beyond just shapes.

Current APIs

Control hierarchy

IUIElement, IUIElementCollection, IControl, IUserControl

Shapes and Drawing

Shapes: IShape, IEllipse, ILine, IPath, IPolygon, IPolyline, IRectangle

Geometries: IGeometry, IArcSegement, IBezierSegment, ILineSegment, IPathFigure, IPathGeometry, IPathSegment, IPolyBezierSegment IPolyQuadraticBezierSegment IQuadraticBezierSegment

Transforms: ITransform, IRotateTransform, IScaleTransform, ITransformGroup, ITranslateTransform

Brushes and Strokes: BrushMappingMode, FillMode, GradientStreamMethod, IGradientBrush, ILinearGradientBrush, IRadialGradientBrush, ISolidColorBrush, PenLineCap, PenLineJoin, SweepDirection

All of these APIs are nearly identical to UWP, WPF, and Xamarin.Forms 4.8 (which added shape and brush support).

Shapes are IUIElements that can be used as children to build the visual representation of a control, often as part of a control template. That's the same model used by UWP/WPF/Forms.

Geometries, transforms, and brushes all help support the drawing.

Text

ITextBlock, FontStyle, FontWeight, FontWeights

Other controls

IBorder

Layout

IPanel, IStackPanel, IGrid, ICanvas