fixed the window extend issue #20056
Conversation
|
You can test this PR using the following package version. |
|
I'm working on fixing the unit tests. I have fixes but I'm reviewing them one more time. |
|
OK, I have learned that my attempt to fix this only works when override just the title bar height of 32. It seems to not work properly when extending past (ex. 70). |
|
You can test this PR using the following package version. |
|
You can test this PR using the following package version. |
|
OK, I think this final commit is good. I would love feedback from the Avalonia team. If this is not acceptable then maybe instead I could add a bool to like UWP's TitleBar.ExtendViewIntoTitleBar, this way we can leave the left, right, and bottom border as is. |
|
You can test this PR using the following package version. |
|
You can test this PR using the following package version. |
|
You can test this PR using the following package version. |
|
You can test this PR using the following package version. |
|
You can test this PR using the following package version. |
|
The problem with this PR is that the requested client area isn't respected anymore: the initial Plus, since this PR only works with captions having a height > 32, we now have completely different behaviors depending on the height of the title bar. As it is currently, we can't accept this PR. That said, the idea has merits. In fact, I started reviewing this yesterday, found the size issue and hacked my way around. I came up with a start of a solution that seemed to worked well initially, and also solved the clipping issue that we have on master. Then I realized that I just added new problems when the window gets maximized, because we are special casing a lot of things in a lot of places. I went down the rabbit hole. Deeply. We have hacks in every corner in this area, and they don't play well with each other. A lot of combinations of I initially just wanted to give you some pointers, but at the point where I am right now I'll just finish this work and open a new PR that will solve this issue, as well as several others. I'm also working on adding integration tests, because those scenarios are tedious to test manually, and so easy to break without realizing it. (Which is what happened through the years when other fixes got pushed). Thank you for your understanding :) |
|
Can you reference the PR here once you create it? Also, I don't mind if the problem is solved another way, I just need a better resize experience. I wasn't sure my way was the "correct" way to solve it. |
|
You can test this PR using the following package version. |
|
@BobbyCannon I'm closing this in favor of #20217. |
3 participants
What does the pull request do?
The current extend into client area on windows makes it very difficult to resize on the left, right, and bottom borders due to extending into the resize areas.
ExtendClientAreaToDecorationsHint="True"
ExtendClientAreaChromeHints="NoChrome"
ExtendClientAreaTitleBarHeightHint="32"
The arrow should be in "resize" mode to resize the window on the right side.
What is the current behavior?
Extending into the client area makes it hard or impossible to use controls due to the window resize overriding the control area on the left, right, and bottom borders.
Ex. if you have a scrolling item that has a collapsed scroll bar on the right side of your application. Because the client area extends into the right area the scroll bar is inaccessible due to the window resize margin.
What is the updated/expected behavior with this PR?
When extending only the top (title bar) should be extended into.
Breaking changes
May affect apps that wants resize to override on all sides? I'm not entirely sure this would be desired ever. When would an app want to resize into the resize margin?