Port UWP taskbar behavior when fullscreen to Win32 apps

[MarcAnt01]

Proposal: [Port UWP taskbar behavior when fullscreen to Win32 apps]

Summary

If a UWP app is in full screen if I swipe up from the bottom part of the screen with touch or otherwise with a touchpad/mouse I just hover the bottom part of the screen.
In Win32 apps nothing happens. The only way to switch to apps is using multitasking view, which is quite annoying.
Another useful feature of this uwp feature is the ability to retrieve the title bar analogously by swiping down from the upper part of the screen or putting the mouse hover on top.
This could be invoked with the useful shortcut Win+Shift+Enter like in UWP apps so that you can also manually opt it in

Rationale

• Having the same behaviour in Win32/UWP apps is ok for the purpose of Project Reunion
• Being able to switch among apps or just check the time or info on taskbar would be made definitely easier and with basically no drawback

Scope

Capability	Priority

Important Notes

Open Questions

Will this behavior cause problems to games where the taskbar could be popping-out continuously?
My idea is to make this one the default behavior, even if an option to disable it should be present. For those who continue to argue about games, I just think that they aren't the main usage of WinAppSDK, that I think is instead new generation WinUI 3 apps

[jaigak]

The problem is UWP apps use the built-in API to do this which handles this correctly but Win32 apps don't have such API and have their own methods of achieving so it's up to the developer unless Microsoft provides a built-in way to go full screen in a Windows desktop app. I did ask for a built-in API because many full screen implementations are broken and don't work correctly.

[riverar]

This proposal is incomplete (e.g. scope section is invalid).

[MarcAnt01]

This proposal is incomplete (e.g. scope section is invalid).

[riverar]

@MarcAnt01 Optional != Provided w/ invalid values. I understand it's minor but I read it and was briefly confused.

[MarcAnt01]

@MarcAnt01 Optional != Provided w/ invalid values. I understand it's minor but I read it and was briefly confused.

Ah yes, removing it might make sense. Done

[sylveon]

I think this outright cannot work for exclusive full screen apps (because DWM is not involved here, so start cannot show up over the game), and might cause more pain than benefits for some kinds of games or interfaces.

For example, some games requiring the pointer might have you jerk quickly around the screen, meaning you might hit the bottom. Thus the taskbar pops up and breaks DirectFlip, making the game become stuttery until the taskbar goes away.

Some FPS games don't reset the pointer position often enough to the center, so sometimes you might hit the bottom and the same issue happens (I've had that one when using Mouse Without Borders). It gets even worse if you end up clicking on the taskbar too, because you could trigger long loading processes (e.g. Visual Studio or another game is pinned to the taskbar).

In the cases of interfaces, I think of YouTube where somebody would want to access settings or something and because the mouse went to the bottom of the screen, start pops up and completely blocks out the settings icon, forcing the user to move their mouse back towards the middle, wait for the taskbar to go away and then move their mouse back towards the settings icon more carefully to not hit the bottom of the screen.

In all 3 examples, this is very frustrating behavior.

[MarcAnt01]

I think this outright cannot work for exclusive full screen apps (because DWM is not involved here, so start cannot show up over the game), and might cause more pain than benefits for some kinds of games or interfaces.

For example, some games requiring the pointer might have you jerk quickly around the screen, meaning you might hit the bottom. Thus the taskbar pops up and breaks DirectFlip, making the game becomes stuttery until the taskbar goes away.

Some FPS games don't reset the pointer position often enough to the center, so sometimes you might hit the bottom and the same issue happens (I've had that one when using Mouse Without Borders). It gets even worse if you end up clicking on the taskbar too, because you could trigger long loading processes (e.g. Visual Studio or another game is pinned to the taskbar).

In the cases of interfaces, I think of YouTube where somebody would want to access settings or something and because the mouse went to the bottom of the screen, start pops up and completely blocks out the settings icon, forcing the user to move their mouse back towards the middle, wait for the taskbar to go away and then move their mouse back towards the settings icon more carefully to not hit the bottom of the screen.

In all 3 examples, this is very frustrating behavior.

I find it way more annoying not to have a way to go back in certain scenarios. Using touch it's even worse, because sometimes you cannot go back unless there's a "go back button". I agree it's not a perfect behavior, but the one which is less annoying in the overall imho

[Gavin-Williams]

This must be an optional behavior. UWP is already hobbled by this behavior and IMO not suitable for game development on desktop because of it. And that's because we cannot fully suspend overlay in UWP, and so Windows captures the top and bottom pixel row of the screen for taskbar / titlebar activation. Even with the mini-bar, it is still captured. That is a breaking feature for many games, they could not be run without incident, because this mouse capture blocks normal interaction such as camera pan where the hardware mouse is used. But software mouse doesn't get around it either. Besides those titles that use the screen edge already, the issue with titlebar and taskbar popping up uninvited is already observed for games such as Minecraft which do capture the mouse and keep it centered. It just shouldn't happen if the app developer doesn't want it happening.

You could propose an OS feature to enable taskbar activation, or restrict it to swipe-up only, and no mouse responsiveness.

I've just moved back to Win32 after a few years learning to code on UWP, I love UWP but this is one of the few boxes I've crossed for UWP that has caused me to abandon it. Because by now, Microsoft would have given us an option to disable overlay if they were serious about supporting game development on UWP. They are not seemingly. It was a relief to open my Win32 app stub and move the mouse around without any overlay popping up. That is the control I need to make games. Games have particular UI/UX needs that not all app dev's understand. And I bet there are even some apps that require full control of the view space, and in those cases, it's just as important that this is optional.

See my counter proposal from 2020...

Proposal: Provide API to disable TitleBar and TaskBar popups #2027

[Balkoth]

If a UWP app is in full screen if I swipe up from the bottom part of the screen with touch or otherwise with a touchpad/mouse I just over the bottom part of the screen.

This sentence does not make any sense.

[MarcAnt01]

If a UWP app is in full screen if I swipe up from the bottom part of the screen with touch or otherwise with a touchpad/mouse I just over the bottom part of the screen.

This sentence does not make any sense.

If you want to discuss about it, starting with it "does not make any sense " isn't a good idea, since I don't usually like to answer to rude sentences

[Balkoth]

There is no discussion, because i do not understand your problem, because your description does not make any sense. Please write an english sentence. Have a nice day.