Skip to content
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

Added window animations for undecorated Win32 window #3221

Merged
merged 2 commits into from Nov 8, 2019

Conversation

@mstr2
Copy link
Contributor

mstr2 commented Nov 5, 2019

What does the pull request do?

The current Win32 window implementation supports Window.HasSystemDecorations with a set of window styles that unfortunately also remove all window animations that are provided by DWM. This PR restores these lost window animations. The result is that a window with HasSystemDecorations == false will feel the same as any other window.

How was the solution implemented (if it's not obvious)?

The window styles that are responsible for window animations are not removed from the window. SetWindowTheme is used to fix a visual glitch that would otherwise make the window have rounded top-left and top-right corners.

@mstr2 mstr2 force-pushed the mstr2:undecorated-window branch from bf20e6f to 7b2af95 Nov 8, 2019
@Gillibald

This comment has been minimized.

Copy link
Contributor

Gillibald commented Nov 8, 2019

Thanks @mstr2

@Gillibald Gillibald merged commit a3712ed into AvaloniaUI:master Nov 8, 2019
3 checks passed
3 checks passed
Avalonia (Pull Requests) Avalonia (Pull Requests) succeeded
Details
AvaloniaUI.Avalonia #20191108.20 succeeded
Details
WIP Ready for review
Details
danwalmsley added a commit that referenced this pull request Nov 9, 2019
Added window animations for undecorated Win32 window
danwalmsley added a commit that referenced this pull request Nov 9, 2019
This reverts commit 7f7471e.
danwalmsley added a commit that referenced this pull request Nov 9, 2019
This reverts commit a3712ed, reversing
changes made to edbd75c.
@danwalmsley

This comment has been minimized.

Copy link
Member

danwalmsley commented Nov 9, 2019

@mstr2 @Gillibald @kekekeks iv had to revert this, because it seems to have some kind of negative border on maximize windows.

@danwalmsley

This comment has been minimized.

Copy link
Member

danwalmsley commented Nov 9, 2019

image

@danwalmsley

This comment has been minimized.

Copy link
Member

danwalmsley commented Nov 9, 2019

it cuts off some of the UI. Perhaps its asuming a certain part of the ui is border, but this would need to be configurable, or set to 0 and then the end user can handle this themselves.

@Gillibald

This comment has been minimized.

Copy link
Contributor

Gillibald commented Nov 9, 2019

This should be tested against a naked undecorated window

@Gillibald

This comment has been minimized.

Copy link
Contributor

Gillibald commented Nov 9, 2019

BTW I think this is the expected behavior. It always takes some extra space. So on maximize you need to set the border to zero if you don't want this behavior.

@kekekeks

This comment has been minimized.

Copy link
Member

kekekeks commented Nov 9, 2019

It seems that Windows expect windows with WS_BORDER to always have a proper border, so it positions a maximized window somewhere at (-4,-4) and adds extra pixels to its size.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.