<!-- Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. -->

ℹ Computer information

• PowerToys version: v0.18.2
• PowerToy Utility: Shortcut Guide
• Running PowerToys as Admin: No
• Windows build number: 19041.508

📝 Provide detailed reproduction steps (if any)

1. Press and hold the Windows key
2. Shortcut view shows

✔️ Expected result

G - "Open Game bar" is in the list of shortcuts,

❌ Actual result

G - "Open Game Bar" (capital B) should be shown

I know it's small, but we worked for that B (it's also incorrect in some places in Windows, we'll fix that soon).

I don't see any reference to wiring diagram, can you please share how you're connecting the two raspberry pi, and laser LED including mosfet?

Thanks much for the diagrams, I'm still plugging away in my spare time. Up and running but badly out of focus :D

Hi @visionarylab - it's not clear to me what you're reporting here. Widget1 is the primary widget opened, Widget1Settings is the widget which is opened when using the settings button in the title bar of Widget1. Are you reporting that the description of what they are is not clear? Not sure what you would want swapped.

Tracking as VSO 29138992

Where is 1. My volume levels for my mic? and 2. more importantly and the purpose of this entire feedback... CAN I GET A NOISE GATE PLEASE??

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] The problem is when I'm not talking .. you can hear the static in the room

Describe the solution you'd like A clear and concise description of what you want to happen. Just need either a widget or a function built in to add a noise gate on your microphone...

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Recording my audio seperately in my DAW.. Works but crazy long process plus lining up plus many errors and things can go wrong from here to there.. Tried Muffling the sound of my pc.. Rediculously impossible.. TRIED getting a whole NEW recording software even though this ones damn near perfect.. Why cant yall just add a quick feature?

Additional context Add any other context or screenshots about the feature request here. I think I've made my point Thanks for listening and hopefully solving this =)

Much love~

I've filed a bug directly against Game Bar for this, closing this issue as this is not directly related to the SDK.

VSO 29138874

Great - thanks! I didn't even think that was a thing. I found some articles on Raspberry Pi to Arduino via USB, I'll see if I can figure it out.

From what I can see these are the pins, does that look right?

Arduino UNO: 0(RX), 1(TX) Raspberry Pi Zero: 10 (RX), 8 (TX)

Also did you just solder directly to the vision bonnet, or some other magic?

the code references a crosshair image ('Crosshair_Black.png') for live preview, can you please include in repo, or define attributes for recreation?

I don't see any reference to wiring diagram, can you please share how you're connecting the two raspberry pi, and laser LED including mosfet?

The fix was internal to Game Bar and the SDK.

This is not currently supported, we have it in our backlog but have not committed to how or when we will implement it.

Can you describe your scenario more? Would you want this for the first run experience, or you want to be able to override where a user has placed your widget (and why)?

We're not currently planning to allow arbitrary activation as it would be too easy to abuse. What if only the user could set what apps should activate the widget?

One of the areas we're investigating for many scenarios is providing the user ability to determine capabilities (e.g can a widget use the microphone, know which game is playing, show notifications, launch other widgets, etc.), this would also need to be considered.

fix the issue where the minimized widget doesn't take input You mean where the minimized widget takes input, right? Because that's the issue I'm facing.

A pinned widget should not take input when minimized.

It would be nice if the widget could open automatically after opening the application.

We're working on a feature that would allow for an application to activate Game Bar and a widget, but this would require that your application is installed with the widget in the same package. It doesn't sound like this is the case for you. We're not currently planning to allow arbitrary activation as it would be too easy to abuse.

I need to display some information incessantly and hide it in some scenarios. When it comes to my other project, which displays some information from time to time

I sounds like the ability to minimize and restore your pinned widget through the API should meet your needs, assuming we fix the issue where the minimized widget doesn't take input (which we just checked in the fix for, but won't be available broadly until the 20.08 release). However we will not allow you to programmatically pin/unpin or change the click-through state, we believe these are actions only a user should control.

Should be fixed in the current 20.06 release - please let us know if you're still seeing this.

Describe the bug MinWindowSize function do not work expectedly, and MaxWindowSize function makes the program crash.

To Reproduce Steps to reproduce the behavior:

1. Clone and build WidgetAdvSample
2. Debug in x64 mode; Win+G
3. Click on SetMinWindowSize (behavior 1)
4. Click on SetMaxWindowSize (behavior 2)

Behavior & Screenshots

1. after MinWindowSize({800, 600}), the window can be resized to very small.
2. after MaxWindowSize, nothings happens. But when you try to resize or drag the window, the whole game bar crashed (how can i get the crash log?).

Desktop:

• OS version: Windows 10 2004 build 19041.264
• Game Bar version 5.320.5291.0
• SDK version: XboxGameBar v5.1.200401003
• Target platform version: Windows 10.0.19041.0 (Tried 10.0.17763.0 also)

Tracking: VSO 27480391

Marking as a bug because minimized widgets should not restore when moving into pinned mode. Should consider a new issue for relevant feature requests coming from this.

I thought that minimizing would be the solution. I thought it would hide the widget and stop capturing the mouse.

Are you calling GameBarWidget::MinimizeAsync()? If so when? It sounds like you're trying to minimize at some point (after you receive the GameBarDisplayModeChanged event?) and the widget is not minimized, hence intercepting click events. If so we'd need to evaluate if the minimize event is working properly when in pinned mode.

This brings some other questions to mind:

• How does your widget react when not over the top of your own application? Do your application use foreground or some other mechanism to determine the user has it focused, and give this information to the widget?
• If you own the other application why do you need Game Bar for this? Why not build an overlay system into your application?

What I would also want to do is opening a widget in pinned state so user doesn't have to pin it manually. My widgets are supposed to be an overlay for the underlying app. I would like to achieve a seamless usage without having to constantly open the Game Bar.

Yes - however our platform isn't designed, nor can it support this model right now. There are both technical, security and user experience issues we need to work through. The technical issues are currently not solvable without larger changes to the OS and Game Bar, I don't expect we'll be able to support this soon.

In the near future we are looking at mechanisms for widgets to provide notifications to the user. Can you describe the scenario and what information you wish to convey to your user in these situations? Possibly they could help in your situation.

I see now - are you intentionally hiding content in your widget when pinned? Do you have some use case where the widget would show something when pinned, but not all the time? To me this looks like a case where the widget should not allow the pinned state if it doesn't plan to show something when pinned. I.e. don't hide your content when pinned, or attempt to managed the pinned state on your own.

Re: getting a out of the way when I would disturb the normal usage of the app, Game Bar has no way to understand the users intent, we do not know if the user intends to interact with the widget or the app. The intent is for the widgets usage to be clear, none of the Game Bar widgets allow themselves to be fully transparent when pinned for this reason - we want the user to know that the widget is there so that it makes sense why they can't click through it.

Long term we also want to allow per-widget click through settings; possibly then we could allow the widget to manage the click-through state on their own to allow for cases where they're transparent (or minimized) with no interaction, vs. visible. This is not currently possible due to other technical constraints that we can't modify at this time.

Hi @Dawider10 - we call the ability to click-through a widget (wait for it...) click-through mode. In the home bar at the top you'll notice a button that has a mouse icon. In your image it shows as click-through disabled, that is: the mouse is enabled and you can interact with your widget when it is pinned. If you enable click-through, the mouse icon becomes disabled, and afterwards all widgets will no longer respond to mouse input when pinned.

XboxGameBarWidget exposes an ElementTheme property and event for when it changes.

https://docs.microsoft.com/en-us/gaming/game-bar/api/xgb-widget#game-bar-state