Open Felix-Dev opened 4 years ago
I can't remember which team in XAML has normally worked on title bar stuff, but I think it may have been Rendering.
He just means that he thinks team-Rendering is the right sub-team within XAML for title bar issues/features. And he is correct.
In this case, the reserved draggable region is not controlled by XAML. This is enforced by the Windows shell for apps running in the UWP app model. So removing that reserved region will require agreement from the shell team and a change in the Windows shell code. This well-written proposal can be used for tracking that possibility. Since this would be an OS change, though, it would likely only be for whichever future release of Windows contains this theoretical change, and would therefore be a while before apps could always depend on the new behavior.
Note that WinUI Desktop apps will not be forced by shell to have this reserved draggable region. So this issue should not occur there (unless we go out of our way to make that happen, but this proposal is a compelling reason to not do that 😄).
@codendone Second what @yaichenbaum said. I do hope that apps using the UWP app model will also be able to create the example experiences shown in the proposal in the future and not just WinUI Desktop apps. In the case that I do want to target multiple different Windows devices in the future with an app, the UWP is the platform of choice. I don't want to end up having to create a separate WinUI Desktop app just so I can style the titlebar of my UPW app on Desktop with the freedom Win32 has been offering for many years now.
Especially when we see that Microsoft UWP Sticky Notes apparently already can create a custom titlebar experience tailored exactly to its needs.
@Felix-Dev and @yaichenbaum: I agree this needs to be reconsidered for UWP. I have logged this request for the Windows shell to provide the desired flexibility for UWP:
@Felix-Dev and @yaichenbaum: I agree this needs to be reconsidered for UWP. I have logged this request for the Windows shell to provide the desired flexibility for UWP:
Hopefully this will extend to the new WinUI Windowing APIs in development for WinUI Desktop apps
@mdtauk
Note that WinUI Desktop apps will not be forced by shell to have this reserved draggable region.
@mdtauk
Note that WinUI Desktop apps will not be forced by shell to have this reserved draggable region.
If a developer wants to dig into the HWND and handle the drawing of the Titlebar. But with an API being developed at the moment - they may put that reserved space in, whilst UWP considers removing it.
Pretty sure WinUI desktop apps won't have this reserved titlebar space even if using the new API. It's not a question of the UWP API but system policy defined by the shell why UWP apps currently have this reserved space in the titlebar. The current UWP Windowing APIs can't work around the underlying shell policy. And since there is no such forced policy for WinUI Desktop apps, you can use the new API (i.e. ExtendIntoTitlebar()) just fine.
So this issue should not occur there (unless we go out of our way to make that happen, but this proposal is a compelling reason to not do that 😄).
Any such feature of the new Windowing APIs for WinUI Desktop would at least be optional then, and as I said above, I don't even think this behavior will be ported over.
The problem is the right inset (left inset in RTL languages) is much larger than the caption area. This is to ensure that there's always a drag region even if the developer messes up. However this prevents you from drawing an interactive control right next to the caption area buttons. There could be an option to remove the extra inset so you can draw right next.
The problem is the right inset (left inset in RTL languages) is much larger than the caption area. This is to ensure that there's always a drag region even if the developer messes up. However this prevents you from drawing an interactive control right next to the caption area buttons. There could be an option to remove the extra inset so you can draw right next.
The size of the Titlebar Buttons may be set to increase in the future, which adjusts the reserved area too. The Figma toolkit includes Standard, Tall, and Future Tall variations
The problem is the right inset (left inset in RTL languages) is much larger than the caption area. This is to ensure that there's always a drag region even if the developer messes up. However this prevents you from drawing an interactive control right next to the caption area buttons. There could be an option to remove the extra inset so you can draw right next.
The size of the Titlebar Buttons may be set to increase in the future, which adjusts the reserved area too. The Figma toolkit includes Standard, Tall, and Future Tall variations
Right but I'm taking about the fact that not only the caption buttons are reserved (you can't get input there) but also some whitespace next to it (about 56px to the right) which becomes obvious since the right inset value is larger than total width of caption buttons. I wanted to put a full screen button next to the minimize button but couldn't because that region doesn't allow input.
The problem is the right inset (left inset in RTL languages) is much larger than the caption area. This is to ensure that there's always a drag region even if the developer messes up. However this prevents you from drawing an interactive control right next to the caption area buttons. There could be an option to remove the extra inset so you can draw right next.
The size of the Titlebar Buttons may be set to increase in the future, which adjusts the reserved area too. The Figma toolkit includes Standard, Tall, and Future Tall variations
Right but I'm taking about the fact that not only the caption buttons are reserved (you can't get input there) but also some whitespace next to it (about 56px to the right) which becomes obvious since the right inset value is larger than total width of caption buttons. I wanted to put a full screen button next to the minimize button but couldn't because that region doesn't allow input.
I only mention it because the design kit includes spacing for the Tall variant, but not for Standard and Future Tall - so it may be something they will implement in the future. I guess it could be an opt in, so a dev can remove the reserved space - or it will just change as the titlebars change
Until any changes to the system reserved area is implemented, could the Design Toolkit maybe add examples that manage to work around it in terms of the design for additional buttons.
Your phone works around it well I think.
Until any changes to the system reserved area is implemented, could the Design Toolkit maybe add examples that manage to work around it in terms of the design for additional buttons.
Your phone works around it well I think.
No it doesn't work well. It has an ugly separator in the middle which is totally unnecessary. Since existing UIs might rely on the behavior, it could be an opt-in feature to remove the reserved region on Windows 21H2+.
I'm porting a WinForms app to UWP which implements a custom titlebar that contains tabs. If the user clicks, the app gets the event. If the user mouses down and moves, the system does, and the window moves. The ability to achieve parity here would be appreciated.
Summary
In UWP, we can easily add custom UI elements to the titlebar of our apps thanks to the CoreApplicationViewTitleBar API. The issue arises when we want to add interactive UI elements (such as Buttons) to the titlebar. By default, our added custom UI elements cannot be interacted with as the sytem will retain the entire titlebar area as a draggable region (minus the system caption buttons area). This behavior is described in the UWP documentation:
If we want our custom UI elements such as buttons to be interactive, we need to define a custom draggable region as stated in the docs:
And here comes the issue: Defining a custom draggable titlebar region will automatically create a system reserved region in the titlebar which the developer cannot control:
@yaichenbaum created an app demonstrating the effects of this behavior (attached at the bottom): (red = system caption buttons area) (pale red = system reserved draggable region when defining a custom draggable region) (sky blue = titlebar region which can be made fully interactive)
As can be seen, any custom UI element added to the titlebar inside the system reserved draggable region cannot be interacted with. In other words, if you want to place an interactive button to the left of the system caption buttons, you will always end up with the region displayed in pale red as a separator between your button and the system caption buttons.
This is a major issue which prevents developers from creating custom titlebar experiences which seamlessly integrate with the system provided titlebar for UWP apps.
Here are a few examples which show customized titlebars which cannot be realized by us UWP developers today:
NordVPN:
Microsoft UWP Sticky Notes:
In both images, the highlighted background of the custom titlebar button (Settings button in both cases) indicates mouse hovering/click and thus that the user can interact with the custom button.
Rationale
Thus, when the developer ensures that there always will be a draggable titlebar region at any given time, the developer should be allowed to fully create the experience which has been envisioned for the product in question.
Scope
Open Questions
Attached Files
Stubborn_Button.zip