Support for widgets in non-UWP apps (WinUI 3)

[agc93]

Is your feature request related to a problem? Please describe. Currently, building an overlay requires using a UWP app as a base. This immediately locks out use of any libraries or features from .NET 5 as well as anything newer than .NET Standard 2.0.

Additionally, Project Reunion no longer includes any planned roadmap for supporting newer features (WinUI 3, .NET 5 support, etc) in UWP apps.

Describe the solution you'd like Ideally, I'd like to be able to add a widget from a "modern" WPF app (such as one created by the new production-supported WinUI 3 Desktop templates from Project Reunion), thus allowing for creating a widget without being hamstrung by UWP's increasingly acute limitations.

As it stands, I am unable to use any library, component or code created since about 2018 (i.e. since .NET Standard 2.1) on top of not being able to use .NET 5, WinUI 3, SDK-style projects or newer C# features.

Describe alternatives you've considered Given the focus on the "enhance" and "extend" stories for making Windows 10 APIs available through packaged Win32/WPF apps and the availability of bridging options like XAML Islands, I would hope there was some alternative method of providing a widget.

Additional context I understand that a lot of the culprit here lies with UWP itself, but to be clear, my request is specifically whether there is a supported method of providing Game Bar widgets from any target/platform other than UWP.

[hamiltonia]

Hi @agc93

We 110% agree with you on this :)

Game Bar relies on various internal Windows tech to enable 3rd party widgets to run as overlays. Some of the benefits of project reunion and WinUI 3 are related to how they are being undocked from the OS, unfortunately this also means that they are independent form the tech we need to enable our scenario.

We're working with the relevant teams working on project reunion enable this, but it is not a small ask. We'll comment back when we have more information to share.

Thanks for the feedback!

[edwardchanjw]

Especially also Webview2. Kinda multi tasking all the time. Gamebar help.

[vidager]

As Eric mentioned, we're pursuing support for hosting WinUI3 and WebView2 in Game Bar, but that currently doesn't include non-UWP. It would be UWP WinUI3 and WebView2 powered by WinUI3. We have a hard limitation on the visual hosting tech we use in Windows that only supports UWP XAML. There is no alternative hosting solution in Windows at this time. If we gain WinUI3 support, note that this should unlock the new React Native Windows stack. React Native on the existing (non-WinUI3) stack should already work in Game Bar, but we haven't "officially" declared support for that.

If you need features beyond what you can get in UWP XAML, another approach is to have your Game Bar widget UI (which should be fairly light anyway), be the UWP XAML, then have a full trust process (non-UWP) that your widget communicates with to do your heavy lifting. Many widgets are already using this approach.

Thank you, Ben

[joshhunt]

If we gain WinUI3 support, note that this should unlock the new React Native Windows stack.

I am very interested in this :)

[agc93]

Given WinUI 3 is not coming to UWP and UWP appears to have been dropped entirely from the Windows App SDK roadmap, are there any plans for making the Game Bar SDK available for contexts other than UWP?

At present, a developer wanting to integrate Game Bar widgets now has to shackle themselves to what is essentially a legacy technology and only support extremely out-of-date .NET versions without access to most of the modern .NET features.

[superusercode]

Given WinUI 3 is not coming to UWP and UWP appears to have been dropped entirely from the Windows App SDK roadmap, are there any plans for making the Game Bar SDK available for contexts other than UWP?

The idea seems to be now that someone can create a "UWP" app by transferring the code in their solution to a new windows app sdk project. The priority for winui 3 will be to get win32 apps quick access to xaml and then completely XAML/"UWP" apps will be supported in a later release.

[agc93]

@superusercode huh? Win32 apps already use XAML, they just use WPF XAML, or use Islands etc

and then completely XAML/"UWP" apps will be supported in a later release.

The last community call said "we have no plans right now to release WinUI 3 for UWP in a stable way". That doesn't sound like it will be supported in a later release.

[superusercode]

The last community call said "we have no plans right now to release WinUI 3 for UWP in a stable way". That doesn't sound like it will be supported in a later release.

The terminology has changed. You can copy the UWP code straight into a new windows app sdk project - therefore no longer making you a UWP app and now a .NET app.

[agc93]

@superusercode Okay so if it's no longer a UWP app and therefore no longer running in the UWP app host, how is it going to be able to include Game Bar widgets?

[agc93]

@hamiltonia Is there any update on this internally?

.NET 6 is now out, Windows App SDK (i.e. Project Reunion) is 1.0 and apparently stable. Having to put widgets in a UWP context is only becoming more and more of a point of friction.

UWP is still not included on the App SDK roadmap, nor is WinUI 3 supported on UWP (see here ). The UWP story for desktop apps is clearly stalled, and holds developers back to a years-old set of components.

This also means a developer wanting to build a Game Bar widget is also locked to components that are years behind the curve, or drop the widgets and use a modern stack.

[vidager]

Hi agc93,

We definitely hear you and want the widgets to as simple and friction free to build as possible. Unfortunately, the only Windows tech at our disposal for doing visual hosting inside Game Bar and Input 'redirection' both require CoreApplication/CoreWindow (i.e. UWP app). We do have asks on the appropriate Windows teams to get support for these requirements outside of CoreApplication/CoreWindow, but there is no current ETA for when they will be delivered.

With that said, there is a lot of power at your disposal today for widgets, as you can build a full trust process (aka Centennial/Desktop Bridge) that runs your business logic and just have the UWP XAML side be light weight. Your full trust process can be written in whatever you like, as long as you can do IPC to your UWP XAML process. For example, you could use the latest .NET for your full trust process and used named pipes for communication with your UWP XAML process. This doesn't help you get the latest .NET tech on the visuals side, but if you're wanting that tech for the business logic side, it should solve your problem.

Sorry for the inconvenience. Please let us know if you have further questions about alternate strategies.

Thanks, Ben

[agc93]

Thanks for the detail @vidager (I just remembered I never followed up here).

I can agree that using named pipes is a possibility, but in my view its not much more than a band-aid and still involves a lot of friction. Even in the IPC scenario, things like data models and other shared code is still made much harder than usual (or needs to be duplicated) and there's a lot of boilerplate required for correctly implementing and managing communication over named pipes (or any other IPC method of choice).

Especially since the other "standard" communication method is just as limiting (App Services, limited by both UWP and WinRT compatibility), is there any chance that we'll see anything on the Game Bar SDK side to make this sort of split logic deployment easier?

I understand that you're trying your best but in terms of keeping things frictionless, splitting apps in half with a heap of custom-built IPC is just trading one friction for a new one, in my opinion.

[K900]

It's almost been another year now. Is this happening at all?

[vidager]

Windows is actively working on a new Input Delegation feature that will work outside of UWP (which Game Bar will need for this ask), but that's still in progress. After that's been done, we also need a visual hosting solution that doesn't rely on CoreWindows. XAML islands hosted OOP might be one solution, but we're waiting for guidance from Windows on which direction they're going there. Once both of those pieces are in place, we'd need to determine how to update the architecture of Game Bar to support both new (non-UWP) and legacy widgets.

Unfortunately, there's no solid timelines for these and priorities are balanced against the other asks Windows has for any given release.

In summary, we still want to support this, and we haven't "cut it", but given the amount of work involved by Windows and Xbox, the work is often punted in favor of other work.

Not the best news, I know, but that's the full transparency.

Thanks, Ben

[K900]

Appreciate the transparency. Please keep us up to date.

[vidager]

Thanks for the detail @vidager (I just remembered I never followed up here).

I can agree that using named pipes is a possibility, but in my view its not much more than a band-aid and still involves a lot of friction. Even in the IPC scenario, things like data models and other shared code is still made much harder than usual (or needs to be duplicated) and there's a lot of boilerplate required for correctly implementing and managing communication over named pipes (or any other IPC method of choice).

Especially since the other "standard" communication method is just as limiting (App Services, limited by both UWP and WinRT compatibility), is there any chance that we'll see anything on the Game Bar SDK side to make this sort of split logic deployment easier?

I understand that you're trying your best but in terms of keeping things frictionless, splitting apps in half with a heap of custom-built IPC is just trading one friction for a new one, in my opinion.

For IPC between UWP (AppContainer) and a full trust process, we've found COM/WinRT very simple and powerful. Xbox and a number of our partners are following this pattern now too. We can look into providing a sample. With WinRT, your UWP app just CoCreates the COM object (hosted in your full trust process), COM auto starts your FullTrust process and connects the object, then you talk to that object just like you would any other WinRT object. If you're using C++/WinRT, you're just programming standard C++ object oriented RAII style and the fact the object is hosted in a remote process is mostly transparent. You do have to be mind of chatty IPC costs, etc, but your model can be clean.

[project-sbc]

Thanks for the detail @vidager (I just remembered I never followed up here). I can agree that using named pipes is a possibility, but in my view its not much more than a band-aid and still involves a lot of friction. Even in the IPC scenario, things like data models and other shared code is still made much harder than usual (or needs to be duplicated) and there's a lot of boilerplate required for correctly implementing and managing communication over named pipes (or any other IPC method of choice). Especially since the other "standard" communication method is just as limiting (App Services, limited by both UWP and WinRT compatibility), is there any chance that we'll see anything on the Game Bar SDK side to make this sort of split logic deployment easier? I understand that you're trying your best but in terms of keeping things frictionless, splitting apps in half with a heap of custom-built IPC is just trading one friction for a new one, in my opinion.

For IPC between UWP (AppContainer) and a full trust process, we've found COM/WinRT very simple and powerful. Xbox and a number of our partners are following this pattern now too. We can look into providing a sample. With WinRT, your UWP app just CoCreates the COM object (hosted in your full trust process), COM auto starts your FullTrust process and connects the object, then you talk to that object just like you would any other WinRT object. If you're using C++/WinRT, you're just programming standard C++ object oriented RAII style and the fact the object is hosted in a remote process is mostly transparent. You do have to be mind of chatty IPC costs, etc, but your model can be clean.

checking in to see if you have any examples of WinRT integration, looking to help windows handhelds with some widgets

[vidager]

I'm working on a sample to share. I'll push to a branch on this repo hopefully this week!

[vidager]

@project-sbc Draft sample pushed. If you have questions, I'll do my best to answer as I have time. Thanks! https://github.com/microsoft/XboxGameBarSamples/tree/users/benmc/ft_com_server_sample/Samples/WidgetFTSample

[project-sbc]

Thank you!!!!

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: Ben McGregor @.> Sent: Thursday, August 29, 2024 7:14:50 PM To: microsoft/XboxGameBarSamples @.> Cc: project-sbc @.>; Mention @.> Subject: Re: [microsoft/XboxGameBarSamples] Support for widgets in non-UWP apps (WinUI 3) (#100)

@project-sbchttps://github.com/project-sbc Draft sample pushed. If you have questions, I'll do my best to answer as I have time. Thanks! https://github.com/microsoft/XboxGameBarSamples/tree/users/benmc/ft_com_server_sample

— Reply to this email directly, view it on GitHubhttps://github.com/microsoft/XboxGameBarSamples/issues/100#issuecomment-2319362474, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASZ4DJK7BAN3YS7DRDL54BDZT6TOVAVCNFSM6AAAAABNDDJKZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJZGM3DENBXGQ. You are receiving this because you were mentioned.Message ID: @.***>