-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve updates of Win32 window's WindowStyles #12752
Conversation
You can test this PR using the following package version. |
What about other styles set by the application itself? There are very valid usages of I've definitely seen such usages being suggested as workarounds in some Avalonia issues/discussions, which is fine imo, as Avalonia isn't expected to handle every platform-specific property. |
Thanks for your feedback. |
You can test this PR using the following package version. |
9eb971e
to
286dc6d
Compare
Thank you! Any reason why |
a343cdb
to
5fc0bc5
Compare
Having it in controls would allow using the api in the shared ui projects, especially in the multiplatform templates. |
You can test this PR using the following package version. |
This is platform-specific code. So I don't see why we wanted to add that to some x-plat template. |
c31f662
to
bd95c0e
Compare
You can test this PR using the following package version. |
bd95c0e
to
869b5c5
Compare
You can test this PR using the following package version. |
869b5c5
to
4a5498e
Compare
You can test this PR using the following package version. |
I've not been involved in this feature, so I may be wrong but this is my layman's understanding:
When running on non-win32 this code will be stripped, and no reference to
|
Even if it won't be stripped (e. g. you define it from XAML), the code in |
You can test this PR using the following package version. |
I'd argue that if an user needs such a low level platform specific hook, they're either targeting a single platform, or already have conditional compilation/references in place. Here, the API is simple: it's only two delegates with primitive arguments only. For the sake of the argument, imagine we need some heavy Win32-specific structs instead: personally, I'd find it really weird to have them in the base platform. |
[PrivateApi] | ||
public interface IWin32OptionsTopLevelImpl : ITopLevelImpl | ||
{ | ||
public delegate (uint style, uint exStyle) CustomWindowStylesCallback(uint style, uint exStyle); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those delegates are still accessible despite the PrivateApi
but I don't know whether it's the expected behavior or not. All PrivateApi
members and nested types normally become internal
in the ref assemblies, but delegates aren't affected currently. @kekekeks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Callback delegate should be declared in Win32SpecificOptions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved.
|
||
namespace Avalonia.Controls.Platform | ||
{ | ||
[Unstable] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure Unstable
is the right attribute here: both SetXxxCallback
methods will be marked as obsolete, effectively discouraging or preventing their usage.
Also, the class should probably be made static to prevent inheritance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Class is now static, and Unstable attribute removed
That's not the case for 3rd-party controls that are providing a custom window class. Since our desktop platforms are built for |
You can test this PR using the following package version. |
cf636b7
to
787b5ce
Compare
You can test this PR using the following package version. |
You can test this PR using the following package version. |
7fd8a09
to
5ead24a
Compare
You can test this PR using the following package version. |
5ead24a
to
0705446
Compare
You can test this PR using the following package version. |
Hello, I've noticed that in recent master builds, a no-chrome Previous to this PR, a A window with those properties set is only showing a single pixel border all around. My guess is the result SHOULD be that the window opens at 1026x770 (1024x768 plus a pixel on each side) instead of 1040x807 since there is no chrome and Avalonia seems to try and get the window's content to the Prior to the PR, the no-chrome window's overall size was the exact Can this PR be updated to get it working properly for no-chrome windows? |
What does the pull request do?
Improves updates of window styles, reducing the number of calls to
SetWindowLong
needed to apply an update to a window.This change computes the required window styles from the window properties, ensuring only the styles we requested persists.
To allow user to set custom styles, 2 new apis are provided;
Win32SpecificOptions.SetWindowStylesCallback
: called after the window styles are computed.Win32SpecificOptions.SetWndProcHookCallback
: called as part of the window message handling.What is the current behavior?
Window styles are updated from the current window styles. Then the relevant styles are toggled and window is updated. Since the styles aren't validated with the window properties, and only when the properties change will their styles be toggled, the window styles can have other unexpected styles set by external applications, and window behavior may differ from normal.
What is the updated/expected behavior with this PR?
How was the solution implemented (if it's not obvious)?
Checklist
Breaking changes
Obsoletions / Deprecations
Fixed issues