[SDK BUG] Background="Transparent" doesn't work on Widgets

[QuiNz0r]

Describe the bug
Setting the Background Transparent doesn't apply to the widget in Game Bar

The Default System Performance Widget is actually Transparent, how is this achieved?

[QuiNz0r]

got everything to work with the preview package.

One question: if I develop my widget now with the preview features, how can I upgrade/release it properly when the preview gets officially released?

[totallymonkey]

Glad to hear you got everything working with the preview package. We generally make the release nuget package available 1 week before we ship the matching Game Bar version. Our target release dates right now are:

6/8 for the nuget package
6/15 for general availability of Game Bar

Just know that these dates could change. Let me know if you have any other questions!

[QuiNz0r]

I have an issue I cannot solve: I want my widget to be fullscreen or at least centered in the middle.

The Problem is the GameBar itself doesn't allow me to maximize my widget further then where the GameBar sits at the top.

Also I couldn't find anything to atleast position my Widget in such a way that it uses the maximum screen space available and/or make it centered in the middle of the screen

[DDobynsMS]

@QuiNz0r Can you tell us more about the scenario you're hoping to achieve with a fullscreen or strictly centered widget?

The Game Bar SDK doesn't currently support setting specific widget position, but I'd like to learn more about your scenario requirements to help inform this issue. Thanks.

[QuiNz0r]

I'd like to develop a tool to draw lines on the whole screen as an overlay in order to adjust monitors on your desk (some monitors have this functionality built in) also a crosshair overlay would be thinkable

[hamiltonia]

Closing this issue as the original is a feature in 20.06 and already in preview. For the latter I believe a new issue should be created and we will mark as feature request for consideration.

[joshhunt]

@hamiltonia @totallymonkey Are you able to confirm that we are able to safely ship an update using the new SDK (once it's out of prerelease) and have code that uses widget.RequestedOpacityChanged and widget.RequestedOpacity, but it will essentially be a no-op until the user's Game Bar recieves the matching update? Should i account for widget.RequestedOpacity to be null or something until user have the Game Bar update?

I would like to submit my transparency-supporting update to the store next week when the SDK is out of prerelease, so my widget supports it once the Game Bar update is out.

[hamiltonia]

If you ship your widget with the new SDK before we release the new Game Bar, users with the old Game Bar will not be able to use your widget. When attempting to load the widget they will instead get text inside the frame instructing them to upgrade Game Bar, which will not be possible short of joining an insider flight ring.

So while nothing will catastrophically break, it will not work either. Our intent is for you to have the release SDK ahead of time so that you can start building and testing against it, but preferably wait until we ship the new Game Bar before you publish your own app.

What do you think of this? It's a policy that we're still working on, and would like feedback on. Alternately we could wait until Game Bar ships before releasing the updated nupkg.

[joshhunt]

Thanks, this is extremely helpful to know - I consider my widget not loading for user's to be relatively catastrophic 😉

It would be really helpful if Game Bar and SDK versions were forward/backwards compatible, to avoid instances of users being locked out of widgets before their update has downloaded, but I figure there are technical hurdles to overcome to achieve this.

Personally, I'm unsure about this policy. While initially i figured that "sdk out of prerelease" meant "ready for use, release & users", I realise it would be handy to have the SDK out of prerelease so updates can be built and submitted to the Microsoft Store, and manually release used once the Game Bar update is out.

[hamiltonia]

Newer versions of Game Bar will work with widgets that were built with older SDKs, but not the other way around. It's easier to build backwards compatibility against a known feature set, then try to support widgets from the future that may require functionality an older game bar can't support.

[joshhunt]

@hamiltonia I appreciate the technical difficulties involved, but at least from my perspective as a SDK consumer and widget developer, I believe it would be a worthwhile investment to make Game Bar forward compatible with newer SDK releases.

Last week I had prepared a build with new features and bug features with the new SDK and was approved in the Microsoft Store for manual release today, which I now have to cancel and submit a new build with old SDK and go through the 3+ Microsoft Store certification cycle again.

I understand the scope and scale is very different, but an iOS app developer can submit an update to their apps to support new platform features while maintaining compatibility with previous iOS version. I believe it would be exceptionally beneficial for both developers and users if Xbox Game Bar and it's SDK could work similar.

Cheers!

[Edit: I am going to repost this as it's own issue as I believe it's something that should be considered and prioritised on its own]