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

gpui: Fix window display on Windows #18705

Merged
merged 4 commits into from
Oct 10, 2024

Conversation

JunkuiZhang
Copy link
Contributor

@JunkuiZhang JunkuiZhang commented Oct 3, 2024

This PR addresses the same issue as PR #18578. After a full day of research and testing, I believe I’ve found the best solution to resolve this issue. With this PR, the window creation behavior on Windows becomes more consistent with macOS:

  • When params.show is true: The window is created and immediately displayed.
  • When params.show is false: The window is created but remains hidden until the first call to activate_window.

As I mentioned in #18578, winit creates hidden windows by setting the window's exstyle to WS_EX_NOACTIVATE | WS_EX_TRANSPARENT | WS_EX_LAYERED | WS_EX_TOOLWINDOW, which is different from the method used in this PR. Here, the window is created with normal parameters, but we do not call ShowWindow so the window is not shown.

I'm not sure why winit doesn't use a smilliar approach like this PR to create hidden windows. My guess is that winit is creating this hidden window to function as a "DispatchWindow" — serving a purpose similar to WindowsPlatform in zed. To ensure the window stays hidden even if ShowWindow is called, they use the exstyle approach.

With the method used in this PR, my initial tests haven't revealed any issues.

Release Notes:

  • N/A

@cla-bot cla-bot bot added the cla-signed The user has signed the Contributor License Agreement label Oct 3, 2024
@maxdeviant maxdeviant changed the title Windows/fix show 4 windows: Fix window display on Windows Oct 3, 2024
@maxdeviant maxdeviant changed the title windows: Fix window display on Windows gpui: Fix window display on Windows Oct 3, 2024
@shenjackyuanjie

This comment was marked as off-topic.

@Long0x0
Copy link

Long0x0 commented Oct 4, 2024

winit does create windows using the WS_EX_APPWINDOW flag (code here). The window you mentioned is an extra one created for the event loop that is never visible.

@evaneaston
Copy link

I've verified that this fixes the reported problem. I have no idea if it's the correct way to solved it.

@co-bby

This comment was marked as off-topic.

@co-bby
Copy link

co-bby commented Oct 5, 2024

Tested is working

@MarvinMynx
Copy link

MarvinMynx commented Oct 5, 2024

I had the same issue "no Window after Build Process" can confirm that this fix works too.

@AFellowSpeedrunner
Copy link

AFellowSpeedrunner commented Oct 6, 2024

Added it into my source tree, can also confirm it works on Windows 11 Home 23H2.

Thanks for the patch by the way, spent forever trying to figure this out myself...

EDIT: I forgot to mention, but I've been using this for over a day and I myself haven't found any issues with this change yet.

image

@zhouxs1023
Copy link

still turn on error as below:
Error { kind: Generic("Input watch path is neither a file nor a directory."), paths: [] }

@shenjackyuanjie
Copy link
Contributor

still turn on error as below: Error { kind: Generic("Input watch path is neither a file nor a directory."), paths: [] }

this error is not related to this issue

@AFellowSpeedrunner
Copy link

Any timeframe for when this gets merged?

Copy link
Contributor

@SomeoneToIgnore SomeoneToIgnore left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no clue about these changes, but given the previous change got merged and this is tested by others and reported to be fixing the issue, let's merge this and @mikayla-maki can post-review if needed.

Odd that I have never experienced that in my Windows builds.

@SomeoneToIgnore SomeoneToIgnore self-assigned this Oct 10, 2024
@SomeoneToIgnore SomeoneToIgnore merged commit 7c306a5 into zed-industries:main Oct 10, 2024
14 checks passed
@getpool
Copy link

getpool commented Oct 11, 2024

最近更新编译,在windows下,没办法保存正确的窗口大小,没办法最大化,删除db,也是一样。
我只能手动修改db.sqlite,把window_with和window_height改成我的显示尺寸大小。

大佬能不能增加个兼容一下,老旧设备不支持vulkan的问题呢。

@JunkuiZhang
Copy link
Contributor Author

最近更新编译,在windows下,没办法保存正确的窗口大小,没办法最大化,删除db,也是一样。 我只能手动修改db.sqlite,把window_with和window_height改成我的显示尺寸大小。

I will open a PR to address this tomorrow.

大佬能不能增加个兼容一下,老旧设备不支持vulkan的问题呢。

The only possible solution is porting the backend from blade to directX, but zed team rejected my PR of porting to directX. So, I can’t, sorry.

mikayla-maki pushed a commit that referenced this pull request Oct 16, 2024
Closes #18705 (comment)

This PR fixes the issue where the Zed window was not displaying
correctly on launch. Now, when Zed is closed in a maximized state, it
will reopen in a maximized state.

On macOS, when a window is created but not yet visible, calling `zoom`
or `toggle_fullscreen` will still affect the hidden window. However,
this behavior is different on Windows, so special handling is required.

Also, since #18705 hasn't been reviewed yet, I'm not sure if this PR
should be merged now or if it should wait until #18705 is reviewed
first.


Release Notes:

- N/A
noaccOS pushed a commit to noaccOS/zed that referenced this pull request Oct 19, 2024
- Closes zed-industries#18610


This PR addresses the same issue as PR zed-industries#18578. After a full day of
research and testing, I believe I’ve found the best solution to resolve
this issue. With this PR, the window creation behavior on Windows
becomes more consistent with macOS:

- When `params.show` is `true`: The window is created and immediately
displayed.
- When `params.show` is `false`: The window is created but remains
hidden until the first call to `activate_window`.

As I mentioned in zed-industries#18578, `winit` creates hidden windows by setting the
window's `exstyle` to `WS_EX_NOACTIVATE | WS_EX_TRANSPARENT |
WS_EX_LAYERED | WS_EX_TOOLWINDOW`, which is different from the method
used in this PR. Here, the window is created with normal parameters, but
we do not call `ShowWindow` so the window is not shown.

I'm not sure why `winit` doesn't use a smilliar approach like this PR to
create hidden windows. My guess is that `winit` is creating this hidden
window to function as a "DispatchWindow" — serving a purpose similar to
`WindowsPlatform` in `zed`. To ensure the window stays hidden even if
`ShowWindow` is called, they use the `exstyle` approach.

With the method used in this PR, my initial tests haven't revealed any
issues.



Release Notes:

- N/A
noaccOS pushed a commit to noaccOS/zed that referenced this pull request Oct 19, 2024
…s#19124)

Closes zed-industries#18705 (comment)

This PR fixes the issue where the Zed window was not displaying
correctly on launch. Now, when Zed is closed in a maximized state, it
will reopen in a maximized state.

On macOS, when a window is created but not yet visible, calling `zoom`
or `toggle_fullscreen` will still affect the hidden window. However,
this behavior is different on Windows, so special handling is required.

Also, since zed-industries#18705 hasn't been reviewed yet, I'm not sure if this PR
should be merged now or if it should wait until zed-industries#18705 is reviewed
first.


Release Notes:

- N/A
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla-signed The user has signed the Contributor License Agreement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Zed Cannot Display a Window on Windows OS after Being Built