WinUI 3.0 : WPF features that should be in WinRT XAML

[mdtauk]

I remember since Windows 8 and the introduction of WinRT - many times people saying they couldn't make a control, or couldn't achieve X Y Z - because something they took for granted in WPF didn't exist in the newer WinRT version of XAML.

With WinUI 3.0 and the convergence of WPF and UWP as open source libraries...

What should be added to WinRT XAML that exists in WPF, and why?

[huoyaoyuan]

{x:Bind} equivalent for DataTrigger

I don't know if there is a simple way to convert an enum into themed color, or localized string. Visual states are too heavy for this.

Limited dynamic resource support

Dynamic resource are harmful to performance, but useful for custom theming support. Currently {ThemeResource} only supports system defined themes, and can't be used from code.

[rmarinho]

WinUI Xaml should support XAML 2009 language features

https://docs.microsoft.com/en-us/dotnet/framework/xaml-services/xaml-2009-language-features

it only implements 2006

[bschoepke]

VisualBrush is a good one. You can achieve mostly the same outcome using windows.ui.composition.redirectvisual but it's less convenient than a brush, and there's no way to "Freeze" it.

https://docs.microsoft.com/en-us/dotnet/api/system.windows.media.visualbrush?view=netframework-4.8

[Psykobal]

Support bindings in style setters, it's a very common feature in wpf and there isn't any "easy" workaround.

It has an Uservoice request

[TonyHenrique]

A proper Window object would be awesome in WinRT.

[mfe-]

I just gonna quote myself here.

[...]

• Style Triggers missing
• The ability to use e.g. BasedOn={StaticResource {x:Type TextBlock}} in a Style
• Defined DataTemplates with DataTypes aren't automatically applied like in WPF (only via Key)
• Why is every second Windows.UI.Xaml.Controls control (TextBlock, Border,...) declared as sealed?! Please don't do this in WinUI 3.0 with UWP.
• Markup Extensions for WPF parity
  I'll add here (even they were mentioned in the issue already)

• Style Binding missing
• Binding RelativeSource missing
• The ability to use various Types combined in xaml e.g. (Array with strings; e.g. <ListBox><ListBox.ItemsSource><x:Array><s:string>foo<s/:string>[...])
• AdornerItem
• Path Markup Extension of WPF

[charlesroddie]

(Not Xaml-related)
WPF has sub-pixel anti-aliasing and WinRT doesn't.

[mdtauk]

@charlesroddie I've covered that in #768

[adrientetar]

Ability to create cursors dynamically at runtime #506

[sonnemaf]

I would like:

• {x:Static}
• Bubbeling of the ButtonBase.Click event on a parent, see screenshot below
  
• Path animations
• Shape classes like Arrow, Callout, Star, etc. (Included in Blend for WPF projects)
• StringFormat property on Binding object
• DataTemplate.DataType property
  

I don't need:

• {DynamicResource}
• Tunneling of events
• PropertyTriggers, EventTriggers, DataTriggers, MultiDataTriggers. I will use the VSM
• IMultiValueConverter, I will use x:Bind instead
• FindAncestor and PreviousData RelativeSource databinding

[verelpode]

• @bschoepke mentioned VisualBrush. This is also relevant for tiled brushes. See Proposal: Bring back vector-based tiled brushes #536.

• @bschoepke also mentioned no way to Freeze. This is also relevant for sharing of PathGeometry -- you can share a frozen PathGeometry in WPF but not in UWP. See issue #827.

• WPF apps can make their own custom Controls/elements that render graphics (instead of creating child Controls or ControlTemplate), by overriding System.Windows.UIElement.OnRender(System.Windows.Media.DrawingContext). Is the equivalent ability missing in UWP? I know this is a Composition/Visual issue, but does it require access to internal/protected members? I will understand this issue much better when I can look at the source code when WinUI 3 is released.

• WPF (but not UWP) apps can measure text without disrupting the Measure/Arrange passes, by using System.Windows.Media.FormattedText. See issue #1226.

• WPF (but not UWP) apps can check and be notified when the effective visibility of an element changes. See issue #674.

• WPF apps can use Block objects to easily read and modify the contents of both editable and non-editable rich textboxes, whereas UWP only supports Block objects for RichTextBlock not RichEditBox. See issue #706.

• WPF (but not UWP) apps can skip the print dialog. See issue #672.

[adrientetar]

WPF apps can make their own custom Controls/elements that render graphics

Isn't that what Win2D does?

[VitezslavImrysek]

There are differences. Rendering instructions provided by a user to DrawingContext (WPF way of doing custom rendering for elements) become part of the resulting UI scene graph. One of the direct benefits of this is that these retained instructions are automatically used during hit testing by WPF and could result in raising your event handlers (for input events like MouseEnter).
Win2D on the other hand does immediate mode rendering to a bitmap whenever invalidated. As no rendering instructions are retained, no hit testing support is provided. And you are also stuck with one more bitmap.

[verelpode]

@VitezslavImrysek -- Nice answer. Your explanation is better than how I was going to explain. Do you (or anyone else) happen to also know the answer to the next part of the puzzle? Meaning do you know if WinUI already has an equivalent to System.Windows.UIElement.OnRender that doesn't require internal access?

I know WinUI already supports the Windows.UI.Composition API, but so far I haven't seen any example usage of Composition that operates as an actual equivalent of System.Windows.UIElement.OnRender. For example, I'd love to see the source code of Windows.UI.Xaml.Shapes.Ellipse in order to understand how it renders itself. In the case of WPF, Ellipse and the other shapes render themselves via OnRender.

[zenjia]

Bring back more tuneling event, please!
And {x: Static}, MultipleBinding, binding in style setters

[adrientetar]

There's no way to declare an array in UWP XAML apparently, like x:Array in WPF.

[verelpode]

The ability to convert styled text to a Geometry object. I'm trying to convert a WPF app to WinUI/UWP and the WPF app uses this ability but I cannot find any equivalent in WinUI. In WPF, this is performed using either of these methods:

• System.Windows.Media.FormattedText.BuildGeometry
• System.Windows.Media.GlyphRun.BuildGeometry

WinUI has a related feature Windows.UI.Xaml.Controls.TextBlock.GetAlphaMask. That's a nice feature. How about complementing it with a method in TextBlock named GetGeometry or BuildGeometry that returns a new instance of Windows.UI.Xaml.Media.Geometry?

It sure is frustrating and time-consuming when trying to convert a large WPF app to WinUI and multiple WPF features are missing in WinUI.

[verelpode]

This WPF features issue has turned into a useful reference/list of the missing features. Here's another one for the list:

In WPF, you can use PathGeometry in a ResourceDictionary XAML file. For example, you can use it to store the various icons/symbols that your app needs. Unfortunately, the WinUI XAML compiler produces an error message when it tries to compile PathGeometry (it compiles Path successfully but not PathGeometry). Here's a link to a message with more details about PathGeometry in ResourceDictionary.

[pjmlp]

Here are two from my side:

WPF can have 3D models without forcing developers to drag along a 3D game engine.

https://docs.microsoft.com/en-us/dotnet/framework/wpf/graphics-multimedia/3-d-graphics-overview

WPF can have nice UI effects without forcing .NET developers to write C++ code

https://docs.microsoft.com/en-us/dotnet/api/system.windows.media.effects.shadereffect

[robloo]

@mdtauk I didn't see this issue earlier but it's a really good idea!

I've converted an internal document that outlines WPF/UWP differences to markdown and made it public. It was started when porting WPF code over to UWP a few years ago. I also started pulling in some of the comments above -- still more work to do.

It should be a good -- and visual -- summary of the differences that others can use. Special thanks to everyone who took the time to comment and write blog posts over the years.

https://github.com/robloo/PublicDocs/blob/master/UWPvsWPF.md

[ranjeshj]

@predavid and @anawishnoff as FYI

[michael-hawker]

@predavid this should get the wpf tracking label too.

[weitzhandler]

Another super important topic missing in UWP - Validation: #179 #2476.
Related: dotnet/runtime#40157.

[zhuman]

A major barrier I would have to using WinUI right now is the inability to host a child HWND - or even better, bring back the IDCompositionDeviceDesktop::CreateSurfaceFromHwnd as a new function in Windows.UI.Composition to host layered child windows. Bringing CreateSurfaceFromHwnd into the new API would solve so many issues with hosting third-party plug-ins, the "airspace problem", and enable people to integrate old UI technologies seamlessly with composition blends and animation. As an example, every audio application that supports third-party VST controls needs to be able to host HWNDs in some way, as this is the interop mechanism provided by the standard.

Right now the closest I could come would be to host WinUI in another framework - the reverse. This has its own issues, particularly around performing layout/arrangement of the WinUI parts with the HWND. It also makes it impossible to use WinUI "around" child HWNDs since you can only have one island today, and even with multiple islands things would get really unwieldy.

Please consider CreateSurfaceFromHwnd! (I know it's actually internally used heavily by the Windows shell with Windows.UI.Composition, so this is a request to make it public!)

[Noemata]

I would be happy to see UWP reach feature parity with where Silverlight and the Silverlight SDK left off (not even WPF). LOB friendly controls for things like validation. Feature parity and support for all the controls that were in Silverlight. That includes the XNA like 3D features added near the end. That shouldn't be a big ask given how straightforward porting most of the code should be and where UWP is at today. My request (I hope) is modest because it should be achievable at this stage of where UWP is at.

UWP/WinUI needs full LOB support (validation, charting and preferably a bindable 3D markup system). The UWP innovations around the compositor and WinRT API were fantastic as was the security sandbox. Tooling that incorporated a .Net Native compiler were also huge. As was the whole multi-device deployment magic through the Store. That last mile doesn't really seem so far away unless you start to introduce another reboot via WinUI 3.x.

[Noemata]

Lastly, I did notice how easy it is to go from UWP to WinUI where things work. I doubt WPF folks will find the transition that easy. Wouldn't it have been easier to add a desktop capability (no sandbox) to UWP and port the existing WPF API over to UWP than the path being taken now? WinUI 3.x on day one can't be missing things like the map control. The current feature set of UWP should be seen as essential and just the starting point for the future of WinUI. If things are missing on day one WinUI will be a bust.

[sigmarsson]

Gosh, ample of splendid ideas aggregated here! x:Type would be cool e.g.

<RadioButtons Style="{StaticResource {x:Type ToggleButton}}">

[ClausBarth]

I am trying to draw Path and PathGeometry in WinUI, but it will not work (nothing shows).

In WPF it works perfectly

[oliverw]

Gosh, ample of splendid ideas aggregated here! x:Type would be cool e.g.

<RadioButtons Style="{StaticResource {x:Type ToggleButton}}">

Yeah and two years later not much has changed. Its hard to take WinUI serious.

[verelpode]

@oliverw wrote:

two years later not much has changed. Its hard to take WinUI serious.

I think it's difficult to get competent software engineers to work on WinUI because, for example, the first thing they will say is:
"Why on earth is WinUI written in C++? That makes no sense. It should be mostly written in C# plus a smaller amount of C++ where necessary, like how WPF was written, or like how the UI in Android is mostly written in Java. Furthermore, why should I work for a mega-corp if they won't give me any shares in return? Better to work for a startup - they'll give me shares."

[pjmlp]

@verelpode Because after Longhorn WinDev decided to redo .NET in COM, WinRT is basically the return of Ext-VOS ideas as COM Runtime.

It wasn't that bad with .NET Native and C++/CX, the pain point was whoever decided it was fine to throw them away without feature parity.

So now instead of letting the .NET Native runtime handle COM, you get to mess around with CsWinRT and manually export files.

Likewise instead of having a .NET like experience with C++/CX, something that C++ Builder has done for 30 years, you get to manually edit IDL files without VS tooling support, just like back in the ATL days, 23 years ago.

[oliverw]

It wasn't that bad with .NET Native and C++/CX, the pain point was whoever decided it was fine to throw them away without feature parity.

Sinofsky, to keep the evil .NET hordes threatening his kingdom at bay? 😁

[pjmlp]

It wasn't that bad with .NET Native and C++/CX, the pain point was whoever decided it was fine to throw them away without feature parity.

Sinofsky, to keep the evil .NET hordes threatening his kingdom at bay? 😁

He was long gone when C++/WinRT and WinUI 3.0 took place.

[verelpode]

@pjmlp

It wasn't that bad with .NET Native and C++/CX,

As an "Ahead-of-Time" compiler (meaning a normal compiler), I found the concept of .NET Native comprehensible and sensible. It made sense to stop overusing JIT, considering that JIT is only justifiable in rare cases, such as unusual special apps that truly need runtime code generation.

the pain point was whoever decided it was fine to throw them away without feature parity.

And now there is "Native AOT" but it is still limited to "console type applications" and has no built-in COM. So yes one does get the feeling "two steps forward, one step backward, one step repeated, three steps cancelled, rinse and repeat".

So now .... just like back in the ATL days, 23 years ago.

Yes unfortunately I've seen several brand-new "modern" projects that were started in recent years yet gave me awful flashbacks to the pain of programming in the 1990's.

To convince me or someone like me to work on WinUI 3, it would be necessary to pay me a fortune. Then the employer would ask, "Why do you deserve to be paid a fortune to work on WinUI?"
And then I'd reply, "Nevermind. Forget it. Just delete my job application."

Even if the employer agreed to pay me the fortune, the project would still be a failure because one of my bosses would inevitably place untenable conditions on me or the project -- one or more conditions that make the project practically impossible to succeed. The biggest problem is not technical, but rather the terrible people-politics that ruin everything.

[Qiu233]

There're a lot of stuff that meant to be here but in fact not. Grid with shared size, implicit DataTemplate, Binding in style setters.
There's not even alternative workaround, but endless dirty, ad-hoc, tedious boilerplates.
I've been working with WinUI for more than one month, but still struggling with all those minutiae. And I'm convinced that WinUI isn't ready for production use.
The developer team should really look into those removed things, and if they're not being back, please introduce some new features to replace them, instead telling users not to do that or why you can't bring them back.